Wow, I guess I never fully realized that OpenEXR's API allowed for this! 
OpenEXR's addition of "multi-part" was a latecomer, compared to TIFF which has 
allowed multiple images in a file, but not random read or write access to them, 
and I guess I never reexamined those assumptions when OpenEXR added the ability.

Yes, in light of that, I think it does make sense to extend the API to have a 
variant of write_tiles that lets you specify the subimage. Of course, since 
most image formats (such as TIFF) do not allow this flexibility, apps will be 
cautioned to only use it for output formats for which 
supports("random_subimage_access") is true, otherwise it would be an error to 
write tiles to anything but the currently-opened subimage.

Do you think we need write_scanlines similarly modified? write_image? Or is the 
practical use case for this always going to be tiles?

What about input? Do you think it's important to allow reading of a tile from 
one part in a random access way, but without needing a seek_subimage to set the 
current subimage?

Let me think a bit about how to structure this. It seems to me that this is 
going to have to be a master-only feature, since adding it is going to break 
link compatibility with the existing ImageOutput class API and vtable.

        -- lg


> On Mar 7, 2016, at 3:38 AM, Ramon Montoya Vozmediano 
> <[email protected]> wrote:
> 
> Hi Larry,
> 
> OIIO supports output to multipart EXR images, and they have to be written out 
> like this:
> 
> open(multipart file with n parts)
> write_tiles(...)
> 
> open(...AppendSubimage)
> write_tiles(...)
> 
> open(...AppendSubimage)
> write_tiles(...)
> 
> close()
> 
> So you write out the first subimage, then the next, etc...
> 
> The motivation for this email is that with this setup, when you are 
> rendering, you need to keep all the tiles in memory before they can be 
> written out.
> 
> OpenEXR itself lets you write out tiles for any part in any order.
> 
> So, when using the EXR API directly, a renderer could write out tiles as soon 
> as they are done, and the physical layout of the multipart image would end up 
> looking like this:
> 
> [chunk offset index]
> [part 0, data for tile (0,0)]
> [part 1, data for tile (0,0)]
> [part 2, data for tile (0,0)]
> ...
> [part 0, data for tile (0,1)]
> [part 1, data for tile (0,1)]
> [part 2, data for tile (0,1)]
> ...
> 
> It looks like supporting this means extending OIIO's API, so that you can set 
> the part you want to write to, without having to close/open a "subimage".
> 
> Another way to look at this conceptually, is to consider an EXR part as a 
> channel grouping rather than a tiff style subimage.
> 
> Have you considered extending OIIO's API in this direction?
> 
> Best,
> 
> r
> 

--
Larry Gritz
[email protected]


_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Reply via email to