OpenEXR (*.exr) file format support

[Beep6581]

Originally reported on Google Code with ID 1911

Continuing issue 1575, and as requested in the forum ( http://www.rawtherapee.com/forum/viewtopic.php?f=2&t=4643
), can someone please adds OpenEXR support to RawTherapee (input/output) ?

Reported by natureh.510 on 2013-06-25 13:52:34

[Beep6581]

Would be so nice...

Reported by entertheyoni on 2014-10-12 19:53:50

[Hombre57]

Just to point out some key place in the code : OpenEXR doe not need demosaicing, so it's a Standard file format, whatever the bit depth is.

See StdImageSource::getSampleFormat in rtengine/stdimagesource.cc, this is where we detect the file format and set some variables for reading a file. Then few line below the load method will create the appropriate data representation, and call ImageIO::load (rtengine::imageio.cc) to fill it by reading the file.

To save a file, there are per-format dedicated functions in rtengine/imageio.cc that are called trough a parent class.

I don't know for metadata though, but OpenEXR is built over the TIFF standard, so we might be in known areas. Maybe the OpenEXR offer it own API. And color handling have to be supported as well, so it's definitely not a one day task.

[Beep6581]

Metadata support in OpenEXR through Exiv2 is planned but not done yet: http://dev.exiv2.org/issues/885

[Beep6581]

There is no standard way of storing metadata in EXR because the film industry doesn't seem to care about it like photographers do. darktable/GIMP store metadata in EXR using their own interoperable way: https://git.gnome.org/browse/gimp/tree/plug-ins/file-exr/openexr-wrapper.cc#n303 https://github.com/darktable-org/darktable/blob/master/src/common/imageio_exr.hh https://git.gnome.org/browse/gimp/tree/plug-ins/file-exr/exr-attribute-blob.h If RawTherapee supported EXR and used the same metadata storage solution, that would make RT interoperable with dt/GIMP at least wrt. metadata.

[cmrdt]

perhaps store metadata in separate file with same file but with different/extra file extension

[ZoomRmc]

Is there a reason RT can't support EXR as an input format? I'm integrating RT as a color grading tool in my video editing workflow and processing EXR would save me a bit of time and disk space for intermediate files.

[Hombre57]

@ZoomRmc No, there's no reason it can't support it. We just need someone willing to do it. I don't think it will be a full support though, as RT doesn't support alpha channel, but it could simply drop it or pass it through.

[ZoomRmc]

It would be really great, even without the alpha support. Hope some code can be pulled off from Blender.

[gregzaal]

Just adding another voice and hoping this idea doesn't die :)

EXR has become standard in the VFX world, for a long time already, and photography is now a big part of modern workflows when it comes to photoscanning texture sets, 3d models and HDRI environments. Being able to stick to a reliable format all the way through would be invaluable.

Right now the only alternative is uncompressed 16-bit tiff (uncompressed because the compressed version is far too slow to be practical when dealing with hundreds or thousands of images per scan), but these files are absolutely massive and a pain to work with.

Edit: talking about EXR as an output format.

[Entropy512]

@ZoomRmc Direct support for OpenEXR as an input format is pretty low on the priorities list, but if you provide an example file, I can test a script I've been working on that (as a workaround) will convert many formats supported by the imagecodecs Python module to float32 TIFF.

[Beep6581]

Hi @Entropy512 , just a general comment. Back in the day, I wanted OpenEXR support in RT to increase interoperability with LuminanceHDR. Since then RT gained the ability to read/write high bit depth TIFF and PNG, it also gained the Fattal tone-mapping operator (Dynamic Range Compression tool), and maybe LHDR can also handle 16/32-bit TIFF/PNG well now (I haven't checked in several years), so as you say, it's now low on the priorities list.

You can use LuminanceHDR to generate OpenEXR files. Easy compilation script: https://github.com/Beep6581/LuminanceHDR/blob/master/build-lhdr

[gregzaal]

Also to jump on the bandwagon of "this should be low-priority":

We tried using Darktable instead which supports outputing EXR very well. Exporting was indeed way faster than uncompressed TIFFs, the files were of course far smaller, and using them in other software (Reality Capture) was generally a bit quicker too.

But, it didn't maintain the photo metadata (exposure info, etc.), which means it has limited use for us. There were also some other unexpected technical issues with using EXR, and we ended up reverting back to TIFFs from RawTherapee ¯_(ツ)_/¯

[Entropy512]

At some point I need to play with LHDR more - I haven't used it much for similar reasons as @Beep6581 in recent years - Fattal in RT usually does the trick, and for the cases where it doesn't, exporting separate exposures and feeding them to enfuse usually does.

Interesting that exporting was significantly faster than uncompressed TIFF - I would expect compressed to be slow, but not uncompressed, other than darktable having the advantage of GPU acceleration for most of the pipeline to make the processing part significantly faster.

OpenEXR is not supported by imagecodecs, and the Python modules I have found so far for it are a little... clunky... to use. Imagecodecs is nice in that it returns a nice numpy array similar to what rawpy and a few other image I/O modules return. Still poking at it. Just not quite as easy as Radiance RGBE or JXR. https://dragly.org/2022/08/27/speeding-up-loading-openexr-in-python/ looks like an option, but chokes on the sample images I've found so far (complains about deep data not being supported yet)

[ZoomRmc]

@Entropy512, as far as I remember, I used EXR files as a by-frame exporting format for video editing in Blender. It provided much better compression ratio than TIFF (which is a significant benefit in a non-professional environment) and generally was faster.

[Entropy512]

Interesting, I'm surprised that unless you were using a lossy algorithm (such as B44) it outcompressed TIFF with predictor. (TIFF without an appropriate predictor is meh, and a lot of software doesn't do predictors... Perhaps Blender doesn't export TIFF using predictors for compression.)

PXR24 does appear to be (roughly) equivalent to TIFF predictor 3.

I've successfully converted an example EXR file to compressed TIF, but there are some weird artifacts in the result - but maybe the file itself is problematic. It's shockingly difficult to find sample EXR files other than the OpenEXR test suite - which contains mostly "extreme corner case" testcase files.

[Entropy512]

@Beep6581 I generated an EXR from what has become my "HDRMerge torture test" set... There are some pretty severe highlight artifacts, I don't know if it's a bad EXR conversion or LHDR exported with the artifacts.

https://discuss.pixls.us/t/python-image-conversion-scripts-intended-primarily-for-rawtherapee-input-but-useful-otherwise/33865 - I used the script I published there.

For reference, the EXR is 216M, converted TIF is 186M, HDRMerge DNG is 65M with fanckush's patches

[avclubvids]

Adding another +1 to EXR export support - the VFX industry uses it heavily for HDRI, it would be greatly preferred over TIFF and PNG for converting DSLR/Mirrorless images from raw!

[kmilos]

It's shockingly difficult to find sample EXR files other than the OpenEXR test suite

https://polyhaven.com/hdris

CC0 as well!

[avclubvids]

The Open Image IO (OIIO) project has a ton of file read/write conveniences that would allow RT to add far more than just EXR support all at once: OIIO

OIIO supports pretty deep EXIF and other metadata injection into EXRs and other file formats: OIIO Metadata

There's a bunch of sample EXRs on the Motion Picture Academy's Github: here

And there are thousands of free HDRI .exrs available on the web: CC-CBY: hdrmaps CC-C0: hdri heaven "free" iHDRI "free" noah witchell "free" (quasi CC-BY?): hdri-hub