Chromaticities should be a required attribute

[szeproka]

Working as in the CG industry for quite long now, and it is always a pain to know what is the original colorspace of any exr, without knowing before hand its export settings.

We always have to know or be be the author of the exr to know how to work with properly.

For example, exporting exr from Blender, we have no way to know what colorspace an exr is encoded in. You can only guess that it is sRGB encoded because you KNOW that it was rendered with Blender because you know it, or because you recognized the pattern of attributes in metadata like "Camera" and "Scene".

It would also be awesome if an attribute like "colorspace" or "gamut" existed, that auto translates chromaticities coordinates to their human readable colorspace like : 0.712999999523163 0.293000012636185 0.165000006556511 0.829999983310699 0.128000006079674 0.0439999997615814 0.321680009365082 0.337669998407364 to : Aces Ap1 (cg, cc, cct, proxy).

Any info about how required attributes are chosen would be very helpful.

Thank you.

[lgritz]

We've found the chromaticities attributes to be really unreliable.

We'll probably make an official "ColorSpace" attribute that will be assumed to have the name of one of the official color spaces defined by the OCIO / color interop forum.

[peterhillman]

Perhaps a new attribute type could either contain either a canonical name of a standard space, or a set of chromaticity values for arbitrary/custom spaces, with the library supporting conversion between the two.

In any case I'm not convinced the attribute can be made 'required'. It would be fantastic if every tool and every user always understood exactly what colorspace images were in at every point in the pipeline, but that's not always the case. It would be better if the attribute is omitted unless the creator is confident the space is correct, rather than just using a default value or a guess. One reason that chromaticities is unreliable is due to some tools inserting incorrect default values just to have something there, and those are then propagated. Also, OpenEXRs that only contain matte channels, motion vectors, etc shouldn't have a color space.

There are actually very few required attributes. The Header predefines a set of attributes, largely the ones necessary to be able to read the pixel data from the file. If a file is missing those, for some reason, the library will assume default values on reading the file

[szeproka]

Hi Igritz, Hi peterhillman, and thank you both for your wise answers. I understand your points as I further inspected the chromaticities output produced by different programs (After Effects, Blender, Unreal, DaVinci) and found them not very consistent. Multiple chromaticities for sRGB, multiple chromaticites for ACES...

Nonetheless, even if unreliable, it would be useful to get a hint on how to interpret an exr.file. Even for matte channels, if they shouldn't have a colorspace, may be default chromaticities of ' 1 2 3 4 5 6 7 8' (or something else) could be defined after discussion.

Anyway, if anyone is interested, I'm working on a fork of exiftool that not only complete the hash of corresponding keys for DWAA and DWAB compressions (actually displayed as 'Unknown(8)'), but also add a new 'Colorspace' tag that displays a simple colorspace name if the found chromaticites match some that I manually added :

'0.712999999523163 0.293000012636185 0.165000006556511 0.829999983310699 0.128000006079674 0.0439999997615814 0.321680009365082 0.337669998407364' => 'ACEScg',
'0.7124263048172 0.293813675642014 0.180122509598732 0.807839155197144 0.125906214118004 0.0442668609321117 0.345702916383743 0.358537524938583' => 'ACEScg AMPAS S-2014-004',
'0.733956277370453 0.268055468797684 0.0164710879325867 0.972419202327728 -0.0559232085943222 -0.121274426579475 0.345702916383743 0.358537524938583' => 'ACES SMPTE ST 2065-1',
'0.639999985694885 0.330000013113022 0.300000011920929 0.600000023841858 0.150000005960464 0.0599999986588955 0.312700003385544 0.328999996185303' => 'sRGB',
'0.648453652858734 0.330852478742599 0.321197688579559 0.597844362258911 0.155884742736816 0.0660382062196732 0.345702916383743 0.358538597822189' => 'sRGB IEC61966-2.1',
'0.648438155651093 0.330855995416641 0.230178281664848 0.701570689678192 0.155893236398697 0.0660597011446953 0.345702916383743 0.358538597822189' => 'Adobe RGB (1998)',
'0.734698474407196 0.265301525592804 0.159599378705025 0.840400636196136 0.0365994907915592 0.000106911851617042 0.345702916383743 0.358538597822189' => 'ProPhoto RGB',
'0.708493113517761 0.293545454740524 0.190204367041588 0.775371015071869 0.129246488213539 0.0471405945718288 0.345702916383743 0.358537524938583' => 'Rec.2020 Gamma 2.4',
'0.734700918197632 0.265299111604691 0.115173131227493 0.826431155204773 0.156608253717422 0.017684992402792 0.345702916383743 0.358538597822189' => 'Wide Gamut RGB',

Thank you for your attention

[peterhillman]

I'm interested, particularly on which spaces you chose, and how you implement tolerance to permit non-exact values. Many camera manufacturers define their own gamuts: should those be included in any standard attribute definition?

It would be good to know if there are spaces which have standard RGB values but a different white value (e.g. ACES but with D65 white point). If that's common then an attribute which uses named spaces might need separate strings for the RGB gamut and the whitepoint.

The chromaticities attribute defaults to Rec709/sRGB, so it's surprising that there's variation there. It might depend on how attributes are transported through software which reads and writes EXRs but has its own internal metadata representation. It's possible values are being truncated or rounded as they are converted between floating point and string representations.

Getting into the weeds a bit, but I suspect most standard spaces define their chromaticities using decimal values, rather than their nearest floating point equivalent, so perhaps chromaticities should be encoded as rationals rather than floating point, (e.g as 64/1000,33/1000 for the x,y coordinate of Rec709 red, and 1/3,1/3 for the white point of XYZ space)

[szeproka]

Hi again, thank you for your interest!

I chose spaces that I found most common in wy work, and spaces that I found exact chromaticities for. I mostly brute force it.

For example, I exported multiple exrs from After Effects and Unreal in different working spaces, read their chromaticities with exiftool (as values are rounded in exrinfo), and copied them in my custom OpenEXR.pm of exiftool source code. I plan to manually add colorspaces as I found new ones across my journey. Maybe it is kind of dumb but I try to be pragmatic and use it as atool to work. Maybe it could be a collaborative thing to fill this empirical chromaticities corresponding table, as it is certainly already partly done by compositing softwares like After effects, davinci or Blender, that sometimes rightly auto detects and translates colorspaces of textures.

I didn't know that camera manufacturers defined their own gamut. Thinking of that I think that it could be interesting not to try to find the closest colorspace, as keeping the difference could add info about the exr origin.

More clearly: if these particular chromaticities are found, it means that is the RGB from Arri, from this camera. Same way for other sRGB chromaticities from CG softwares : this is the sRGB of After effects, this is the one from Unreal, etc...This way it would also carry the information about the origin of the exr.

I agree that it could be interesting to separate gamut from white point, as they are always the last two floating points values of the chromaticities array.

If possible, I think that your idea to express chromaticities as rationals instead of floating points is really great ! This way we could nullify the floating points conversion problems.

Le jeu. 1 août 2024 à 00:35, peterhillman @.***> a écrit :

I'm interested, particularly on which spaces you chose, and how you implement tolerance to permit non-exact values. Many camera manufacturers define their own gamuts: should those be included in any standard attribute definition?

It would be good to know if there are spaces which have standard RGB values but a different white value (e.g. ACES but with D65 white point). If that's common then an attribute which uses named spaces might need separate strings for the RGB gamut and the whitepoint.

The chromaticities attribute defaults to Rec709/sRGB, so it's surprising that there's variation there. It might depend on how attributes are transported through software which reads and writes EXRs but has its own internal metadata representation. It's possible values are being truncated or rounded as they are converted between floating point and string representations.

Getting into the weeds a bit, but I suspect most standard spaces define their chromaticities using decimal values, rather than their nearest floating point equivalent, so perhaps chromaticities should be encoded as rationals rather than floating point, (e.g as 64/1000,33/1000 for the x,y coordinate of Rec709 red, and 1/3,1/3 for the white point of XYZ space)

— Reply to this email directly, view it on GitHub https://github.com/AcademySoftwareFoundation/openexr/issues/1783#issuecomment-2261570959, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH4GWNDLAJEPTTUOCJJM6YTZPFRCFAVCNFSM6AAAAABLSGWWQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRRGU3TAOJVHE . You are receiving this because you authored the thread.Message ID: @.***>

[meshula]

Bugs and misinterpretation of colorimetry and its use in EXR files has permanently poisoned the use of the existing attributes.

At this point I don't think we are ready to stray from the idea that EXR files contain either raw data, or scene referred data. Certainly when it comes up in TSC meetings, there is consensus not to encode camera colorimetry in an EXR file.

As such, I would advocate a new string named attribute that supports a named linear color space, from the table developed by the ASWF Color Interop Forum. https://wiki.aswf.io/display/CIF/Color+Interop+Forum+Home

If we do want to encode primaries and whitepoint beyond that, then we should deprecate the existing attributes, and name new ones and declare that the new attributes if they exist, must not be filled with nonsense.

[lgritz]

As a practical matter, I don't think we should absolutely require it to be on the CIF list, but rather that the CIF list names should always mean what they say, if used. It should be ok to use any OCIO built-in or in-config name (+1 for a second standard attribute naming the config that is being referenced, if it's neither CIF nor built-in).