Please add spaces such as *Adobe RGB*, *Prophoto RGB* (RIMM/ROMM), *Widegamut RGB*, etc...

[ssh4net]

That was a discussion about this on Slack, but I want to open an issue for this.

Default ACES config must include Standard color spaces even if they are legacy or not used in VFX industry.

ACES that want to be a standard for new media also have a duty to join separate camps, VFX, Graphic Design, Photographers, etc.

Obeying some standard color spaces, that can be used in other industries, like Adobe RGB (that included in ALL DSLR and Mirrorless cameras prior to 2023 release date). ProPhoto RGB (RIMM/ROMM) that is internal wide gamut color space for most Adobe Apps (good or not, is the same industry standard as proprietary Nuke) that have almost the same as ACEScg or BT.2020 gamut size.
Some can be used in research papers or in resources about color science. For example https://www.colour-science.org/apps/ Have a lot classical, legacy or other color spaces from Different industries, that make this package usable for everyone, not only several holliwood companies.

Looking how many camera specific color profiles already included in ACES configs, 3-5-10 standard color spaces not make ACES config heavier or easier to manage. But can help to find a piece for all who need to work with colors.

[KelSolaar]

Hey @ssh4net,

Thanks for writing this issue! I will give some historical context and quote what I wrote on Slack Discord:

OpenColorIO was designed by Sony to solve VFX industry problems nothing else. If you look at original configs from Jeremy, you won’t find Adobe RGB and even ProPhoto because they did not use them. When we built the ACES configs with HPD et al., we decided to add those spaces because indeed they were used by photographers and they were part of the Adobe workflows. Now, when we worked on the new Configs, one of the first issues to address was the bloat. The Working Group, which includes people from ILM, Dneg, Framestore, Wētā, etc…, decided to remove those two spaces among many others because the aforementioned companies were not using them.

I don't have a strong opinion as to whether those spaces should be added or not. I personally don't use them and when I need, which probably happened two or three times in the past decade, I pop a matrix wherever relevant! Our app that you link above makes that trivial and it can also emit YAML for OCIO now.

That being said, I certainly see the value for photographers, especially ProPhoto RGB, which is why they are in the legacy config, so I would be fine either way.

A quick side note and this might be a language/formulation thing but there is some commanding tone in your writing that might not be well received: "must include", "have a duty", "Obeying".

[carolalynn]

Hi @ssh4net - thank you for the issue. We are definitely not against adding color spaces to the configs, but it would be helpful for us if you could be a bit more detailed about your specific use case. Are you building a specific application that could benefit from these spaces? You've listed a few, but also say "etc" - is your list complete with Adobe RGB and ProPhoto RGB? Do you need both RIMM and ROMM?

Also, by definition, some of these are display-referred spaces (Adobe RGB, ROMM) - we would need to discuss where they fit into the configs, as they are designed around scene-referred, high dynamic range workflows (ACES). We have a few output-encoded spaces in the "texture" category - but I'm not sure that is the correct place for spaces such as these. Do you have thoughts? Again, a specific use case would really help us here, as we design for ease of use for an end-user.

Apologies for the delay on reply, and thanks for your time and input!

[ssh4net]

Hi @carolalynn22

Sure there is a some examples of use:
• Legacy design materials including corporate identity/branding. This sources in most cases can are used sRGB but because any graphic designer know that sRGB even smaller than CMYK gamut in some areas, so there is some chance to have received the data in Adobe RGB, Wide Gamut RGB and some other more or less legacy color spaces.
• Photo cameras before 2023. Most of them have sRGB and Adobe RGB color space switches. When direct to jpeg shooting rarely used in big productions, hobby or indie studios can use RAW+Jpeg captures or even jpeg captures for photogrammetry or references. And this is a main reason why Adobe RGB still makes sense.
• ProPhoto RGB (aka. RIMM, aka ROMM). That one probably less used outside photography. But this is internal wide gamut color space in Adobe Apps. And as soon as most of commercial raw processors is not support any VFX color spaces as ACEScg or BT.2020 it only one that good choice to use in HDRI capture pipelines. Between sRGB, near the same Adobe RGB and ProPhoto RGB last one is a clear winner, because it have almost the same as ACEScg gamut.

Old Thomas ocio config had a right definitions for all that spaces:
Utility - for linear representation and Texture - for linear and gamma transformed.

Just maybe for ProPhoto RGB Texture in addition to standard 1.8 gamma and D50 add Adobe modification of ProPhoto RGB, often named Melissa RGB that use ProPhoto RGB primaries and sRGB D65 white point and sRGB gamma transfer function. Because that is a usual ProPhoto RGB color space outputs from apps like Adobe Lightroom.

[ssh4net]

Can we resurrect this thread?

Yesterday I found that even XYZ at D50, that is a reference color space for a lot of color math operations (for example classical camera raw processing) just absent in standard OCIO config.

Well, if someone understands a difference between XYZ D50 and XYZ D60 and why them from, is probably not a problem to write ad-hoc replacement for OCIO part of color space conventions. But again, why not have standard color spaces in official OCIO config even if they less common for VFX.

XYZ (D50)
Adobe RGB (D65)
Prophoto RGB (D65) (RIMM/ROMM RGB)

Don't think this three configs (or 5 if include gamma encoding) will increase OCIO config so much.
Some config names have longer names than those three 😅

[KelSolaar]

We are discussing about Adobe RGB and Prophoto RGB again.

@doug-walker for VIS.

[ssh4net]

@KelSolaar @doug-walker
Please do not forget XYZ D50.

Adobe DNG pipeline usually has matrices depended to this color space.
When later OCIO can be used.

[KelSolaar]

Support for Adoge DNG SDK specificities seems out of scope of what we are trying to achieve here. I can count the numbers of people requiring this in the context of OCIO on the fingers of a Na'vi hand :)

[ssh4net]

Yes, i can understand your irony. And for VFX users XYZ D50 have less sense now when ACES become a standard.
But OCIO slowly adopting in other industries too.
Why not make interchange easier for everyone?
Not for big software houses, but also for researchers and independent studios that have connection with VFX but not an VFX.

[carolalynn]

Hi Vlad, Thanks for the feedback. At a certain point, it is on users of ocio to add the spaces they require for their workflows. As Thomas mentioned, we are talking about adding Adobe RGB etc as a part of the NanoColor initiative, but we already support XYZ D65, and supporting arbitrary white points as built ins gets cumbersome at best. It’s really easy to add in d50 to your configs, and at some point, we might have a place for community supported public configs for different workflows. But for our core built in ocio configs, we have to draw the line at core workflows, until the user base you speak of grows. Hope that makes sense!

…

On Tue, Jun 18, 2024 at 09:49 Vlad (Kuzmin) Erium ***@***.***> wrote: Yes, i can understand your irony. And for VFX users XYZ D50 have less sense now when ACES become a standard. But OCIO slowly adopting in other industries too. Why not make interchange easier for everyone? Not for big software houses, but also for researchers and independent studios that have connection with VFX but not an VFX. — Reply to this email directly, view it on GitHub <#113 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMPHU2FE4XZUBQ6YSTWC5CTZH7RA5AVCNFSM6AAAAABJFOGZE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZVGQZTAOBRGM> . You are receiving this because you were mentioned.Message ID: <AcademySoftwareFoundation/OpenColorIO-Config-ACES/issues/113/2175430813@ github.com>

[KelSolaar]

Yes, i can understand your irony.

I certainly include myself in that hand, that leaves 3 fingers! :)

CIE XYZ D50 is not useful by itself: If some user wants to use one of the DNG ColorMatrix1 or ColorMatrix2, he WILL HAVE to edit the config manually because there is not a world where we can add all the existing and future DNG matrices, at this point he might either add the CIE XYZ D50 matrix himself or recompute ColorMatrix1 so that it directly maps to ACES.

[ssh4net]

There is no need to try to include all possible DNG matrices. And in any case, they are from/to XYZ D50.
Just CIE XYZ D50 can be from the step before OCIO.

I'm curious why this works so smoothly in your Colour-Science when in OCIO is not.

@carolalynn If OCIO config was modular, that was easier. When the config has 5000 lines, and information is spread across these lines randomly (for those unfamiliar with OCIO), that becomes a bit complicated.

[KelSolaar]

Even if it is a single ColorMatrix1 or 2, the user would need to add it to the config right? Or are you suggesting that we should also add them?

For what it is worth, the 2.1 profile CG and Studio configs are 593 and 1547 lines respectively.

I'm curious why this works so smoothly in your Colour-Science when in OCIO is not.

I don't understand what you meant here?