Create scriptable 'Add cell measurements' command

[petebankhead]

Feature request

Is your feature request related to a problem? Please describe.
QuPath's built-in cell detection makes measurements at the same time and at the same resolution as detection.

This isn't sustainable as we support a wider range of cell detection methods.

That's why the ObjectMeasurements class exists.

This is used internally by the QuPath StarDist extension - but it still has the basic form of 'make measurements at the same time as detection'.

I think we need to decouple these two things, or at least ensure that it's possible to add cell measurements after detection.

Describe the solution you'd like
A new, scriptable command to add cell measurements.

Describe alternatives you've considered
Build upon the existing 'Add intensity features' command.

I can think of a few relevant considerations:

• We want shape measurements as well, not just intensity measurements (although perhaps the command could be generalized to include shapes too)
• 'Add intensity features' can simultaneously give too many and too few measurements. We probably don't need the Haralick features generally, but do need the possibility of membrane measurements (possibly with control over thickness?).
• 'Add intensity features' tries to handle the tricky problem of arbitrarily large ROIs, by tiling. It is easier to code more imaginative feature measurements if we can assume that all pixels and binary mask can fit easily into RAM.
• 'Add intensity features' does not handle the different cell compartments currently (i.e. nucleus, cytoplasm, cell, membrane)

Additional context
In writing this, it's not clear to me if we should replace 'Add intensity features' and 'Add shape features' with a single, better command at the same time as trying to solve this issue.

A few extra considerations and complexities:

• We need to be able to handle color transforms (e.g. color deconvolution)
• We need to consider the resolution at which the measurements are calculated
• We need to think a lot about the measurement names; specifically, these need to be unique (since they are effectively stored in a map), and efficiently encode the key info (e.g. compartment, resolution, measurement type)

An occasional complaint is that QuPath's cell detection and the StarDist extension use different naming conventions.

This was a conscious decision, because the measurements weren't expected to be directly comparable - and so shouldn't be used interchangeably (e.g. when training a cell classifier).

But I don't think it was necessarily a good decision.

With default cell detection, you'd get

Nucleus: Hematoxylin OD mean

but with StarDist (i.e. ObjectMeasurements) you woul dhave

Hematoxylin: Nucleus: Mean

Both share the idea of splitting parts with colons... but inconsistently in most respects.

If we had a better convention, then this might also be useful to show measurements in a grouped way.

I suspect grouping first by compartment would be more sensible than by stain.

The closest comparable measurement from 'Add intensity features' would be

ROI: 2.00 µm per pixel: Hematoxylin: Mean

which also groups... confusingly.