Ticket #1978 (closed defect: moved)

Opened 6 years ago

Last modified 4 years ago

Create a measurement service

Reported by: bdezonia Owned by: bdezonia
Priority: major Milestone: imagej2-b8-analysis
Component: ImgLib2 Version:
Severity: serious Keywords:
Cc: christian.dietz@…, leek Blocked By:
Blocking: #1519


We could use a service in Imglib that facilitates the creation and reuse of measurements of data sources. For example the mean value of an Img, or the convex hull of a RegionOfInterest. The service should cache some commonly used measures, recalc measures when underlying data changes (optional), allow one to name and retrieve and forget measures, etc. It should also define a protocol for other developers to create new measures that can be easily slotted in. Ideally it would pass over input data a minimum number of times in calcing values.

The Knime developers want to see this also and have contributed their feature measurement code (in the knip_features branch of imglib) as example code to support in some fashion and to inform the design of this service.

Barry played with some ideas on the measure-engine branch too some time ago. There were related fiji-devel emails too. And there was the creation of the measure2-experiments branch to begin fleshing out something going forward.

For a partial history see ticket #1384.

Change History

comment:1 Changed 6 years ago by bdezonia

In a private email with Christian Dietz I asked what he is looking for in a measurement facility. Below is his response.

For us a feature measurement service is the following:
Compute on a certain IterableInterval/RandomAccessibleInterval (which may result from a labeling, segmentation, certain roi definition, overlay) a set of numerical features:

  • First order statistics like mean, std. dev, kurtosis, etc.
  • Texture features like Haralick, Tamura
  • Zernike Features
  • Shape Descriptors
  • Geometrical Features (Circularity, Convexity, Extend, Size, Perimeter etc)
  • ... many more out there

If you for example take a labeling and calculate these feature for each region of interest (or the resulting iterableinterval), you in the end get a table, each row containing all features (or measurements) for a certain region of interest (see Image Segment Features in KNIME, e.g. example flow HCS on tech.knime.org/community/image-processing).

What would be cool (dreaming):

  • Avoid redundant computations (e.g. if you compute the mean on a certain iterable interval you don't need to recompute the mean again for std. dev. or if you compute convexhull, you dont need to recomute this again etc).
  • Easy extendible (maybe with a service?)
  • Annotatable classes (Simply write a class against a certain interface and this class could be a "FeatureFactory" then you annotate some methods/attributes which then will be used as features like

@Feature(Name="Mean", Dependency="none")
double mean = 0.0;

We use these features (as well as CellProfiler for example) for classification/clustering/measurements/statistic issues afterwards.
I think how we define such FeatureFactories/MeasurementServices also heavily depend on the definition of ROIs in ImgLib2 (e.g. RandomAccessibleInterval vs. IterableInterval).

comment:2 Changed 6 years ago by bdezonia

  • Cc leek added

comment:3 Changed 4 years ago by curtis

  • Status changed from new to closed
  • Resolution set to moved
Note: See TracTickets for help on using tickets.