New rendering settings specification

[dominikl]

The render plugin is a good starting point to play around with different ideas. Wonder if we should have an 'experimental' branch maybe? /cc @jburel @dgault @francesw

Here's a first attempt, kind of a hybrid of the current render plugin output and the current NGFF draft specification
(code see draft PR #54 ):

{
    "channels": {
        "0": {
            "active": true,
            "color": "00FF00",
            "color-format": "hex",
            "color-type": "rgb",
            "label": "CEP192-M",
            "window": {
                "end": 16633.45703125,
                "max": 16633.45703125,
                "min": 0.0,
                "start": 0.0
            }
        },
        "1": {
            "active": true,
            "color": "FF0000",
            "color-format": "hex",
            "color-type": "rgb",
            "label": "CENT2",
            "window": {
                "end": 103353.1796875,
                "max": 103353.1796875,
                "min": 0.0,
                "start": 0.0
            }
        }
    },
    "color-model": "color",
    "default-dimension-0": 0,
    "default-dimension-1": 0,
    "dimensions": "zt",
    "plane": "xy",
    "version": 3
}

Instead of defaultZ/T it's more generic default-dimension- and what the dimensions actually mean is specified in dimensions, what a plane actually means likewise in plane. Also the color can be more generic. See above for the common html color specification, but it could also hold lookup tables (e.g. specified by a name or maybe url, etc.), e.g.

    "channels": {
        "0": {
            "active": true,
            "color": "glasbey",
            "color-format": "name",
            "color-type": "lut",
            "label": "CEP192-M",
            "window": {
                "end": 23900.765625,
                "max": 23900.765625,
                "min": 0.0,
                "start": 0.0
            }
        },
        ...
    }

Edit: Actually default-dimension- should better be a list, not several keys.

[jburel]

other elements like mapping family needs to be added: this assumes linear mapping
This could also be an opportunity to re-activate the "co-domain" transformations i.e. changes in the device space

Introducing an experimental branch will make sense otherwise we will have a long open PR

[sbesson]

A few high-level thoughts, I think the development workflow will come across several repositories (ome/omero-cli-zarr#88 is another example). Completely fine from my side with having an experimental/development branch where PRs get integrated more quickly.

A few additional considerations:

• wherever appropriate we might still want to be upfront about the in-progres nature of the work. For instance, suffixing the spec version with a dev suffix or similar
• even if working from an integration branch, I think we might want to go for pre-releases/dev releases that we can start consuming internally

[will-moore]

Maybe for default dimensions, this might be nicer:

"default_dimensions" : {
  "0": 10,
  "2": 2
}

Also, note the discussion of naming style at ome/ngff#54
Strong preference for color_format over color-format etc.

[jburel]

for the naming discussion, I am wondering if we should not follow the schema.org rule i.e. colorFormat

[jburel]

concept of group should be supported. We will need support for multiple groups

group : {
  "name":  "group1",
  "visible": True,
  "indexes": "1, 2, 5",
  "type": "channel" (could be angle)
}

[jburel]

Looking at the BDV xml files, they need support for AffineTransform for each viewSetup. A viewSetup is either a channel or an angle. There is a transform per timepoint.

[jburel]

The physicalSizeX etc. will need to be known for scale bar but I assume that will be stored elsewhere in the file

[jburel]

Resolution level, viewport could be considered

[will-moore]

@jburel If you're suggesting that the ngff spec uses a different naming convention than snake_case then you should suggest that on ome/ngff#54 since I don't think we want different conventions for different parts of the spec.
I don't quite understand the relevance of https://schema.org/ here. Are you thinking that we might want to extend the schema.org vocabulary with our ngff terms?

[jburel]

My comment is more general that this specific issue. The suggestion of following schema.org is coming from the fact that others efforts e.g. bioschema.org, ro-crate follow that convention so it might make more sense to follow similar rule instead of the snake_case convention

[joshmoore]

Are you thinking that we might want to extend the schema.org vocabulary with our ngff terms?

There's a pretty good likelihood that we will eventually want to incorporate schema.org types into our metadata, but that's true for other ontologies & vocabularies as well. The likelihood of being able to find a set which follow the same naming style is basically zero.

[jburel]

I am currently looking at https://www.ebi.ac.uk/spot/oxo/docs/api for a project: mappingTarget is for example a field returned

[dominikl]

With the recent suggestions added, it would look like these:

{
    "channels": {
        "0": {
            "color": "00FF00",
            "color_format": "hex",
            "color_type": "rgb",
            "label": "GFP",
            "mapping": {
                "coefficient": "1.8",
                "family": "exponential",
                "reverse": "False"
            },
            "noise_reduction": "False",
            "window": {
                "end": 1542.5789794921875,
                "max": 1542.5789794921875,
                "min": 0.0,
                "start": 0.0
            }
        },
...
    },
    "color_model": "color",
    "default_dimensions": {
        "0": 0,
        "1": 0
    },
    "dimensions": "zt",
    "group": {
        "0": {
            "indexes": [
                "0",
                "2"
            ],
            "type": "channel",
            "visible": "True"
        }
    },
    "plane": "xy",
    "version": 3
}

Not sure where to put the viewSetup.

[sbesson]

A few initial thoughts while reading #55 (comment) (without having looked at the notes):

• I see the channels index is changed from 1-based index to 0-based index. No objection to this as long as we agree this is the way forward and do not change it back again
• does the current draft of the rendering model support sparse channel settings or should all channels be specified? In the latter case, it might be possible to choose between a dictionary (assuming the key is the channel index) and a list
• the new color_format/color_type properties might be think we might be moving towards defining a color dictionary rather than a series of flat keys?
• dimensions/default_dimensions: is there an expected overlap/relationship with the axes metadata? Should these default settings also be within the group objects?