Photo 2.4.2 - 32bit image - export to 8bit - wrong gamma | workaround with procedural texture

[cgidesign]

When exporting a 32bit image (for example a linear exr) as an 8bit image (e.g. png) the gamma curve is not applied as needed.

 

With a procedural texture (live filter) this can be compensated:

 

With the texture active, the image looks wrong in Photo but the export is ok.

 

I made two gamma textures; one to add gamma, one to remove it:

• Gamma_add_APhoto.aftoolpresets
• Gamma_remove_APhoto.aftoolpresets

Those can be imported:

The presets are made on a Windows PC with German keyboard layout. It might be that the import does not work because of the dot vs. comma situation (see the gamma value in the screenshot - in German it is 2,2 while US would be 2.2). But I posted both textures as screenshots so you can create them manually.

Gamma_add_APhoto.aftoolpresets Gamma_remove_APhoto.aftoolpresets

[James Ritson]

You're using an Unmanaged (linear light) view, ICC Display Transform is what you want to be using in order for the export to a gamma-encoded format to match the document view. This does complicate the process of trying to work with OCIO, however.

When OpenColorIO was implemented, its intended use was only for non-destructive colour management where Photo would be utilised for retouching of linear EXR/HDR files, before then being exported back to that same format for compositing in other software. The OCIO adjustment was introduced so you could composite multiple sources with varied colour spaces into one document. It seems there's a bigger demand for working with an OCIO view and then exporting the OCIO-encoded results to a gamma-encoded format for final output.

One thing that was suggested a while back was having the option of writing an unmanaged bitmap if the OCIO view transform is in use—so similar to blender (and I expect other software) where the OCIO transforms are written into the colour values and the resulting image is untagged (assumed sRGB in most cases). I'll bring it up again with the Photo team.

[cgidesign]

I tried to use the ICC managed view in the past but that introduced complications like you wrote. As ocio became the defacto standard for 32bit editing in most tools it is easier and more predictable to use that for everything.

The nice thing about Photo is, that it can be used as a tool for "quick and dirty" exr canvas compositing including a usable 32bit brushing. But I understand that the initial idea was to edit e.g. textures in linear space and give them back to Fusion, Blender in linear as well.

If you ask me, I would like to see a more complete ocio feature set, especially GUI vise. The current implementation differs a lot from the standard ocio UI most apps use. But on the other hand, because some features are not accessible via the gui I had to finally learn how the configs work internally.

The most interesting part would be Virtual Displays:

I think that concept is available since ocio V2 and allows to add an icc display transform into the chain. That means at the end of the chain a final ICC correction for the actual display can be used. More about this here: https://github.com/AcademySoftwareFoundation/OpenColorIO/issues/1082 and here in "read the docs" https://opencolorio.readthedocs.io/en/latest/guides/authoring/displays_views.html#config-displays-views

That means we can have a complete colormanaged chain even if the display is not a high end reference display (which especially most pen displays are not).

I have not yet tried if this is already working in Photo, because I just recently learned about this.