omero fields optional

[will-moore]

Fixes ome/ngff#192

ported from ome/ngff#297

[github-actions]

Automated Review URLs

• Readthedocs

[jo-mueller]

@will-moore small bump here to have a look at will-moore#2 to have this move forward :)

[jburel]

This could also be an opportunity to fix the model value color is not a value used by omero it is rgb

[will-moore]

All the color values shouldn't include the #.
Definition below is:
(string) String of 6 hexadecimal digits specifying the color of the channel in RGB format.

[will-moore]

@jburel We're not changing the color definition here. This PR should not be a breaking change. We're just making some fields optional. The definition for color is:

(string) String of 6 hexadecimal digits specifying the color of the channel in RGB format.

No mention of OMERO.

[jburel]

to clarify I am referring to "model": "color" . We are using "omero" metadata but the model in ome-zarr is color and the omero-model is rgb.

[jo-mueller]

@jburel @will-moore is there a central place where the fields and possible values of the omero metadata model are documented? There's a link in the spec text but explains some fields, but not all (i.e., family, etc)

[joshmoore]

@will-moore @jburel: would you like to get this into one of the upcoming .dev versions? And if so, when would you be thinking?

[will-moore]

I actually thought this had made it into v0.6.
So, yes. As soon as possible, thanks.

[joshmoore]

@jni is leading dev1 so I'll defer. Otherwise we can get it on a board for dev2 and discuss.

[jni]

@will-moore there's a number of unresolved comments here. (log->logarithmic, removing "gamma", removing "#" from the color). Otherwise, I'm happy for this to go into 0.9.dev1 which is due ~end August. Note also that I don't have merge rights in this repo 😅 so someone else will have to do so, presumably after 0.6 is out. (Although, given the backwards compatibility of the change, I would not be opposed if it went into 0.6.rc1/final. CC @jo-mueller)

[will-moore]

I think that is all the fixes done.
I was checking https://omero.readthedocs.io/en/stable/developers/Web/WebGateway.html#imgdata for any reference to coefficient and family but it has no info on these and actually has less info than is in these docs themselves so I've removed that link.

I also have therefore also removed the coefficient and family fields from the omero block since these have never been defined and never used AFAIK.

[jni]

Great. @will-moore do you want to mark this as ready for review then?

@jo-mueller what do you think about shipping this with 0.6 final?

[jo-mueller]

@jni sorry it took me so long to catch up here. To summarize:

Feature	Version 1 (Before)	Version 2 (After)
omero Metadata	Optional, but if present, channels MUST be included.	Not explicitly mentioned.
channels Array	MUST exist if omero is present.	Optional. Length SHOULD correspond to the size of the respective channels axis, if present.
Fields in channels	Every object MUST contain color and window.	All fields are optional. MAY include color, label, active, window, or inverted.
color Field	MUST be a 6-digit hexadecimal RGB string.	MAY be a 6-digit hexadecimal RGB string.
window Object	MUST contain min, max, start, and end.	If provided, MUST contain start and end. min and max are optional.
Additional Fields	None.	MAY include label (channel name), active (display toggle), and inverted (pixel rendering).
Data Types	Implied integers for min, max, start, and end.	Explicitly allows floating-point numbers for min, max, start, and end.
RFC 2119 Keywords	Uses MUST for all requirements (strict compliance).	Uses SHOULD, MAY, and MUST (flexible, with conditional requirements).
Purpose	Strictly defines rendering requirements (color and window).	Expands to include usability, customization, and rendering flexibility.

Arguments for adding:

• Syncs spec with what was already in the schemas (i.e., label, active, inverted have been in the schemas for a while(?)), and this matches the text with them
• All changes are relaxing requirements, so non-breaking

Arguments against:

• timing?

[jo-mueller]

After some more thought, since I made a quite verbal statement about no new changes in 0.6, I'm hesitant to eat from the forbidden fruit and slip in this (very reasonable!) PR 🙈

I think my headcanon for moving this forward would be:

1. Get the feedback from @jburel - I think there were some unresolved comments further up?
2. I agree that the requirements are unreasonably tight - but writers will probably circumvent this by writing some reasonable defaults, i.e., for min/max or start/end. Making these fields non-required would make these defaults a bit more opinionated as they are now. Aside from the fact that validators would need to update code.
3. Get this PR in first thing after the 0.6 tag?

[lubianat]

related to the redo of omero fields, here is an insteesting scenario where color is being used as a local ID for a channel

https://github.com/JurgenKriel/macro_candi

Channels are resolved by colour, not index. canmac/io/channels.py reads the OME-Zarr omero metadata and matches hex colours, so channel order changes don't silently mis-assign data. Edit COLORS there for your fluorophores.

this touches on both the need of a channel spec and on different uses of the omero metadata block