Configure Analyze Regions

[tischi]

@dlegland

How does one set those booleans from Java?

I mean without calling the UI, but programmatically....

[dlegland]

Hi @tischi, I do not think this is possible. When using an ImageJ plugin, one has to rely on the "run" method. One way could be to split the implementation, such that the plugin class only manages the GUI. I plan to refactor the Analyze regions plugins in a near future, so maybe I can also add this feature, if it is possible and not too hard.

[tischi]

Thanks! A very easy fix would be to make the boolean variables public. What do you think?

[dlegland]

Hi, yes, you're right, this could be a quick fix! I try to have a look soon!

[tischi]

@dlegland any progress on this front? :-)

[dlegland]

Hi, not much at the moment, but I plan to check this when I come back from holidays. hopefully end of august or beginning of september...

best, David

[dlegland]

Hi, I just pushed a commit that updates the AnayzeRegions plugins.

It introduces an inner class "Features", that contains public boolean fields for selecting the features to compute. Example:

// creates a new Features instance to select the features to compute.  
AnalyzeRegions.Features features = new AnalyzeRegions.Features();
features.setAll(false);
features.area = true;
features.perimeter = true;
features.centroid = true;

// compute the features, and returns the corresponding table
ResultsTable table = AnalyzeRegions.process(imagePlus, features);
table.show("Morphometry");

Feedback welcome!

[dlegland]

Proposition from @oburri: use a Builder type approach.

ResultsTable table = AnalyzeRegions.create( imagePlus )
       .getArea()
       .getPerimeter()
       .getCentroid()
       .compute();

[lacan]

In case you're interested in this kind of Builder Pattern refactoring, I'd be happy to help, as I do love MorphoLibJ

[dlegland]

Hi @tischi and @lacan ,

I finally arrived at a new refactoring of the AnalyzeRegions class!

The main thing is that the computation part is now managed by the "MorphometricFeartures2D" class (within inra.ijpb.analyze.regions2d package). I was trying with builder type approach, but finally used a collection features (instances of the inner "Feature" enum). A typical call can be as follow:

ResultsTable table = new MorphometricFeatures2D()
    .add(Feature.AREA)
    .add(Feature.PERIMETER)
    .add(Feature.CENTROID)
    .computeTable(imagePlus);

An alternative with adequate static imports:

ResultsTable table = new MorphometricFeatures2D(AREA, PERIMETER, CENTROID)
    .computeTable(imagePlus);

The AnalyzeRegions have been updated to call the MorphometricFeatures2D class. The AnalyzeRegions.Features class have been deprecated, and the code was adapted to use the MorphometricFeatures2D class. It seems to work as previously.

I would lije to have a more generic approach, that would allow to add new user-defined features without having to change code in MorphoLibJ, but I could not yet find a simple enough solution...

[tischi]

@dlegland

0. Thank you very much! Looks beautiful!
1. What happens if one does this: ResultsTable table = new MorphometricFeatures2D().computeTable(imagePlus); does one get all or none?
2. Will that also work in 3D with the same API?
3. finally used a collection features (instances of the inner "Feature" enum). I am intrigued, could you post a link to the code?

[dlegland]

Thank you very much! Looks beautiful!

Thank you! I hope this will be more scriptable than the AnalyzeRegions plugin, and that this will not be too complicated to maintain by introducing new features...

What happens if one does this: ResultsTable table = new MorphometricFeatures2D().computeTable(imagePlus); does one get all or none?

One get an empty table. Only the region label is provided.

Will that also work in 3D with the same API?

Yes! working on it... nearly ready, I just would like to enhance unit tests and general checks.

finally used a collection features (instances of the inner "Feature" enum). I am intrigued, could you post a link to the code?

Sure! the main class is MorphometricFeatures2D.java. It encapsulates an enum class MorphometricFeatures2D.Feature. This enumeration lists the different features that can be computed with the AnalyzeRegions plugin. Then, the computeTable method populates the results table from an ImagePlus containing a 2D label map. In practice, most of the computations are performed within specialized feature analyzers (like Centroid, EquivalentEllipse...). The MorphometricFeatures2D.computeTable method calls them is the appropriate way (to manage dependencies), then populates the table from the various results.

[tischi]

I see!

    public MorphometricFeatures2D add(Feature f)
    {
        features.add(f);
        return this;
    }

I guess this does the trick?! Isn't that some kind of builder pattern?

[dlegland]

I guess this does the trick?!

Yes! Works like classical methods from the Collections framework, but returns instance to "this".

Isn't that some kind of builder pattern?

To be honest, I do not really know... Returning an instance to this is typical from the Builder pattern, but the builder approaches I have seen often use two different classes: one for the builder, another one for the main class. Here, there is no "build()" method at the end. Or maybe the MorphometricFeatures2D class can be seen as a builder for a ResultsTable!

[dlegland]

Hi! a small follow-up, I have just pushed the refactoring of the AnalyzeRegions3D plugin to use a new MorphometricFeatures3D based on the same principle that the 2D equivalent.

Everything seems to work fine: same behaviour as before, and it is now possible to choose features programmatically. I am just not totally satisfied with management of options, but this will be for a future enhancement.

On the roadmap is also the refactoring of the dialogs for analysis of regions. This may take some time however.