#60 Multipage support for EXR format
A quick search of OpenEXR wrappers shows that a large number (maybe even a majority?) of tools that support EXR images do so through FreeImage. Perhaps on accident, FreeImage has become the de facto way that many developer shops interact with EXR files.
That's why I'm passing along a feature request that I first received at GitHub. I've also attached the sample file shared there as it was helpful for studying how FreeImage could support multi-layer EXR files via its existing multipage functions.
EXR files are increasingly distributed as multi-layer files. Multilayer files are normal EXR files, but they contain (possibly many) more channels than a standard 3- or 4-channel image. Channels from the same layer share a name - for example, the attached file has channel names like "Background.B, Background.G, Background.R" which together comprise the RGB layer "Background". Another RGB layer is comprised of the "Shadow.B", "Shadow.G", and "Shadow.R" channels.
Supporting multipage EXR files in FreeImage would be straightforward. It wouldn't (I think) require any changes to FreeImage's existing single-page EXR support either, so existing single-page EXR compatibility would not change.
My proposal is that FreeImage could easily support these multipage EXR files by simply treating each channel as its own page. This would allow callers to retrieve each channel as a single grayscale DIB, which they could then assemble into discrete "layers" or "pages" using the channel names. This would free FreeImage from needing to perform string-matching for each channel - leave that up to the caller!
Writing multipage EXR files could work similarly: let the caller write each channel as an individual grayscale "page". Setting and retrieving EXR channel names would likely require an extension to FreeImage's metadata functions.
Other than this, changes to the library would be minimal. Much of FreeImage's existing EXR plugin could be reused - for example, the plugin already iterates all EXR channels, e.g. line 212 of PluginEXR.cpp: for (Imf::ChannelList::ConstIterator i = channels.begin(); i != channels.end(); ++i) { . FreeImage just ignores all channels after the first RGB/A match.
As an added bonus, this feature would give FreeImage users the ability to manually handle EXR formats FreeImage itself cannot, like grayscale+alpha files. Callers could simply use the multipage functions to retrieve and assemble any channels that FreeImage itself doesn't understand.
Thank you in advance for considering this. I think many FreeImage users could make meaningful use of this enhancement, and given how many applications already rely on FreeImage for EXR support, I think the wider EXR ecosystem would also benefit greatly.
Discussion
Anonymous
Attached is a second, smaller image for testing. It may be a simpler reference point. This image opens just fine with FreeImage's existing EXR plugin, but obviously only one page (of many) is loaded.
(Also, the free, open-source software Krita provides a good 3rd-party tool for loading and saving these types of EXR images.)
I will take a look at that again. I also played around some 10 years ago, but dropped it because it was not important enough for me at the time.
In any case multipage is becoming more and more important w/ basically ALL modern formats having animation or burst-mode in them.
Thank you, Mihail!
Hi,
If I try to load "untitled.zip", I see the error message attached.
How to convert such an image to a displyable image when using default loading options (i.e. EXR flags == 0) ?
Hervé
Hi Hervé, thank you for your reply. It has been a few months since I looked at this so I will need to investigate why FreeImage doesn't load "untitled.zip" above.
For a reference image that does currently load into FreeImage, there is x35_3a.exr in the 2nd post, above. It is a much smaller image comprising ~17 layers and FreeImage will happily load the first layer (using default EXR flags).
Hi Tanner,
The problem is not the error message itself (I coded its format together with the EXR plugin), but the way to interpret such images when loading an EXR with default flags.
In facts FI mainly support a single color model : RGBA. How to transform a layer model into a color model ? better reject it if its not understandable ?
Hervé
Last edit: Hervé Drolon 2021-01-23
Hi Hervé,
Thank you for the clarification. I apologize that I misunderstood your original comment (and I apologize in advance if I still misunderstand!).
Ignoring multi-page support for a moment, if FreeImage does encounter a multi-layer EXR file, a great improvement to its current behavior would be to simply load the first RGB/A layer it encounters.
In the case of multi-layer EXR export from e.g. Blender, the first layer in the file will usually be an RGB/A-format composite copy of the image (similar to the composite copy of a multi-layer image in a PSD file). So for software that doesn't care about multi-layer support (like viewers), FreeImage could still return a useful image for them.
In the case of untitled.zip above, the full embedded channel list is quite long, but you can see that the first four channels are standard RGBA ones that contain a nice composite copy of the image:
So for default FreeImage behavior with default EXR flags, I would think it a very useful improvement for FreeImage to simply check the first 3/4 channels in the image. If they are in RGB/A format, FreeImage can return that RGB/A image by default. This alone would make FreeImage's behavior on e.g. untitled.zip much better!
Returning to multi-page support as a possibility, my original suggestion was for FreeImage to not concern itself with the many color-format possibilities in an EXR file. Instead, it would be very helpful to have a new EXR flag that allows the user to load EXR files into FreeImage in 1) multipage format, and 2) where each channel is treated as its own grayscale page in FIT_FLOAT format.
So for untitled.zip above, Composite.Combined.A float would be the first page, Composite.Combined.B float would be the second page, etc.
The benefit of this is that the user can then utilize as many or as few channels as they require, regardless of FreeImage's ability to understand all the color formats involved, because FreeImage just treats the file as a list of individual grayscale "pages", without concern for whether those pages are R/G/B/A or X/Y/Z or something else. Mixed color models becomes the caller's problem.
The burden of this approach is that it would require a new function (or metadata model) so the user can retrieve page/channel names. I do not know the easiest or best way to expose this using the current FreeImage design, unfortunately.
hi, is it yet possible to read the layers of a multilayer exr and then save back out to a multilayer EXR with freeimage?