Open xulman opened 6 years ago
Your localNetSender
and localNetReveiver
classes are Command
s already, so if your annotate them with headless=true
, they should just work in KNIME (with autogenerated nodes). (I'm not sure about the parameter initializer
s, though...).
Just be sure to also install the ZeroMQ dependency (and possible inherited dependencies) as jars via the ImageJ2 integration as well.
Thank you, Jan, for the advice. This is my deepest wish that it would just work like you say.... (if not, turning it into a native KNIP node is not so much pain either).
Since I want to add status/progress bar into the Fiji, which maybe makes no sense on the KNIME side, I would need to strip the two classes anyway and make a richer one for the Fiji (instead of having these rich and making them poorer for KNIME).
work on this has started with commit b9c64c588b9e85ca5c7347b3db3b37e8aa2112df
plan is: extend the protocol with optional sub-header that tells how many images are about to come; with end_of_transmission tag at the end (if it is not received, receiver must continue listening)
create the receiveNode with receiveImage(), create the sendNode with serveImage()
the protocol has been extended in commit a2ab8b40083e87fb04e0850e74b1deb15adc2056
remains to create the nodes themselves
nodes were created in commit 7310505f491c3cdc272ebb699add8d517faa1e24
remains to fine tune them:
adjust logging levels (info for the main loop, debug for the ProgressCallback)
ServingNode add the ability to choose/supply the filename of the transfered image
icons...
DOCUMENTATION: how to build it and how to install it
use BufferedTable?, Streamlining?
check RemoteWorkflowExecution, can we use it?
Should be a nice wrapper of the ImgPacker class, just like we have it already for the Fiji plugin. Since KNIME nodes are executed not necessarily right after their configuration is done, any interactive style of configuration (e.g., clients discovery, available host/listening IP addresses) will likely be avoided in this branch.