Question: how to avoid hardcoding expected colorspaces for typical e.g: srgb image formats

[MrKepzie]

Maybe a silly question, but I've been wondering what's the expected behavior for a typical application that applies colorspace conversion to images that are "expected" to be in e.g: sRGB colorspace read in input. The sRGB colorspace does not have the same name in each config, so what should the application do ? Hardcode the colorspace name for every possible config "supported" by the app? Then if users load another custom config, they do not necessarily have that colorspace, resulting in the app failing to load the image properly. Same when encoding for example ProRes Quicktimes which may expected Gamma 1.8 or 2.2 depending on the profile. What's the best way to avoid hardcoding a bunch of colorspace names related to specific configs in the app ?

[dekekincaid]

Imho this should be left up to the DCC to decide. Nuke for example has around 26 different slots for different colorspaces which you can override with the colorspace of your choice from your ocio config.

https://learn.foundry.com/nuke/developers/132/pythondevguide/callbacks.html

[MrKepzie]

I see, so it's pretty much up to the user to do it

[lgritz]

I've wondered about this myself. "Leave it to the app" isn't a very satisfying answer, IMHO.

One thing I've contemplated is, basically, taking each color space in the config and running certain known xy values and intensities through transformations in and out in order to, essentially, deduce which arbitrary names correspond to which common color spaces. We know the color primaries and response curve of sRGB, so if oddball color space "foobar" transforms values identically, we can conclude it's sRGB. In this manner, an app could try its best to identify several color spaces regardless of name.

I admit I haven't been following the 2.2 conversation and PRs too closely, so I'm not sure whether anything made it into this upcoming release that would serve directly as a "what are the color primaries of this named color space" query or other relevant helpers. So apologies if this is all solved at this point.

[MrKepzie]

Also for example any type of Gamma reported from image metadata as well that the app should try to honor (that for example OpenImageIO properly reports in oiio:ColorSpace and GammaCorrected) I know some apps are even adding metadata to Quicktime streams with named colorspaces (of who knows what OCIO config) to their file.... which then makes it really hard once these file are in the wild. How is then the receiving downstream application supposed to guess where the config came from, the only thing it can do is tell the user the name of the colorspace, that it may hopefully support but with a likely different name.

I do not even mention all the user-erroneously encoded Quicktimes that come out of NLEs etc... where you never know the YUV colormatrix used in the file and where most players make very rough guess about what's in the file.

To me the problem is 2-fold:

• How can apps standardize tagging of OCIO colorspaces in image/video containers
• How can apps then properly understand each other with similar colorspaces that have different names across different configs

[lgritz]

There has been some related discussion jointly by the OpenEXR and OpenColorIO groups about how exr files ought to identify their color spaces correctly. I think what you're getting at, @MrKepzie, is just the generalization of this idea to additional formats and use cases.

[lgritz]

These seem to be related topics: https://github.com/AcademySoftwareFoundation/OpenColorIO/issues/1399 https://github.com/AcademySoftwareFoundation/OpenColorIO/issues/1621

[MrLixm]

If I may and If I understand properly the question, I also raised an issue for having at least a way to define what is the sRGB colourspace in every config in https://github.com/AcademySoftwareFoundation/OpenColorIO/issues/1667

[MrKepzie]

Thank you for the references, they indeed refer to the same interchange issue. The built-in configs is definitely a good way to go, at least to provide a good consistent default behavior for apps that supports OCIO and users that don't really know about OCIO configs. Having a built-in standardized sRGB as mentionned in #1667 is a good idea, but does not cover every cases and does not build a path forward to have a better interchange.