This is a gain on the camera exposure values, and not the textures.
I know, you can use “gain/exposure” at a Substance level (along the plain contained LUT) if that’s the workflow you want to follow.
Looks like Thomas answered everything
The gamut expansion is subtle enough to ignore for the average texture in my experience unless you’re working with saturated colors near the Rec.709 boundary. The blue light fix may be more of a common issue since it has a bit of an effect into cyan and purple, but the blend is arbitrary and may not even be necessary. I generally disable it unless I need it- it’ll be pretty obvious if you have any bright blue emissives and don’t use the correction.
I agree. There’s a few shader-based ACES implementations(almost always from Narkowicz’s RRT+ODT fit), but imo it helps to have the background HDRI match as well and it reduces the need to manage however many Painter shaders you use. Sadly the LUT requires an additional step that I wish wasn’t needed, but you can set up a template with everything already enabled for your project.
Thank you all so much for your quick responses. Couple follow-ups:
To make sure I’m interpreting this correctly: you’re advocating avoiding touching any of the filmic curve parameters UE exposes like slope/toe/shoulder, since that is meant to be a fixed standard, and any adjustments to be done through LMTs (UE’s color grading categories)?
To go back to what spurred this topic, the original rock texture done in Substance, using their default linear tonemapper, had a lot of colour detail that ended up disappearing after tonemapping. Am I correct that this likely means our albedo was authored with too bright colours? And we should author based on no changes to the color grading categories & the default ACES curve.
ACES 1.1 will not change anything and we are at 1.2 btw The easiest way, for now, is to use the following OCIO colourspaces and disable the Gamut Expansion and Blue Light Artifact Fix as indicated in the UDN Question:
I read the UDN link - to disable these changes, you locally modified the PostProcessCombineLUT shader, correct?
Hello, my disagreement with @Thomas_Mansencal was ONLY about having the option for “Output - sRGB” as IDT (talk about nitpicking). But as I said it’s an option not an enforcement, you can also choose “Utility - sRGB - Texture” as IDT to conform to standard ACES.
Thank you for clarifying Jose; I must admit that at first that discussion had gone over my head, so the exact disagreement was unclear.
Using the contained LUTs that do sRGB —> ACES2065-1 —> RRT —> ODT is a landmine field, colors don’t go well through the log shaper for Substance Painter LUTs. My version doesn’t do any color work, it’s only the tonemapping part.
What is the ‘log shaper’? Which part of the transform does it affect?
The gamut expansion is subtle enough to ignore for the average texture in my experience unless you’re working with saturated colors near the Rec.709 boundary. The blue light fix may be more of a common issue since it has a bit of an effect into cyan and purple, but the blend is arbitrary and may not even be necessary. I generally disable it unless I need it- it’ll be pretty obvious if you have any bright blue emissives and don’t use the correction.
Good to know. I’m going to see what effect it has on our current content if we revert back to standard ACES, but depending on our VFX going forward I may need to bring back the blue light fix as you point out.
To make sure I’m interpreting this correctly: you’re advocating avoiding touching any of the filmic curve parameters UE exposes like slope/toe/shoulder, since that is meant to be a fixed standard, and any adjustments to be done through LMTs (UE’s color grading categories)?
Exactly! It is entirely fine to play with exposure though as you author your assets, you should do that all the time in fact, check that they look great at any exposure value.
the original rock texture done in Substance, using their default linear tonemapper, had a lot of colour detail that ended up disappearing after tonemapping.
It could be either that the albedo values are too high or that the lighting intensity/exposure of the scene is too high. Hard to get a solid answer without seeing the texture or asset.
And we should author based on no changes to the color grading categories & the default ACES curve.
Ideally yes, see it as your neutral authoring conditions.
I read the UDN link - to disable these changes, you locally modified the PostProcessCombineLUT shader, correct?
You can actually set them to 0 in the PostProcessVolume
Actor:
Cheers,
Thomas
Thanks for this great thread ! There were a couple of similar topics on the forum in case you haven’t read them :
Hello everybody, I’m scratching my head around ACES and srgb texturs so I hope somebody can point me in the right direction. I’m using maya / arnold / Aces_1.0.3 / and megascan textures. I know it is normal that the textures get darker when you use the Utility-srgb-texture but still I have question on the consequences. I downloaded the ACEScg_ColorChecker2005.exr from AMPAS github. My understanding is that it would help me get the correct exposure for my lighting. So I loaded the checker w…
In theory one should be able to read in a linear EXR image with Utility-Linear-sRGB and thus have a linear file that was made using sRGB primaries display the same in ACES. So I would expect if I viewed an EXR in Nuke default, and viewed the same EXR in ACES, read in with Utility-Linear-sRGB that they would be identical. However as you can see below they look quite different. There is a notable shift in colors (the ACES going towards green) and the blacks are crushed. [ACESlinearProblem] You…
Mostly answered by @Thomas_Mansencal There is probably more stuff to read about albedos and such but I would have to dig deeper in the forum archives.
We are also trying to develop an open-source tool based on the Pointer’s Gamut to help artists to check their textures’ base colors (as a personal initiative, not ACES related). Maybe it could be helpful.
Regards,
Chris
Mostly answered by @Thomas_Mansencal There is probably more stuff to read about albedos and such but I would have to dig deeper in the forum archives.
It is certainly worth collecting all that in a document that can be linked directly, given how many times it came, it makes sense to do that.
Cheers,
Thomas
There was a discussion about a knowledge base on the new ACESCentral website. Like collecting all the interesting threads into proper documents/pages to give people easier access. I would even volunteer to do that to be honest, since my website is partially based on these threads. Will ask Steve and Scott about it. Sorry, I did not mean to hack the thread…
Chris
No worries @ChrisBrejon! I’m sure a lot of folks would benefit from that page; your summary that I linked earlier was far and away one of the best introductions to this topic.
I’m also interested in the tool you mentioned; I’d proposed building something similar to my team, along the lines of https://docs.unity3d.com/2018.1/Documentation/Manual/MaterialValidator.html
Cool ! I’ll let you know how this goes @daskyler Thanks for the link to the Unity page. I didn’t know about it ! Sebastien Lagarde and his team really care about this topic : PBR values and such…
I would even volunteer to do that to be honest, since my website is partially based on these threads.
I was getting there and would have volunteered you
Sebastien Lagarde and his team really care about this topic : PBR values and such…
At BioWare after we’d transitioned to Frostbite, Seb Lagarde & Charles de Rousiers helped guide our team through the transition to PBR. Can’t speak highly enough of them
Several of the sections in the ACES Central Knowledge Base are summarised versions of threads or posts from the forum. I think it would be worth talking to @stobenkin about adding other topics to that, if you have ideas of what would be useful. It could benefit from more content there, and the useful forum discussions can be hard to keep track of.
and we’re working on it!
What is the ‘log shaper’? Which part of the transform does it affect?
The process where the LUT is made implies doing color transformations in a space that is not linear leading to innacurate color output. My ACESFilm LUT doesn’t do any color transformations only the tonemapper part, whereas the ACESFilm for ACEScg LUTs do the conversions in linear space so they are the recommended method (until OCIO that is).
For the same reasons explained above, I don’t recommend tweaking your exposure to compensate for dark textures from the “Utility - sRGB - Texture” IDT, lookdev normally is done in rather flat lighting. As always I recommend to use gamma (for the time being). Long story short; exposure brightens bright values, gamma brightens dark values.
We are starting a Virtual Production project that includes building lighting tools and standardized assets (buildings, environments, props) in UE that would be easily re-usable in other VP projects. We see ACES as a critical element for this workflow to tie the color spaces together. As we try to use off the shelf assets we are finding more and more that tricks are frequently used to get a UE asset to work in one specific project . It often requires modifications to blueprints and textures to make them portable into new VP projects using different lighting and combining them with other assets.
ACES AND VP Questions:
- Is anyone working on a standard for ACES compatible UE assets for use in Virtual Production?
- ACES and VP with UE would require a defined workflow as well? I think the asset standard would need to be tied to a recommended workflow. Is this a project being considered?
- I assume an ODT would be needed for the LED Wall and an IDT for the camera - would these need to be developed specifically for this VP process or will a standard camera IDT and display ODT work?
- For VP lens calibration is also a critical component - dont know if that should be part of the workflow.
- How do you see the virtual screen color using an ODT, the camera with an IDT interacting with the live actors and props on stage?
Exciting times to be in our industry. Look forward to hearing any comments/suggestions.
Hi,
lookdev normally is done in rather flat lighting.
Mmmmh, lookdev is typically done in many scenarios e.g. from studio neutral, to overcast and daylight. There is simply no way for an asset whose appearance was developed under flat lighting conditions to look great in daylight. Assets must be tested under the most varied lighting conditions possible or at least those representative of that they will be subjected to in the show. The corollary is ensuring that the asset looks great at all the exposure levels.
Hi @Chuck,
- Is anyone working on a standard for ACES compatible UE assets for use in Virtual Production?
This is probably a question for Epic Games
- ACES and VP with UE would require a defined workflow as well? I think the asset standard would need to be tied to a recommended workflow. Is this a project being considered?
Probably for Epic Games too!
I wish I could answer your remaining questions but I contractually cannot!
If you have UDN access, I would probably also consider asking that over there!
Cheers,
Thomas
UE4 uses sRGB linear (given you’re feeding it sRGB colour) throughout the pipeline up to the tonemapping step, at which point it uses RRT → ODT to output the final tonemapped image?
- At this point, it seems prohibitive to move all textures to be pre-converted to ACEScg
Reviving this topic in regards to texturing workflow. In the meantime Substance Painter works with OCIO so that part is easy-peasey. As mentioned above UE uses sRGB linear as its working space, and will read in 8-bit color textures with the sRGB checkbox selected converting them to sRGB linear. It can also recognize normal maps and uncheck the sRGB box. Trouble is other non-color maps: masks, metalness, roughness, AO, etc. which need to manually have the sRGB checkbox turned off. Looking for a good approach to having it automatically detect the correct IDT.
AFAIK, Unreal does not support OCIO rules such as the ColorSpaceNamePathSearch, which is how we would approach this with OCIO in Maya. So I’m curious if anyone has any approaches to get Unreal to automatically ingest non-color textures as raw? What would be nice is to set it to default to reading all textures as raw, with an exception made for color textures, based on naming conventions.
One possibility, I was considering is writing color and normal maps as PNG, and the non-color maps as EXR, which would presumably be read by UE in linear.
Trouble is other non-color maps: masks, metalness, roughness, AO, etc. which need to manually have the sRGB checkbox turned off. Looking for a good approach to having it automatically detect the correct IDT.
Turns out UE does not read in EXR textures as linear.
Arrived at a good solution to this that I thought I’d share:
Keeping working color space at default linear sRGB in UE.
Writing all texture maps as PNG from Substance Painter working with an ACES OCIO config. Non-color maps are raw, and the channels are packed (roughness in green, metalness in blue, etc.)
The packed non-color texture maps import into UE with an unwanted sRGB conversion (sRGB to linear). In the base material for those maps I pipe the channel through a linear to sRGB node, thus undoing/reversing the unwanted gamma correction. This base material is then used for all material instances, making the whole thing automatic.