Hi Larry, I personally can see a need to write entire image parts in a more flexible fashion, rather than tiles - I cant talk about the details on-list, but recently I had to deal with stereo pairs of EXRS each with 400+ channels, and selectively output multipart stereo EXRs with 200+ parts per frame - I could do the job with OIIO, but having more flexible APIs for multipart would be nice.
Thanks -Pete > On 8/03/2016, at 8:48 AM, Larry Gritz <[email protected]> wrote: > > 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 _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
