imagej / imagej-tensorflow

ImageJ/TensorFlow integration library
https://imagej.net/libs/tensorflow
Other
25 stars 13 forks source link

Import graph from local file #1

Closed frauzufall closed 7 years ago

frauzufall commented 7 years ago

Hey Curtis,

I couldn't find a way to import a local graph .pb file so I added this function. I think the existing loadGraph method expects the graph to be unpacked from a model protocol buffer? If this is redundant, maybe you can point me to a solution using the existing functions?

Also updated the pom to the current tensorflow version.

ctrueden commented 7 years ago

I couldn't find a way to import a local graph .pb file so I added this function.

The method Graph loadGraph(Location source, String modelName, String graphPath) should do the trick, no? Just pass a new FileLocation for the Location source. Is there some obstacle with that?

frauzufall commented 7 years ago

It somehow appends the path to a model folder in the Fiji app directory, but maybe I am calling it wrong? I tried different function parameters..

@Parameter
    private File modelfile = new File("/home/user/data/graph.pb");

final FileLocation source = new FileLocation(modelfile);

graph = tensorFlowService.loadGraph(source, "model", modelfile.getAbsolutePath());
// output: java.io.FileNotFoundException: /home/user/Programs/Fiji.app/models/model/home/user/data/graph.pb (No such file or directory)

graph = tensorFlowService.loadGraph(source, "", "");
// output: java.io.FileNotFoundException: /home/user/Programs/Fiji.app/models (Is a directory)
ctrueden commented 7 years ago

Thanks for the additional details.

Looking at the current code, the loadGraph method assumes the source is a compressed ZIP file. The modelName represents a subdirectory where you want the extracted model to be cached. The graphPath is the name of the .pb file within the ZIP archive.

I added some javadoc to clarify this: 71caa7a4c865ec72b788bddc78577514f3337ffc.

The idea is that models should be shipped as ZIP files which get unpacked and cached once. This avoids the need to ship models on ImageJ update sites, since they can get very large.

On the deployment side, is there some reason you need to do things in a different way than that?

On the testing side, we could try to make the TensorFlowService smarter about the case where the source is actually not a zipped resource. But we'll need to decide what to do in that case—whether to skip the caching/copying step completely, whether to emit any warnings to the log, etc.

frauzufall commented 7 years ago

Thanks @ctrueden, using ZIP archives worked fine! I think it would be nice to support the pb files directly, but it's not super important and we have a working solution for now so I would close this.