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 https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/issues/113#issuecomment-2175430813, 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?

[ssh4net]

No. From "user" will be CIE XYZ D50.

[KelSolaar]

You probably need to explain your use case, as it looks like something you intend to use for a very specific workflow.

[ssh4net]

With my use case, I can omit OCIO but think that removing CIE XYZ D50 is not fair for other industries that can use OCIO.

One use case: Using xRIte, Adobe DNG profile, Lumariver, etc. All of them can give a user GUI to get CCM. By following Adobe DNG, Bruce Lindbloom, and others, users can get Camera to CIE XYZ D50 matrix.

All other steps involve XYZ -> desired color space transformation, and XYZ here is XYZ D50, not D60 nor D65. So, this adds one more step to apply the chromaticity adaptation matrix to D60 or D65.

If the user can understand what CCM he needs from the DNG profile or DCamprof and how this works, he can apply chromaticity adaptation. In that case, he can definitely skip OCIO if ACES is not a goal.

But, Holms! Why does the Color Management Standard not include Standard color spaces to give it more adoption and less chance that another standard will be created, and users in connections with different industries will need to jump between different color managements?

[KelSolaar]

Those industries are certainly free to add and implement the spaces they need. You need to keep in mind that the complain number 1 that was given about the ACES Configs was the number of Colorspaces and the Config size . It was not practical for users and devs. Yourself just above said "When the config has 5000 lines". We took a great deal removing a ton of Colorspaces to the point where we divided the size of the studio config by 3 and removed all the LUTs reducing disk size from 124mb to 70kb.

I hope that you can see that there we will always want a strongly motivated use case to add any new Colorspace. What you listed above are not uses cases, but software that use CIE XYZ D50 as an interchange/connection space. I would argue that if any of the software you listed wants/needs to interface with ACES, it should connect to ACES2065-1 rather than the ACES Configs having to implement all the possible connection spaces: It is not a tenable situation for us!

Why does the Color Management Standard not include Standard color spaces

I can flip the question : Why does ICC not include CIE XYZ D65? Why DNG does not provide matrices for CIE XYZ D65?

We are talking about the ACES Configs and what is useful for them: We removed Adobe RGB and Prophoto RGB in the new Configs because nobody felt they were required. MaterialX and yourself among others have given use cases for their usage, so we are most likely going to add them back.

[ssh4net]

Only 3! standard color spaces! CIE XYZ D50, Prophoto RGB and Adobe RGB and only to make OCIO standard better compatible with other industries.

VFX is not living alone, it still in connection with Advertising and Branding agencies. WEB and TV are not the only Advertising channels for brands. Prints are still used a lot! VFX also use a lot still photography and 3D scanning, so this is direct connection with photo industry.

And to be honest. Adobe was added support for ACES via their ICC color management couple years ago. That was allow to have some limited (enough) support for preview files in ACES color spaces.

Also all know that ICC just can't be extended to use open domain without moving to iccMAX that not sure if someone support at all.