Hi guys! A simple question as one may think - How to treat .exr file (linear sRGB) in Nuke with ACEScg? It seems the interpretation rules of ImageReader Node do nothing when I say colorspace: utility-linear-sRBG! ( a standart way to interprete textures for arnold render in 3D). What is a proper way then to use linear sRGB exr images in Nuke with OCIO environment? Image should look just the same, without heavy darkening. Color matrix may fix it I guess at least. There is a god resource Apps (Colour - Dash) | Colour Science - it shows the color matrix for different cases, but there is no such thing as Linear-sRBG in the list of available colorspaces! (Or may be I just do not familiar with anofficial name for this?
Hi @dmitryshoumkin,
you were interpreting the linear sRGB footage with the right IDT already:
Linear Rec.709 (sRGB)
The primaries of sRGB and Rec.709 are identical.
The standard IDT for textures, when encoded for a sRGB display, is called:
sRGB - Texture
Depending for which kind of display the texture was encoded for, there are more options
since the last OCIOv2 configs were available: (everything with - Texture)
I hope this helps,
Daniel
Yes, I know that, thank you. But the problem is that this interprete rool does not make a sense in Nuke:
It works perfectly with sRBG images of any kind - jpeg, png, mov. But if the image appears in liner-sRBG ( hdri file from some public library or just an old render .exr from non-ASEC pipeline - itās imposiible to accomodate into ACES Nuke workflow! I just saved for example the png mackbethās Chart picture to linear exr (in Nuke without ACES 1.2 environment) and read it in the other Nuke session this time with ACES management - and it does not restore the original look with Linear-sRGB IDT in reader! It seems to be a real problem
If I understand you correctly I think your expectation is wrong. I think you are expecting the image to appear the same through the ACES sRGB ODT as the EXR would look with just an sRGB curve as a view LUT. But a simple sRGB VLUT maps linear 1.0 to peak output, leaving no space for highlights >1. These just get clipped. ACES includes a tone curve which rolls off the highlights, and in order to āmake spaceā for those the mid tones need to be dropped down a little.
You can use an inverse output transform as an IDT to achieve what you want, but you need to consider if that is really appropriate for your situation. Inverse output transforms create scene linear values which are not always physically plausible (sRGB white effectively becomes a scene light source) and may behave in unexpected ways in compositing.
You can see in the screenshot below that while the inverse output transform achieves a match to the simple sRGB curve, to do so the white patch gets a scene luminance of ~3.4.
1 Like
We all understand that both āblackā and āwhiteā can reside at every possible code value right? And that saying āhighlight roll offā is nonsense?
We would all be better off to stop repeating myths and tropes like this.
We also understand that if diffuse white resides at the maximum display code value, then it is not possible to differentiate between that and anything brighter.
I donāt see why there is anything contentious about saying that in order to discriminate between diffuse white and brighter pixels it is necessary to lower the code value where diffuse white resides, and compress brighter values.
False?
False? Conflation of stimuli with cognition of colour?
Because such statements conflate discrete metric quantities of stimuli with colour cognition?
1 Like
Yes, but thatās not quite a point.
First letās look how itā settled in arnold render: every incoming texture first becomes converted to ACEScg colorspace and is going to be saved to .tx file (itās filename gets a suffix of IDT used, like this: horse_BaseColor.1001_sRGB_ACEScg.png.tx)
Thatās really greate thing to bring the source information to the file name!
The result may look as well as:
bat.1001.basecolor_scene-linear Rec.709-sRGB_ACEScg.exr.tx
The HDRI images shoud go through the same procedure and the result would look similar: sunset_scene-linear Rec.709-sRGB_ACEScg.hdr.tx
The render is going to be .exr sequense in ACEScg.
Then this comes to Nuke (with OCIO profile) for compositing. And thatās the point the problem starts.
What if I need to add this sunset.hdr as a background picture (for my ACES render)?
I say āUtility-Linear-sRBGā . And what a supprise, Nuke makes it darker! But what if I just can not accept it becomes any darker and have to preserve the sky color exactly?
Converting it before to sRGB format is working but not the best idea. I have to add another render made before render ACEScg pipeline! Multichannel .exr with light passes which are not supposed to get different tone just because of switching pipeline!
I guess some color matrix may fix it, but I just can not understand where does a difference came fromā¦
How was sunset.jpg made? I obviously donāt know that image, but in your screenshot it looks rather clipped, as if it just had an sRGB curve applied, and everything above 1.0 in the HDRI is clamped at 1.0.
You are using Output sRGB as your IDT which is actually an inverse ODT as I describe above. So again, I donāt know the detail but it looks exactly as I described previously ā an expected mismatch between a simple sRGB curve and a tone mapped ACES rendering.
If you donāt use Nuke in ACES OCIO mode, do the JPEG and the EXR match with an sRGB VLUT?
Perhaps your confusion comes from the expectation that what you see in the Nuke viewer is the image data you are compositing with. This is not the case, there is a āviewing LUTā on top of the image. The ACEScg working space when using OCIO ACES in NUke is linear just like your CG renders (if you rendered them as linear EXRs). So in practice only a primaries conversion is happening from sRGB/709 to AP1 (ACEScgās primaries). All the scene-linear data is retained during compositing.
On export you can bake in the ACES sRGB output transforms for stills or Rec.709 for video or export as linear EXR again if it needs to be handed off for finishing in other software.
Part of the function of an ACES pipeline is that everyone uses that same āviewLUTā for viewing but the set of output transforms are also for grading, finishing and delivering for those intended displays.
The same sky picture stored in different colorspases always match exactly -Cineon, linear or sRGB in Nuke without ACRS. It needs only to interprete their incoming colorspace correctly . Sunset.jpg I made from .hdr by saving it with sRGB output colorspace. Itās ok if I need just a flat picture on the backgroung, all colors are going to be clamped anyway since my output file is mov and no more serious color correction needed.
Yes,I can see clearly the result of only prymary conversion if compare sunset.hdr with sunset_scene-linear Rec.709-sRGB_ACEScg.exr.tx.tif (file made by txmake) which can be opened in Nuke making his extention .tif, not .tx. Fine red tone slightly visible in blue areas
In which case I refer you back to my original post, which describes exactly why the difference you see is expected.