Author: admin

does karma have a color limit somewhere like mantra used to?

try lifting that maybe?

and then work out how you’ll deal with firefly hell

Attachments in this post:
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20232311/29/23/image.png

With regard to the color space talk, I happened to have closely investigated what H20 is doing just yesterday. The issue I was running into is that Karma’s output respects the Input File Rules set up in the OCIO editor (Edit > OCIO Settings…). So even if your working space is set to ACEScg, the rendered image will still be linear rec.709 unless you take some step to prevent it.
– You can put the string “ACEScg” in the render’s filename, and Karma will obey the file rule. – You can change the file rule for *.exr to ACEScg. If you’re already pre-processing your inputs, this is what you should do. This is the “correct” ACES workflow. – You can set the Output Colorspace parameter for each AOV that should be ACEScg. – Or you can use the OCIO filter in the render settings to apply a post conversion. I recommend against that one, though, as I do not believe the conversion is lossless, and it risks a double conversion.
The SDR 1.0 Video view transform from ACES 1.3 ought to be sufficiently visually similar to Output – Display – sRGB from ACES 1.2, but I haven’t verified that yet. The Un-tone-mapped view should be the same as Input – Texture – sRGB.
The ACES 1.2 config can be found here: github.com/colour-science/OpenColorIO-Configs/tree/master/aces_1.2