Hi there, I’m new to ACES, but have read the VES whitepaper and have trawled through the forums quite a bit. However, I’m a little confused about the correct way to work with sRGB textures out of packages which are not using the ACES workflow and then convert them to scene-linear for rendering within an ACES workflow.
In my case, I am stuck with only being able to export sRGB textures. If I open these textures in Nuke with a regular-old sRGB colorspace, they get linearised to the values I expect. However, if I try to load them with Output - sRGB, as I have seen suggested here: sRGB Jpeg use in ACEScg my colours are wildly different. What am I missing here? Utility - sRGB - Texture is also way off, but a little closer.
I don’t want to load these textures as sRGB into Maya for rendering as I want to convert to scene-linear before mipmapping, as suggested in the whitepaper. Is it not possible to avoid a colour shift? I paint with physically accurate values when texturing that I intend to be rendered 1:1.
I reckon you should load your textures as ‘Utility - sRGB - Texture’. I only use ‘Output - sRGB’ to write jpgs. Never to import stuff.
I have read in some posts people were loading using ‘Output - sRGB’ but it never worked for me… I am not sure why to be honest.
This is the node I would use to convert my textures in Nuke:
I personally do not convert convert my textures and generally use this setup in Maya after doing my textures in Photoshop.
And to answer your question, I guess you will always have a shift when you convert because of the change of primaries from sRGB to ACEScg…
“The approach we advocate is to linearize prior to mipmap texture generation. The primary advantage of this approach is that scene-linear energy is preserved through all the mipmap levels, allowing for the highest fidelity sampling and fewest color space related artifacts. Further, disallowing color space conversions at shading time prevents shaders from doing evil (non-linear) color math.”
I understand there will be a shift due to shifts in primaries, but in that case can’t you just write sRGB to Utility - sRGB - Texture, and then to ACEScg? But I have read other posts saying this is not correct, and I am not sure why.
The VES Cinematic Color document is currently being updated, and in it @Thomas_Mansencal has written a detailed explanation of why the choice of working primaries makes a difference.
But briefly, CG rendering involves multiplying light colours by surface colours, and if you take two (linear) colours and multiply them together, then do a colour space conversion, the result is not the same as if you convert first then multiply. Try it for yourself in e.g. Nuke. When adding colours the order does not make a difference.
Thanks for the response Nick, although maybe I wasn’t clear - I was suggesting that I import as a standard sRGB texture, convert to Utility - sRGB - Texture, giving me the correct primaries (as far as I understand?), and then convert to ACEScg, and then render. I still don’t really understand why this isn’t okay? I am not suggesting rendering in any other colour space than ACEScg.
And also, if this really isn’t okay, do I just have to accept that if I create a texture outside of the ACES workflow I will not be able to match the colour exactly when converting to ACEScg?
Sorry if I’m missing something, I’m trying to grasp this stuff but I’m a novice when it comes to ACES.
Sorry. I misunderstood then. @ChrisBrejon’s comment about the “shift when you convert because of the change of primaries from sRGB to ACEScg” made me think that you were referring to the difference in the results from different rendering primaries.
Taking CG out of the equation, are you just referring to the change you would see when converting an sRGB image to ACEScg in Nuke (as shown in @ChrisBrejon’s OCIOColorSpace screenshot) and then viewing it through an ACES Output Transform? In this case the result is due to the sRGB be used as scene-referred, with 1.0 representing diffuse white in the scene. The ACES Output Transform then maps diffuse white to a value slightly lower than SDR peak white, in order to leave space for highlight roll-off.
This difference is inevitable, unless you use an approach which allows you to preview the ACES transform as you create the texture. For example, you could bake a LUT of the transform from Utility - sRGB - Texture to Output - sRGB and apply this as an adjustment layer in Photoshop (removing it when you save out the texture).
Creating textures in sRGB obviously limits you to the sRGB gamut.
Sorry for the late response, I’ve been away - thanks a lot for your clear explanation, this was kind of my understanding but I wasn’t sure.
I like the idea of using an ACES transform preview and would be happy to work that way. Although surely the transform would be Utility - sRGB - Texture to ACEScg? Why would I use Output - sRGB?
Also, I am still confused why I can’t convert my sRGB texture to linear, and then save that as an ACEScg image, as this will give me the values I expect when I render?
Because what you want to see on the monitor is a preview of the ACES Output Transform, as that’s how it will appear when you use the texture. You don’t want to look at ACEScg with no display transform on an sRGB monitor. By going Utility - sRGB - Texture to Output - sRGB you are previewing the result of converting your sRGB to ACEScg and then viewing that through an ACEScg to Output - sRGB Output Transform.
You can, and you should. That’s what @ChrisBrejon’s screen grab above shows. It’s just a question of whether you pre-bake the conversion into an ACEScg EXR file or apply it ‘live’ to the sRGB file.
Hello Shane, Nick already answered but I was going to reply from a CG artist point of view.
If I’m wrong please anyone correct me.
When you create a texture you want the View Transform to represent the HDR without any tonemapping shape, “Output - sRGB” has a filmic tonemapping in the RRT and filmic tonemapping makes no sense when creating a texture, that’s I presume the reasoning behind “Utility - sRGB - Texture”.
So to correctly paint your texture maps you need the Working Space to be ACEScg, and viewing LUT “Utility - sRGB - Texture”. Then load the textures in Maya or elsewhere with the ACEScg working space.
If you convert your sRGB texture to linear and save as ACEScg it will wrongly interpret the ACEScg primaries, the best way to convert your sRGB textures to ACEScg (the best alternative from the above mentioned) is with Maya’s Tx Manager. You can assign command line flags so aside from texture mipmap you can also do a colorspace conversion. I’m not sure if this is the same than loading the gamma encoded sRGB texture and setting the TextureNode ColorSpace to “Utility - sRGB - Texture”.
In Photoshop if you want to paint in ACEScg you need to set it as the working space and then soft proof with “Utility - sRGB - Texture”, but I think that if Photoshop doesn’t have full ACES support the color picker will be limited to sRGB so not worth it at all.
I am not a CG artist, but I would disagree there. It may take a bit of getting used to seeing the result of your texture painting work through a filmic Output Transform, but that is how it will be seen when used. A texture value of [1.0, 1.0, 1.0] represents diffuse white, and diffuse white should not appear at peak white in a final image, or there is no room left for specular highlights.
That is true if you follow a PBR workflow (which many actually break for artistic reasons), but I would expect a linear tonemapping (with padding or soft clips to 30 and 240) rather than filmic. Mari works with Output - sRGB as the viewer LUT so that is something to think about. Would love more discussions on this topic.
You can, and you should. That’s what @ChrisBrejon’s screen grab above shows. It’s just a question of whether you pre-bake the conversion into an ACEScg EXR file or apply it ‘live’ to the sRGB file.
Sorry I wasn’t clear again; I meant convert to standard linear, not ACEScg linear, and then save the result as an ACEScg image. That way when I paint with a certain RGB value in Painter, I will get the values I put in as I expect. I’m wondering what the issue with this would be? The primaries will be wrong but the texture will be the colour I expect.
“I will get the values I put in as I expect” do you means data texture like “metallic map” or “roughness map” ?If so ,when you load they in maya you should use “Utility raw” ,because it do not need to degamma,then you will get your correct values when it render.
