imagej
IJ2-based Particle Analyzer
Particle analyzer is one of the more heavily used features of ImageJ. It should be ported to use IJ2 under the hood.
What needs to happen
- [ ] Port IJ1 Analyzer
- [ ] Port ROI manager
To consider
- BioVoxxel's Extended Particle Analyzer
- 3D Manager from mcib3d-core
Hi @kephale. Do you know the individual steps which are conducted using one of these plugins? aAs far as I understand Analyze Particles is more or less an concatenation of several individual steps, right? Maybe we are already pretty close.
As far as I can tell (I have not looked into the code) those steps are involved:
- CCA on binary image
- Filter particles (while we are at it, we could make it use any feature for that?)
- Measure features for the remaining partiles (using the Set Measurements options)
- Add particles to ROI Manager
The more complicated stuff is hiding in the Set Measurements behavior..
So:
- [X] CCA on binary image
- [ ] Filter particles (while we are at it, we could make it use any feature for that?)
This one we already could do but we should implement a convenience method in ops which allows you to (a) calculate features and then (b) discard all regions which don't fulfill a certain condition based on the calculated features... @tibuch you think this is something which we can quickly add? Maybe a Processor?
- [X] Measure features for the remaining partiles (using the Set Measurements options)
- [ ] Add particles to ROI Manager
This is very IJ specific, and I don't know how to do that. I hope we can have a ROI discussion at one of the upcoming hackathons.
I have mixed feelings about interfacing an IJ2 Particle Analyzer with [the existing] ROI Manager (which would presumably involve changing all of the Roi code in ROI Manager to operate on Imglib2-roi and that sounds a bit painful for that 2468 line beast). I'm not sure ROI Manager would be easy to salvage because there are quite a few IJ1 Roi method calls.
Does the ops map function work on ROIs? In Clojure we have a function related to map, called filter, that takes a predicate function and list as input and returns a list containing all input elements that pass the predicate's test.
That said, I think you're right @dietzc. Most of the functionality seems to be there, and if ROI manager is ignored for now, then all that should be needed are ROI/particle filtering and outputting everything to a ResultTable. This would still cover quite a few use cases, such as any time someone wants tables of feature data for their segmentation results, etc..
I have mixed feelings about interfacing an IJ2 Particle Analyzer with [the existing] ROI Manager (which would presumably involve changing all of the Roi code in ROI Manager to operate on Imglib2-roi and that sounds a bit painful for that 2468 line beast). I'm not sure ROI Manager would be easy to salvage because there are quite a few IJ1 Roi method calls.
:+1: on the mixed feelings. I'll also add that it doesn't make too much sense to start with something new as long as the roles and implementations of ROIs / labelings / overlays in ImageJ2 is unclear.
Note that ImageJ2 already has an "Overlay Manager" for working with IJ2-style ROIs. But that was before @tpietzsch redesigned the ROI data structures. Regardless, I do not think that manager should be integrated with an IJ2 particle analyzer workflow.
I also want to comment (reassure?) everyone that UI components of ImageJ 1.x will play no role in new functionality of IJ2. The only way we ever interact with IJ1 is via the imagej-legacy layer. So e.g. for an IJ2 particle analyzer, it would operate on IJ2 data structures, which the imagej-legacy layer knows (or could be taught to know) how to translate to and from IJ1 data structures.
Regarding ROIs specifically, IIRC, right now we synchronize IJ2 Overlays with the IJ1 overlay, since the IJ1 overlay can hold more than one ROI. The ROI manager does not get synced either way, although we could consider doing that in cases where it makes sense.
