I also have this issue:
All scaling should be performed using the Simon filter in ACEScct colourspace
- Simon filter. This is something found in Nuke, what tis the corresponding filter in Flame.
- ACEScct colourspace, again, how do I do this in Flame.
1 Like
Hiya Paul,
All that spec is doing is reminding you to do the proper compositing tasks in the proper compositing space. ACEScct is a log flavor of ACES and is the perfect colorspace to do transforms, as in, desqueezing your anamorphic content, which, I’m guessing you’ll need to do based on your Topic Title.
Regarding Simon, based on what I’m reading about Nuke’s resize filtering, Simon appears to have a little bit of built in sharpening by adding some contrast around neighboring pixels which, when done on linearized images can and will add negative numbers around highlights, which, looks like little jaggy zebra hashtaggy jaggy visible artifacts.
This is perhaps the #1 reason you really need to know what you are doing in these situations in Flame because our beloved Lanczos sounds a lot like Simon and most everyone keeps the Lanczos default Resize in a timeline and causes all sorts of problems and artifacts without realizing it.
The only way to avoid all of this potential pixel drama is to do that work in log space AKA ACEScct which is what your spec is telling you.
Although I’m not an expert, Simon sounds a lot like Lanczos to me, but, based on Lanczos’ rather aggressive sharpening, it may cause problems with moire and small details. For me, I’d try Shannon but experiment.
If you are new to the world of ACES, check out my 8 MInute ACES Logik Academy video: Logik Academy - 8 Minute ACES - YouTube
Also, can you please provide a more specific Topic titles to your posts? Thanks.
2 Likes
@paul_round I don’t know what your workflow is, but we’re doing the bulk of our comp work in acesCG at plate resolution but adding a color management timeline fx to each segment in the timeline with a conversion from acesCG into acesCC for 2d transforms into the delivery res. On top of the full edit there’s a layer of color management to take it back into rec and then graphics on top of that. There are some folks that like to do the graphics in log as well—to each their own.
For shot work—in particular the de-squeeze you would simply color manage from input space, like acesCG into acesCCT, make the 2d transform and then invert the color transform form acesCCT to Working space (or wherever you want to be).
Of course if you’re not working in aces, and just pushing things through in AlexaWideGamut or whatever, you could cheat if you’d like and make the 2d transform in that log space and forget about it. To @randy’s point it’s more about not artifacting in screne-referred linear with a coring filter during resize… given the Nuke heavy wording, it sounds like someone’s been bitten with edge artifacts in linear.
Hope that helps a little.
2 Likes
We’re getting there, and yes, after talking to the clients will be working in ACEScg.
We’ve done ACES before, but the tech spec for this show is something else!
Now trying to sort this one out:
Where visible OOG issues are experienced, we expect vendors to address this in their pipeline using the ACES 1.3 Reference Gamut Compression method ( code and plugins available here ). aces-vwg-gamut-mapping-2020/reference at master · ampas/aces-vwg-gamut-mapping-2020 · GitHub
While I do appreciate specificity in a spec sheet, it does drive me up the wall when they specify a kernel that flame doesn’t have.
On the bright side, no one alive is going to be able to tell the visual difference between a Lanczos and Simon resize. They’re basically the same.
I recently went through the Simon filter request as well. I went through all of the filtering punched in a lot of percents and found Shannon to be the closest with 1.5 precision and .95 crisp/soft and that made it through the QC. It looks marginally different in the quicktimes in the extreme highlights but I was told the EXRs were matching.
2 Likes
Regaring this - there is a matchbox shader that does the gamut compression but dont expect it to match a proper aces 1.3 implementation (like the one in resolve that has a default and a parametric mode). Flame will need to update the included aces version , 1.2 wasnt a big update for sdr but 1.3 is due to the gamut compression stuff.
I am not sure why this would be needed for delivery though as its just a display issue, usually youll only use gamut compression on your display transform and not bake that in - ive only needed to bake it when I needed to comp in CG neon lights and creating those out of gamut colors was a bit weird visually so we baked the gamut compression into the backplate for CG and then inverted it on loading the renders.
And its probably a complete non issue unless you have neon lights around, it just looks like clipping color channels visually.
1 Like