Out-srgb in and Out via acesCG workingspace Colorshift in nuke

Discussions - Using ACES
1

stumbled across something I find a bit odd while testing DNXHR444 in nuke :

I encoded some prores422LT files for dailies using aces 1.2 OCIO same colorspace for both read and write node set to Output-sRGB, which should be a no-op in 32bit nuke land but it isnt?

This is what I get from the outpuit when encoding a SMPTE testchart the dnxhr source looks fine.

image
image850×448 32.1 KB

So I tried reading it in as raw, and the issue seems to come from the working space (acesCG) to out-sRGB step.

image
image1655×1214 289 KB

I cant read/write as RAW cause that will give me the wrong metadata in my Quicktimes and then make nukeStudio lets just say … not happy.

I also get negative blue values on the yellow patch in acesCG, how can I get out of Gamut stuff from a sRGB source even?

I also get the same shift when going via acesAP0 als a colorspace.

Very confused, probably never seen this in real footage, but I do assume that this is not correct? in/out same colorspace should always be a Non-operation as much as possible, no matter what that is?

using utillity-texture-srgb for both idt and odt works fine however… huh… is this how am I supposed to handle display reffered media then?

2

This has been discussed here before. I’ll try and find the link.

Basically using an Output Transform as an Input Transform means going through the inverse RRT. But the RRT is not 100% invertible. So going backwards then forwards through it does not quite result in a no-op. In particular saturated greens and yellows get slightly clipped.

1 Like
3

ahh see I learned something allready, I didnt not know the rrt wasnt iversible, that really throws me a bit off honestly.

I searched for a bit but probably was too far down the rabbit hole with this to find the other post, really sorry!

I need to re-evaluate the way I handle display reffered material then, so far I havent noticed anything in real footage becomming an issue though and just used output-sRGB as my IDT for anything thats sRGB as I output it as output-sRGB again and all was good, or probably was not.
(obviusly I dont do this for textures… just for real display reffered stuff thats supposed to be that way and stay that way and never have to be scene reffered at all) .

One thing is client offline references, we need to match a grade a lot of times and to check we get display reffered stuff, so I will have to find a way around that…

other thing is still client logos and stuff, If I get a yellow client graphic and ingest it as output-srgb that will lead to problems as well…

I think I found the post? Preserving the look of sRGB graphics

This explains the cause of this really well, but I guess to get display reffered values in/out of a aces projects I have to use RAW as input and Output, will have to see how to get around the foundry.colorspace metadata that nuke defaults to before any other rules for dailies, that was such a nice way…

I guess with the current implementation there is no way for me to playback 1:1 display reffered values straight to my display, from a file without turning off all colormanagement, so I can never look at and compare my comps srgb-display output as client will see it in dailies vs lets say a reference quicktime without manually adding a ocio-display node to the end of my comp.

To be honest I am starting to think that using the ODT as a IDT is still a OK workaround as it really just concerns “crazy” colors, but its important to know this to be able to remedy it to some extend, when I now see a shot with bright yellows I will think twice about it and doublecheck it as RAW.

One way I am thinking for dailies is to just write out acesCCT DNXHR files (we do need something single file based with baked audio for convenience) . and then encoding web player output-sRGB dailies from that and making sure RVs OCIO stuff works automatically when playing back those files, only issue is obscure video playback software like this weird one with the blue Q logo, or the one with the traffic cone cant deal with this at all.

Dont really have a great solution for client supplied references and logos, kinda dont want to work without a viewer and doing my display transforms as nodes just because of a yellow logo… man I hope I never have to make a commercial for the yellowpages :wink:

That said, there also wasnt a great solution for this “before” aces, you either had some custom tonemapping lut that mostly wasnt reversible unless it was just 1D or you worked with that straight up sRGB clip-everything-over-1 display transform and then added tonemapping nodes to the comp tree , I dont want to ever go back to that and I take a yellow desat over this any day :smiley:

ahh all the rambling… sorry

4

It’s not normally a problem for display-referred photographic imagery, as that is unlikely to contain colours which will get clipped in the round-trip. It is more likely to be an issue with graphics.

1 Like