Jump to content
You must now use your email address to sign in [click for more info] ×

Convert to 32 bit without gamma correction


Recommended Posts

Hi, Is it possible to convert an image to 32bit from 8bit/16bit without converting to linear? I need to be able to preserve the numerical values of the pixels and save as an EXR.

An example of why I might want to do this: I have an 8bit normal map and a 32bit normal map. Both are correct as far as pixel values go. Now I want to mix them together, I'm finding there is no way to convert the 16bit image to 32bit without linearizing the image. I don't care about preserving the look of the image, I care about preserving the numerical values of the pixels.

Link to comment
Share on other sites

Hi @GabrielM, just to be clear (and maybe a little nit-picky). I'm not looking for a non-linear 32-bit profile; I'd like for it to still be linear. I would like to have the option for AP to not perform a gamma correction to my image when switching to 32bit. A concrete example that I have just run into. I have a 16bit normal map. I am currently trying to convert all my images to EXRs in the ACEScg colorspace for consistency. Now, If I was in Nuke I'd set my read node to Utility - Raw then save it as an EXR (and still work with the image in a linear colorspace). The pixel values did not change and the image went from 16bit to 32bit with no gamma correction. In AP there is no way to open a 16bit image and save it as an EXR without a gamma correction. This makes saving images (originally 16bit) like displacement, normal, spec, etc. as EXRs impossible in AP as the gamma correction destroys the integrity of the images. After conversion I'd like the profile to still be linear, I don't really care if the image looks different when converted to linear.

Hopefully this makes the use case for this feature a little clearer.

Link to comment
Share on other sites

  • Staff
On 3/18/2019 at 2:33 PM, plobnop said:

Hi @GabrielM, just to be clear (and maybe a little nit-picky). I'm not looking for a non-linear 32-bit profile; I'd like for it to still be linear. I would like to have the option for AP to not perform a gamma correction to my image when switching to 32bit. A concrete example that I have just run into. I have a 16bit normal map. I am currently trying to convert all my images to EXRs in the ACEScg colorspace for consistency. Now, If I was in Nuke I'd set my read node to Utility - Raw then save it as an EXR (and still work with the image in a linear colorspace). The pixel values did not change and the image went from 16bit to 32bit with no gamma correction. In AP there is no way to open a 16bit image and save it as an EXR without a gamma correction. This makes saving images (originally 16bit) like displacement, normal, spec, etc. as EXRs impossible in AP as the gamma correction destroys the integrity of the images. After conversion I'd like the profile to still be linear, I don't really care if the image looks different when converted to linear.

Hopefully this makes the use case for this feature a little clearer.

Hey there. Photo doesn't perform destructive gamma correction on 32-bit documents—it's a non-linear view transform mandated by the ICC display profile. This is the default view because the majority of users will be merging bracketed exposures for HDR imagery, and they will need to see an accurate rendition of what happens when they export to an exchange format with a non-linear profile (e.g. JPEG/TIFF sRGB). All of the compositing is done in linear space (and so all of the tools/adjustments/filters work in linear space). When you export back to EXR it should be linear, regardless of the ICC display transform—have you tried exporting back to other software yet?

You can switch to a linear view through the 32-bit Preview panel (found under View>Studio)—choose Unmanaged. The image should then look consistent with Nuke's rendering.

A good way of confirming that the document itself is still linear is to use the colour picker: colour pick a value and look at the RGB values. Now switch the view transform (e.g. from ICC Display Transform to Unmanaged) and colour pick again—the value will stay consistent. The colour picker only reports linear values, it's not influenced by the view transform.

For your workflow, it sounds like you may want to use an OpenColorIO configuration. You could use an OCIO view transform on the 32-bit Preview panel which matches your requirements.

The other consideration is colour space conversion during EXR import/export. Photo always converts to scene linear upon import. You said you're working in ACEScg—if you use that ACES configuration from the official OpenColorIO.org website, you can append your EXR filenames with "acescg". Photo will then convert from ACEScg to scene linear ensuring your colour values are accurate (you'll get an on-screen toast to confirm this). When you export, if you intend to maintain that colour space, append "acescg" to the filename and Photo will convert back from scene linear to ACEScg.

Apologies as that's a wall of text, but hopefully it addresses your issue? Look forward to hearing from you!

Product Expert (Affinity Photo) & Product Expert Team Leader

@JamesR_Affinity for tutorial sneak peeks and more
Official Affinity Photo tutorials

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.