Tiled multi layer exr output

[hstokholm]

https://openimageio.readthedocs.io/en/v2.4.4.2/imageoutput.html#multi-image-files

Is it correct for openEXR output that doesn't support 'appendsubimage' that I need to write full layer, append and write the next layer and so forth?

I am currently receiving a tile of the image with all layers that I want to stream to the exr file, so I would like to have all subimages open for writing, but it doesn't seem to be possible.

Alternatively I would write the layers to individual exr files and merge afterwards, but it would be nicer to keep it in one file.

[lgritz]

"Appendsubimage" perhaps isn't quite what you think it is.

There are two ways to write multiple subimages (illustrated below schematically, this is not working code):

// Method 1: send one subimage at a time -- keep appending new subimages
// simply by repeatedly "opening" with AppendSubimage mode:
out = ImageOutput::create("filename");
out->open("filename", imagespec_for_first_subimage, Create);
out->write_image(...);   // first subimage
out->open("filename", imagespec_for_second_subimage, AppendSubimage);
out->write_image(...);   // second subimage
out->close();

// Method 2: must pre-declare the number of subimages and their ImageSpec's up front:
ImageSpec all_subimage_specs[2];
out = ImageOutput::create("filename");
out->open("filename", 2 /* subimages */, all_subimage_specs);
out->write_image(...);   // first subimage
out->open("filename", all_subimage_specs[1], AppendSubimage);
out->write_image(...);   // second subimage
out->close();

See the subtle difference? The first one, you never say how many subimages there are or give the specs up front, you just keep appending and then you close to say you're done. But for the second one, you must pre-declare them at the start.

The thing is, not all file formats let you do the simpler first one. For some file formats and their libraries, you just have to tell it up front when you first open the file how many subimages there are going to be and what they'll look like. The second way (predeclaring) is always okay. The supports("appendsubimage") tells you if you can do the first (no pre-declaration) for that format.

Turns out that TIFF (to pick one example) allows the first way, but OpenEXR does not. So you have to use the second method -- declaring the number of subimages you will want up front -- if you are outputting to an exr file.

Now, please note that BOTH of these methods require you to fully communicate one subimage before moving on to the next. It's only a question of whether you need to predeclare the number and ImageSpecs of the subimages up front.

Neither method allows you to compute the image bit by bit -- say, in tiles -- and send tile 0 of subimage 0, then tile 0 of subimage 1, then tile 0 of subimage 2, and then send tile 1 to all three subimages.

I can see why you'd want to write in "random access" any tiles to any subimage/part in any order, but it's not currently supported by the OIIO API. I was going to write that I don't know of any image file format libraries that allow that, but now that I look, it might be that OpenEXR does allow this? I'm really not sure. If it does allow it, maybe we should expand the ImageOutput API to allow it. But currently there is no way to express this through OIIO's APIs. I think that what you need to do for now is write the parts to different image files, then combine them into one multi-part file afterwards.

[hstokholm]

I appreciate you taking the time to answer!

Seems like it is working as I thought. I have implemented a test now where I am streaming each subimage to a temporary file first and then combining to a multi layer exr afterwards which seems to work for us. If we run into issues we can always convert to directly using OpenEXR for this task, it is just nice to use the common api for all our supported formats.

We are doing tilebased rendering of (possibly) very high resolution images, so we want to stream the output tile with all it layers to disk to avoid having the whole output buffer in memory.

[lgritz]

Yeah, I understand the desire. I'll double check that it works in OpenEXR and add a new API call to ImageOutput that would allow this (for formats that support it, which might only be OpenEXR). But I'm afraid it can only be in master for now because we can't add virtual methods to the release branch because it would break our ABI back-compatibility guarantees for release branch families.