You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to issues with the TFJS back end, both loading and saving (#363) models from/to disk is currently not possible in discojs. In particular this means we cannot use pre-trained models.
Currently models are built and then said models are made available in the server.
If we have a pre trained model stored as a model.json + weights.bin, we would load it as follows:
[Tensorflow Node-js, TypeError: Only HTTP(S) protocols are supported](https://stackoverflow.com/questions/60137483/tensorflow-node-js-typeerror-only-https-protocols-are-supported)
As with #363, using both tfjs and tfjs-node seems to cause unexpected behavior as reported here
@tharvik Suggested to import either tfjs or tfjs-node on discojs depending on if it is used by browser or node, since the api is identical this should work in principle. Perhaps a simpler solution is possible.
Another idea ( @s314cy ) is to refactor the pertinent code from discojs back into the server.
The text was updated successfully, but these errors were encountered:
Issues with approach 2 (refactoring code back to the serve)
Using the easier approach of refactoring the pertinent code from discojs back into the server yields a previous error #379, so we have come full circle. To summarize the issue
Say model.ts is the file that contains the script of loading models, currently this is in discojs, it used to be in the server.
Issues server side
If model.ts is in the server, we get #379 in the benchmark (and sometimes even in the UI? when going between training and testing). Somehow the tfjs engine has issues keeping track of variable names in the asynchronous js (await style code), and so accidentally sets the same variables with the same name twice causing a collision (once when loading to the server, and then again for the user).
Note that this is not an issue if it is in discojs, somehow by removing it from that scope the imported tfjs dependencies are less stable and causing something weird to happen in the engine that is keeping track of all this.
Note the key here is the tfjs engine which keeps track of variables in the background; this was discussed and worked on in #391.
Issue discojs side
If model.ts is in discojs, then the above causes no issue, however in order to load models from the file system we need the following code:
However io.fileSystem is only available with tfjs-node, and if we use tfjs-node then discojs is not compatible with the browser.
Thus, we need to conditionally import tfjs-node, which I've tried unsuccessfully here using the ts doc for conditional model loading. The issue is that I need to import the type of tfjs-node for the io functionality we need, but we need to import it without importing the functionality (which should be doable, but I have not yet found how).
once we load via links only as in #494 , this might simplify our node/not structure even further? (even if it already works now with the current architecture)
Due to issues with the TFJS back end, both loading and saving (#363) models from/to disk is currently not possible in discojs. In particular this means we cannot use pre-trained models.
Currently models are built and then said models are made available in the server.
If we have a pre trained model stored as a model.json + weights.bin, we would load it as follows:
This however yields the following error:
As with #363, using both
tfjs
andtfjs-node
seems to cause unexpected behavior as reported here@tharvik Suggested to import either tfjs or tfjs-node on discojs depending on if it is used by browser or node, since the api is identical this should work in principle. Perhaps a simpler solution is possible.
Another idea ( @s314cy ) is to refactor the pertinent code from discojs back into the server.
The text was updated successfully, but these errors were encountered: