Labelings / Labeling

BSD 2-Clause "Simplified" License
4 stars 2 forks source link

Labelings lose all information about values in original images #16

Open gselzer opened 2 years ago

gselzer commented 2 years ago

Here is a MCVE, on labeling 0.1.12

from labeling.Labeling import Labeling
import numpy as np

data = np.zeros((4, 4), np.int32)
data[1, 1] = 4

print('Original data:\n', data)

img, metadata = Labeling.fromValues(data).get_result()

print('Data from result: \n', img, vars(metadata))

And the printout on my machine, running Ubuntu 20.04:

(napari-imagej-dev) : gselzer@gselzer-OptiPlex-5090 ~/code/imagej/napari-imagej (roi-support*) [napari-imagej-dev] »
python tmp.py                                                                                                                                                                                                                                          #  0 {2022-05-05 10:18:57}
Original data:
 [[0 0 0 0]
 [0 4 0 0]
 [0 0 0 0]
 [0 0 0 0]]
Data from result: 
 [[0 0 0 0]
 [0 1 0 0]
 [0 0 0 0]
 [0 0 0 0]] {'version': 2, 'numSets': 2, 'numSources': 0, 'indexImg': None, 'labelMapping': {}, 'labelSets': {'0': [], '1': [1]}, 'metadata': None}

As the MCVE shows, looking at the result shows no trace of the value 4.

I do concede it is tricky to retain the values in the result image from the original data given to the Labeling, e.g. when multiple input images have the same non-zero values. But, if this is the behavior, it should be documented somewhere. And, despite the limitations, I'd think we should try our best to ensure that you can get the original values from the result.

@tomburke-rse what do you think? Am I missing something?

tomburke-rse commented 2 years ago

You missed nothing. I can see that adding documentation for that is a good idea. The reasoning behind not retaining old information is that the original label does not hold intrinsic value beyond separating the label from the other labels in the image. I see no reason to add the complexity of retaining information because I would not know how to handle the very likely case of two images with the same label being added, possibly even at the same spot. Are they different? Are they the same? I cannot tell from the library side. What I can see is to add the option to add a static mapping or a mapping function similar to the Java library. Then you could use the mapping to reconstruct from result back to data

gselzer commented 2 years ago

What I can see is to add the option to add a static mapping or a mapping function similar to the Java library. Then you could use the mapping to reconstruct from result back to data

This sounds great!

tomburke-rse commented 2 years ago

@gselzer is this just something you noticed and wanted clarified or does this produce actual problems for anything else? Just so that I can prioritize the issue.

gselzer commented 2 years ago

This is not urgent, it just affects what I can assert in my napari-imagej conversions.

See https://github.com/imagej/napari-imagej/commit/6a67a661f9bf4f9de3689ce0acd8d04bdcef2c58#diff-9e1a0edede8c7f299251e523eb4010ed868090b397db9bf7881c18ab3dfdbf18R160

tomburke-rse commented 2 years ago

I see, thanks @gselzer! The way you assert is looks absolutely right though. At least for one source image.

gselzer commented 2 years ago

I see, thanks @gselzer! The way you assert is looks absolutely right though. At least for one source image.

Thanks for looking over that function :sweat_smile:. I think the assert covers the use cases for napari-imagej, since we will only ever be adding one source image to the Labeling.