I am a Flame assist/compositor at the mill at the Moment. I am working on a Blue screen job and some phone screen comps within each shot. All my batch works well until I bring in my screen asset. This asset becomes jagged and sharp on all the edges and imagery inside. Also, my whites become blown out. We are working in ACES color space and I bring in the assets in the correct color space when importing. I also did the comp in Rec.709 to double check and the screen assets does work well in Rec.709. When I bring back the comp to ACES it still creates the Jagged sharp edges around my screen asset. I have turned up the AA sampling and also my EWA rendering but no luck. Anyone here have experienced this Alias issue in ACES?
I also doubled check with our nuke team and they do not have any issues with this screen assets itself.
Welcome to the forums. This problem happens to artwork if you convert to ACES using an inverse tone mapping.
The automated ColourMgt function ViewTransform is great for getting graded rec.709 footage into HDR colour spaces like ACES but it is a little bit of a hack. SDR into HDR will just be a guess but for an image it works well and you would expect bright areas like skies or light sources to have high values.
However when it comes to artwork or screen inserts this type of conversion is much less desirable. You no longer want bright whites to have the value of the sun.
Use InputTransform instead to have your values convert to ACES but have your values stay within 0-1.
(In Nuke they call this Utility-Texture)
I think @randy talks about this very neatly in his 8 min into to ACES video. You should check it out:
ACES Is designed to take any image that was photographed from a known camera and undo all the silly stuff that camera manufacturers do. Rec709 isn’t an image that was photographed from a known camera. It’s already been messed with. So, ACES has two separate but imperfect solutions to convert Rec709 to ACES. Let’s use ACEScg as an example. Rec709 to ACEScg via an Input Transform results in an image that is visibly different than its original, but, the math makes sense. As in, Colour Picker some highlights in the Rec and resulting ACEScg. It kinda makes sense. A Rec709 to ACEScg via an Inverted View Transform results in an image that is visually identical, but the math DOES NOT make sense. As in, something in Rec that was 0.7 would be like 6 or 7 in ACEScg, causing problems with edges and alphas and other unexpected shenanigans.
I’d recommend bringing everything into ACEScg, then bouncing to ACEScc or ACEScct when combining Rec sources with non Rec sources.
ACES is a collection of colorspaces, not a singular one, and don’t forget that some compositing operations ought to be performed in ACEScg and some compositing operations ought to be performed in ACEScc or ACEScct.
Appreciate it and thank you for the help here. I was testing these approaches that @randy & @PlaceYourBetts gave above. No luck still. It seems the screen asset can’t handle aces with Flame. The moment it gets back into any aces color space the alias is shot. Client is not okay with color change in asset/logs and a grade is not working out. Here is what is happening.
Try tagging as rec709 on import.
In your batch do a colour management view transform from rec709 to st2065 dci p3 (d65 white).
Then plug that into another colour management view transform from st2065 dci p3 (d65 white) to acescg.
That’ll sort your colours out. It might help with your aliasing but maybe not.
here’s the short answer: have them grade the shot without the screen comp. once you get the graded rec 709 plate back do your screen comp as normal. Bob’s your uncle.
here’s the long answer: as some have pointed out ACES was designed with photographic content in mind, not graphic design type stuff. ACES is for stuff that responds to real world lighting values in live action plates. Others have explained this way better than me elsewhere on this forum. As an example when you convert your rec709 or sRGB screen graphic to ACES it maps white to the hottest, brightest thing imaginable. Think the Sun. That’s why it’s all blown out looking. its literally so bright it’s bleeding into the typography and even the edges of the phone a bit. If you use the color sampler (eyedrop tool or hold space+ALT) and sample the white in that top image it’s prob peaking around 16. The same conversion will also shift color values slightly which might look OK to some, but is no bueno when we are talking about brand colors that need to be an exact match to the client style guide. You are not the first to be stymied by this ACES short coming and my understanding is the Academy is working on an update which will make this less painful eventually. One work around is using an input transform from sRGB (or rec709) to ACEScg. this will map your white values to something you are used to: a value of 1. It will look a bit muddy however as a value of 1 is not very bright in ACES, so down stream you can plugin a CC node to tweak the values to be something more palatable. Your screen comp will behave you the way you are accustomed and your type wont be crunchy. If you are dealing with brand colors that MUST match the clients logo (like in your example above) however i recommend bailing on ACES altogether for that shot so you can look your client straight in the eye and tell them that is exactly the asset you were supplied without any color adjustments whatsoever. hence my short answer above
Hey Randy I meant “shot” as in it looks terrible. Poor choice of words on my part.
It seems like any color conversion I do in ACES it still blows my whites out or I need to color grade screen asset as all of you have mentioned. I tried a few ACES luts (ACEScc, ACEScct, & ACEScg). I had the best result in REC_709 but since we have CG in spot we cannot ditch the ACES color space. I found @TimC color fix to work well in this situation I am in with the least amount of color shift/color grade. Thank you all for the help and time.
