I’m wondering if there is a way to check the colorspace of an imported CG sequence, more importantly if it’s in Aces or not ?
Or at least the second part, not exactly the colorspace just to check if the imported sequence is in Aces ?
1 Like
Hi @hyperviktor,
You could check the file metadata if there is anything relevant but if not, it is generally impossible.
As an example, for an EXR file, you could check the chromaticities and acesImageContainerFlag values. See the aces_attributestructs.cpp file in the reference container.
Cheers,
Thomas
1 Like
As far as I know, most common primaries used in CG rendered EXRs are sRGB, AP0 and AP1. And probably P3, I guess.
The first three can be easily distinguished by eye. AP0 looks greenish when viewed on a regular computer display. AP1 looks closer to normal, but too desaturated. And sRGB looks normal. But I wouldn’t rely on eye only if there is a chance the primaries are P3D65, because it looks just a bit less saturated than sRGB.
If it looks like highly desaturated, but not green, there can be another (rare) option: some camera wide gamut primaries. You can only guess if it’s AP1 or camera gamut.
XYZ also looks greenish, but I’ve never heard anybody used it for CG renders.
Arnold by default renders in ACES but would be good to be able to double check, since the normal colorspace for CG rendered EXRs is AcesCG , but if used on a non aces render not sure what would happen.
ACES has multiple RGB colourspaces thus one needs to be careful about which one is being talked about, e.g. ACES2065-1 with AP0 primaries or ACEScg with AP1 primaries.
Cheers,
Thomas
1 Like
Thomas, that’s what I’m trying to figure if there is a way to check which one is a particular render in ?
You don’t always know but most importantly would be very useful to be able to check if said render is in said colorspace.
When you receive a render from any source, they will tell you what colorspace it is in and you handle it accordingly, but how to check if that info is accurate?
The only way I can think of to double check that is to ask for a reference image (with display transform) in sRGB from that same source so you can compare with the same display transform. Provided said source knows that sent sRGB image looks correct.
Not a bad idea, so in essence, the sRGB and the Aces would look the same if each imported in their respective colorspaces ?
Exactly. If the sRGB file was saved with the ACES Output sRGB and you use the same transform on the EXR they should match when the chosen IDT is correct.
1 Like
Probably would be good to clarify whether this is a render we are taking about or a film plate. A render will be in the scene-linear working color space. So if it’s ACES that would be ACEScg, not ACES-2065-1. For a film plate it’s more Wild West as it will be whatever the person set it to when the output the file. It should be in ACES-2065-1 for file interchange.
Render from Arnold, and yes, it should be in ACEScg, but I’m trying to find a way to verify.
Do you know the OCIO configuration that was used, ie whether it was ACES? If it was ACES then 100% the render is in ACEScg. That’s just what the render will do.
The place where it becomes questionable is when it comes from a program like Nuke where the user can set the output colorspace. In Maya a render is just always in the scene-linear working space determined by the OCIO configuration. There is no user setting to get wrong or right.
On an EXR from Arnold specifically, you can look at the exr/arnold/color_space key in the metadata.
Okay, one thing to clarify : this is basically for checking renders, so let’s assume no communication with the person providing the render or assume that information provided is not necessarily correct.
For example on render in the exr/arnold/color_space key it say’s ‘scene-linear Rec.709-sRGBarnold’ , what other value could be here and which is which ?
It appears this happens with 3D studio only, and in maya it says ACES CG 
Also, chromaticities and acesImageContainerFlag values do not exist in the renders 
again, not sure if that’s good or bad.
That means it is not in ACES. The rendering color space in Arnold 6 and older is scene-linear Rec.709-sRGB, Arnold 7 and higher use ACEScg. It will be one or the other.
If reading these renders into Nuke in ACES you would therefore choose scene-linear Rec.709-sRGB on the input color space of the read node. This will transform from scene-linear Rec.709-sRGB to the working space ACEScg.
Unfortunately it seems that renders from 3D studio are still scene linear , even with arnold 7
Sounds like a question for the Autodesk forums or Arnold support
Also, not to be nitpicking but a render is always scene-linear. The question is whether it is scene-linear ACEScg or scene-linear sRGB.
Yeah, but we went far from the original question, which was how to check what color space is a render in when you don’t know / don’t have solid information or simply just want to double check if someone f’cked up sg …
Beyond checking the meta data of the exr, if the files are named in accordance with the config.ocio you can query OCIO to retrieve the colorspace from the filename from an OCIO enabled application.
" getColorSpaceFromFilepath(filePath: str ) → tuple"
It initially designed that in ACES there would be only one way to exchange linear files. .aces are Ap0 linear. This problem isn’t to exist in ACES. Every other colorspace was working and not valid for writing to disk. Hopefully this can be addressed systematically in ACES 2.x and beyond.
Unfortunately, Ap1 broke that assumption and because it is the CG rendering space for a lot of studios, you have textures and renders encoded with it.