Here’s the question/sciency bit - is it possible to do a conversion where it looks more like source but doesn’t have crunchy whites just using a color mgmt node?
I think this is the same problem I have when I use graded, rec.709 footage and I want to do my comp using a linear workflow. The colourMgt conversion, ViewTransform from rec.709 to ACEScg, is imperfect. It is just an approximation.
Taking a small dynamic range (rec.709) with values 0 - 255 and trying to make it a high dynamic range. It struggles. Especially at the high end with the bright white values.
The tone-mapping is most extreme at the toe (shadows) and the head (highlights), certainly in ACES the roll off in the highlights is very sensitive. And when you are trying to do the conversion it is inverting the tone-mapping.
Any values that are white or close to white with be converted into some very high values in ACES land and that soft alias on the edge of the graphics suddenly has values that can jump from 16 (pure white) to 1 with the space of a single pixel. This makes the edges appear crunchy and sharp.
The ViewTransform will get the colours to appear visually the same but the tone-mapping will be struggling. The InputTransform will not do an inverse tone-mapping and you can see that the white graphics sit close to a value of 1 but that looks shit in ACEScg.
Imagine an image that I want to defocus. It is the man from Delmonte in his white linen shirt on the beach. It was graded rec.709 and given to me.
I switch to ACEScg because I want my highlights to bokeh. His white shirt in the grade has become something like a light source. The ArriAlexa would have retained the subtle difference between the sparkles on the water and the white shirt but now that I have graded rec.709 these vales are so close to each other that the ViewTransform conversion puts them both up into the light source territory.
I can see some of that crunchy edges happening where I have a hard edge but if I can cope with that in ACES when I invert back into rec.709 the crunchiness is resolved.
Apologies for not being clearer in my post. Changed the subject heading to reflect the intent more accurately.
@PlaceYourBetts this is the conclusion we had reached too but I hoped someone might have a clever Aces Linear workaround. The second still above shows a transform which though darker, I feel could be graded into a comp.
Aaaaaa @andy_dill nice suggestion. Will try this out. Thanks.
What I found with log is the whites are still very high when you convert the log to aces cg. I think my preference might be to use the second option above and use an image node (after aces cg lut) to colour correct the artwork into plate. Why image node? Because gamma curves seem to work better in linear with it.
This question came about because of screen comps and other similar situations. And to be honest, one normally would grade the artwork for a screen comp so it’s not completely foreign territory.
I`d put to test new T-CAM v2 workflow from baselight. They have both OCIO and Flame configs available to download
There is big chances that it would be free from old ACES luma comress problems.
For screen comps of rec material I have been using a regular old input transform lately. It changes the color some, but I have to match it into the plate anyway.
I asked Doug Walker his thoughts on the subject. Here is answer:
If it is a texture, then I would use the Input Transform tool in the Colour Mgmt effect. This will ensure that no white levels go above 1.0, but it will look a bit darker and higher in contrast.
If it is something like a matte painting, I would use the View Transform tool in the Colour Mgmt effect. This should give a result that looks virtually the same as the original, but the white values may be much greater than 1.0.
This is a a known issue with ACES. The whole system is built around using scene-referred values with plausible reflectance values. So imagine the value a pure white graphic would have to be in the real world for it to be recorded by a camera and still come out looking like pure white on screen. This is the reason your whites look crunchy, they’ve been converted, I presume with a reverseODT, to work in ACEScg but this puts the whites at some extreme value way above float 1, probably something like 11 or 14. Now your anti-aliasing doesn’t work as well at these values and so the crunchy edges on white text.
If you want to stay in ACEScg technically you would use the Utility-sRGB-Textures IDT, but as you’ve noted the graphic would come out dim, because all that does is put an sRGB image inside an ACES container, basically replicating the reflectance values if you recorded an sRGB graphic off a screen.
Also note that all conversions in ACES use 3D luts, so even if your graphic looks ok in ACEScg, it technically won’t be the same as the original sRGB. Also there is another known issue with desaturation of very saturated yellow colors, again a known limitation of the system. When the system was originally developed the use case for graphics was never considered because, graphics don’t “exist” in the real world!
The best approach for simple graphics…don’t work in ACEScg, unless the graphics live in some rendered world with plausible reflectance values. For simple graphics where we need accurate representation of client branding standard linear is fine as the elements are only processed with a straightforward and accurately reversible gamma operation.
Out of interest, what is the actual use case for the graphics? Is it to composite into a real environment, say on a display of some kind? Or is it some hyper real scenario where it is graphics just blatantly being graphics sitting within a shot environment for some kind of design aesthetic?
Bringing back an old topic, dis anyone come up with a workable solution for this?
I have a whole bunch of screen reps that are using artwork that will not convert nicely to ACES.
