Cellprofiler: Drop ImageJ

[0x00b1]

[dlogan]

So what you're saying is that ImageJ is the issue.

[0x00b1]

:stuck_out_tongue_winking_eye:

[0x00b1]

Resolves #1995

[0x00b1]

https://github.com/CellProfiler/prokaryote/issues/22

[0x00b1]

@ctrueden my motivations:

The existing ImageJ integration is shaky

• from a usability perspective
• from an inter-process perspective (i.e. files should be the only inter-process mechanism between ImageJ and CellProfiler)
• from an engineering perspective (javabridge is extremely complicated for such a narrow use case)
• from a performance perspective (concurrently running two virtual machines to do simple image processing is excessive)

I think ImageJ and CellProfiler should continue to be interoperable, but I don't think this requires any sophisticated or additional integration (i.e. we need better documentation rather than better code).

[ctrueden]

Thanks for the details. I agree with much of your assessment. But I have some ideas on how to improve the situation.

files should be the only inter-process mechanism between ImageJ and CellProfiler

I'd like to clarify (for any various folks reading this over) the difference between _interoperability_ and _integration_:

• Interoperability means programs which are capable of consuming each other's I/O. This often boils down to support for the same file formats.
• Integration typically means two programs sharing common data structures. It is generally "closer" than interoperability from a communication standpoint. I generally consider both in-process and interprocess communication approaches to be integration rather than mere interoperability.

So with those definitions in mind, I actually do think we can achieve an inter-process _integration_ between CellProfiler and ImageJ that is more maintainable and sustainable, while remaining performant enough for many real-world use cases, via a RESTful ImageJ server + some thin modules on the CP side. Will describe in more detail below.

javabridge is extremely complicated for such a narrow use case

Yeah, I have mixed feelings about it. I trust @LeeKamentsky that he did his homework when coming up with that beast. I expect there were dramatic performance gains. But it is still a question whether they are worth any headache in maintenance. I would like to hear more about what makes java_bridge difficult enough to maintain that it should be dropped. (As maintainer of Fiji, I definitely sympathize that whenever you can afford to retire a component, it is a great relief.)

concurrently running two virtual machines to do simple image processing is excessive

You refer to the Python interpreter running at the same time as the Java virtual machine? Or does the current CP/ImageJ integration use two VMs somehow??

Assuming you just mean both Python & Java at the same time: I agree that using that integration for trivial purposes is indeed excessive. But that does not mean there are no valid or powerful use cases. It is very convenient for users to be able to "mix and match" in situations where they have existing workflows on each side of the fence—or when they want an existing ImageJ workflow to benefit from CP's automation and reproducibility.

I think ImageJ and CellProfiler should continue to be interoperable, but I don't think this requires any sophisticated or additional integration (i.e. we need better documentation rather than better code).

Always agreed about better documentation. 👍 What I want to avoid is the need for users to manually launch each program and save files back and forth, just to complete an otherwise fully automated analysis, since it kills the scalability when manual transfer steps are required in the middle of the workflow.

So, my idea: a RESTful ImageJ server. We have been discussing it for a while. Please see imagej/imagej-server#1 for some new comments along the lines of my current thinking.

[ctrueden]

For the community: @etarena and I met with @0x00B1 and @AnneCarpenter back in May about this topic. Below are my notes on that meeting, including tentative work plan. See imagej/imagej-server#1, and the imagej/imagej-server project in general, to follow my side of this work.

This work will provide a language-agnostic API for access to ImageJ functionality, which could also be implemented by CellProfiler and potentially other tools in the ecosystem (e.g. OMERO?) to provide image & related data according to the same standard. In a nutshell, it will let CellProfiler continue to call ImageJ modules as part of its pipelines, but without the complexity and fragility incurred by the in-process python-javabridge approach. In medium term, it will help to strengthen and generalize the image transfer mechanism between the two applications.

We also discussed longer-term perspective, particularly how we anticipate image analysis evolving in the next 5-20 years, towards larger scale / cluster computing, as well as (briefly) toward machine learning and deep learning methods. Concretely, we discussed Apache Spark and how we should make a long-term effort to develop our tools in a way which is compatible with its paradigm.

Work we agreed on:

• [ASAP] Curtis will develop an initial prototype of the imagej-server component for RESTful web services:
  
  
  
  • query and execute available modules
  
  
  • read and write images
  
  
• [ASAP] Allen will develop a toy/example client which will exercise the imagej-server from the Python side.
• [Before end of year 2016] Allen will spend ~1 week exploring Apache Spark integration with our technologies, and offer a recommendation on how to proceed with that effort.