Background image colorspace shift OCIO

   2590   2   1
User Avatar
Member
32 posts
Joined: June 2010
Offline
Hello everyone.

I am setting up light pipeline for project in Solaris. We have sequence with exr source files that are ACEScg. Usually for artists doing animations/fx we would set up png proxy for the background that is half res. For that png proxy we would set up colorspace to be outputSRGB.

1. When we load exr ACES-cg seqeunece as background, everything looks perfect. My concern there is that exr would be too heavy for regular type of work like animation/fx. Playback will be slower, and potentially VRAM will be filling at faster rate. In some shots that are almost 1000 frames long that could be significant:

Backround acesCG, regular Houdini viewport:



Background acesCG, Solaris viewport:


So that is all fine looking, same as Nuke.

2. When we load png, by default this is what we get:

Regular houdini viewport:

Solaris:


3. Before solaris we had node that would pass image through cops and convert it's colorspace:



If you look at right side of the image, trees and river, eveything looks ok. Things get messy, or better to say clamped, where there are values that are bright. Looks like internally Houdini clamps data from png files.

4. After bunch of googling, and asking sideFX support for help, I got answer that there are colorspace tags that can be incorporated in filename so image will be interpreted in desired colorspace. So I renamed image to have out_srgb inside it.



I tried loading these images as image planes in Maya, this is result:


It looks correct

So for now we are using exr files in light scene for background, while using png proxy for everyone else. It looks clamped in bright parts, but works much faster than exr. Did anyone encounter same problems?

Attachments:
background_acesCG_regularH.PNG (721.8 KB)
background_acesCG_solaris.PNG (446.0 KB)
background_png_regularH.PNG (720.9 KB)
background_png_solaris.PNG (768.2 KB)
background_png_withCS_correction_regularH.PNG (814.3 KB)
background_png_solaris_CStags.PNG (717.4 KB)
maya_ip.PNG (1023.4 KB)

User Avatar
Member
8173 posts
Joined: Sept. 2011
Offline
Htogrom
If you look at right side of the image, trees and river, eveything looks ok. Things get messy, or better to say clamped, where there are values that are bright. Looks like internally Houdini clamps data from png files.

png files are clamped, Houdini wouldn't be clamping them on input but they might be being transformed without converting to hdr images first.

Transforming from out_srgb to acescg can produce values above 1 when the input has bright screen values. This requires the image be represented as an hdr image before conversion of colorspace. For COPs, the convert node can upgrade the image from 8bit to floating point. Performing the conversion in 8bit and will result in a clamped image.

If your screenshot image with the clamped highlight from COPs, using a convert node, or checking 'linearize input' if the file has appropriate color space tags and the image will be property converted back to hdr. If that is from using the png as a background with the filename token, then you might be out of luck. It seems the colorspace conversion is done for the background without converting to float. In that case, there's not much you can do besides use float images.

You could try submitting a bug and see if it get's a response.
Edited by jsmack - Sept. 2, 2022 13:23:15
User Avatar
Member
32 posts
Joined: June 2010
Offline
jsmack
Htogrom
If you look at right side of the image, trees and river, eveything looks ok. Things get messy, or better to say clamped, where there are values that are bright. Looks like internally Houdini clamps data from png files.

png files are clamped, Houdini wouldn't be clamping them on input but they might be being transformed without converting to hdr images first.

Transforming from out_srgb to acescg can produce values above 1 when the input has bright screen values. This requires the image be represented as an hdr image before conversion of colorspace. For COPs, the convert node can upgrade the image from 8bit to floating point. Performing the conversion in 8bit and will result in a clamped image.

If your screenshot image with the clamped highlight from COPs, using a convert node, or checking 'linearize input' if the file has appropriate color space tags and the image will be property converted back to hdr. If that is from using the png as a background with the filename token, then you might be out of luck. It seems the colorspace conversion is done for the background without converting to float. In that case, there's not much you can do besides use float images.

You could try submitting a bug and see if it get's a response.

Yeah. I was thinking the same thing. Problem is cop can't be used as background image like in regular obj context. In obj I would attach cop network as background image.

I'll check in 19.5 and submit bug if it is same deal there.
  • Quick Links