Mask color array #65
Mask color array #65
Conversation
| the `color` key is another JSON object in which the key is the pixel value of the image and | ||
| the value is an RGBA color (4 byte, `0-255` per channel) for representing the object: | ||
| the `color` key is a JSON array in which the index is the pixel value of the image and | ||
| the value is an RGBA color (4 byte, `0-255` per channel) for representing the object, or `null` if no color is set: |
There was a problem hiding this comment.
We should say something about how the 4-bytes are converted to a single int, e.g. signed/unsigned, big/little endian
|
Note that the microservice uses ROI IDs as pixel values for overlapping masks. |
|
I thought it was going to use a sentinal value e.g. -1 or max-int? |
|
That's masks per ROI rather than two overlapping ROIs. To reduce the ambiguity, using the ROI ID everywhere might be safer (Rois and Masks could have the same ID). |
|
Using ROI-IDs instead of integer labels makes it easy for omero-ms-zarr and other utilities to export the mask from OMERO, but it means a user has to map each ROI-id to a label-index if they want a traditional label image. |
|
It would be easy to make that configurable. It would be possible to wholly prohibit offering ROI ID pixel values, I'd naively guess that the ROI→index lookup would be fast, but if their code is thinking in OMERO ROIs then of course they have to map the indices back to the ROIs. |
|
I've made a second proposal in |
|
Closed in favor of #71 |
See #62
Converts the label-color dict to an array or colours.
Also require the labels to be integers
See also an alternative in #68