After some workflow tests with Role - Mattepaint and Role - Color Picking for 8-bit sRGB images I got a discrepancy. Using Still Life images from ACES-dev Github, I read SonyF35.StillLife_ACES2065-1.exr as ACES2065-1 and SonyF35.StillLife_ODT.Academy.sRGB_100nits_dim.tiff as Role - Color Picking and both are visually the same in my viewport. Yet, normally that type of image is read as Role - Matte Paint (Utility - sRGB - Texture), usually coming from Photoshop. If I change to Role - Matte Paint or texture_paint - ACEScc (Nuke default for 16-bit) I get some big changes in color.
So my doubt is, for 8 or 16-bit files coming from Adobe Photoshop, considering colors visually correct in my viewport, should I read as Role - Matte Paint (Utility - sRGB - Texture) or Role - Color Picking (Output - sRGB)?
These settings are automatic in pipelines and maybe I did something wrong, if this is the case please correct me.
When you read in the EXR with input ACES2065-1 that is converting it from the input color space (ACES2065-1) into the working space in Nuke (ACEScg) and then displaying it through the view transform (sRGB).
When you read in the TIFF, it has the view transform baked into it. So if you opened it in a non-color managed program like Photoshop it would look like the EXR looks in Nuke. In Nuke if you read that TIFF in with Output - sRGB this is an inverse of the view (sRGB) so it basically makes it pass-through. It takes off the sRGB transform in the Read node, then puts it back on with the View Transform. That’s why it appears the same as the EXR. It does not have the same pixel info as the EXR does, since an 8-bit file can’t contain that.
The Utility - sRGB - Texture on the other hand is linearizing the 8-bit file. This is what you’d want to do for texture maps in a render like Maya.
Can I ask what the context is that you would be reading in an 8-bit file into Nuke? Is it for a matte painting? A graphic?
p.s. I would take the OCIO roles in Nuke with a big grain of salt. They are historically pretty wonky.
It was a shot that I worked on but the mattepainter complaint that Nuke was reading wrong colors using Utility - sRGB - Texture, because was visually different from PS viewport. Shot was approved, but for me something was off. I would like to avoid those kind of discussion from files generated in softwares without OCIO color management. There are some studios that don’t have a consistent color management control, and sometimes when working as a freelancer I need to deal with all kinds of workflows and files. What I am looking for is some kind of standardization, like ISO but for image/video production. A documentation with statements.
Ah yes, been there! Generally it is preferable to not have matte paintings done in sRGB space like Photoshop defaults to. Instead it’s better to have them work in log or scene-linear. Here’s a little help doc I made about various options in Photoshop:
Of course if you don’t have control over that workflow you just need to make the best of what’s given to you. Reading in an 8-bit image with the inverse view transform will look the same, but will make white go from a value of 1 to 16 which may give you undesirable results in Nuke. For a matte painting this could actually be a good thing if it’s making a luminous thing go above 1 like fire or the sky. Not so great if it’s making a white wall go above 1.
On the other hand, reading it as sRGB texture has the purpose of keeping the values all below 1 (which you need for physically based renders to avoid making the object light emitting) and will consequently darken it. You can then brighten it to taste in Nuke.
Great plugin but I’m quite sure most matte painters won’t even try OCIO transforms in PS. I’m not a color expert but had an idea. How about I use mmColorTarget gizmo to generate a color matrix and use it as a transform? Just to avoid that viewport difference and keep RGB values consistent. Did a test with MatchGrade node reading ACES2065-1_ColorChecker2014.exr as ACES2065-1 and sRGB_ColorChecker2014.exr as Utility - sRGB - Texture from Colour Science Github. MatchGrade node Pre Lut parameter set as Logarithmic. Visually looks similar, but internally probably something is wrong. What kind of trouble am I expecting here?
Obs: If viewer 4 gamma is increase there’s a slight difference.
