The first stab at the UDIM stuff is in OIIO master. I'm mulling over how to support Bruce's suggestion about UDIM-in-one-file, it seems like a neat idea.
I agree with Jono that if DWA has already proven no negative effects in practice of lifting the same-data-window restriction on multi-part files, that would be a nice patch to put in the mainline of openexr. > On Jun 13, 2016, at 5:23 PM, Jonathan Gibbs <[email protected]> wrote: > > If I recall correctly, when this stuff was added in 2.0, there were > discussions about if this should be a requirement or not. It was decided to > be conservative we'd start with the requirement, and then look to lift it in > a later version. Looks like it's not lifted yet, but technically could be > soon. Maybe make a push for this to be lifted in the next version? > > --jono > > > On Thu, Jun 9, 2016 at 3:38 PM Larry Gritz <[email protected] > <mailto:[email protected]>> wrote: > Haha, I sent this just as Karl's reply was coming. It is still a constraint > in the public version. > > I'm all for lifting the constraint... I was always of the opinion that > multi-part should be fully general subimages and not have any required > commonality. > > >> On Jun 9, 2016, at 3:35 PM, Larry Gritz <[email protected] >> <mailto:[email protected]>> wrote: >> >> Ah, ok, I must be remembering a restriction from an older version. >> >> -- lg >> >> >>> On Jun 9, 2016, at 3:20 PM, Andrea Solis <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> >>> On Thu, Jun 9, 2016 at 2:33 PM, Larry Gritz <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> I'd never heard or thought of the multipart UDIMs. That's a neat idea, I'm >>> sure we can make that work somehow. It seems in that case that you want to >>> give it the one and only true filename (no translation necessary), but then >>> have the UDIM tile select a subimage ("part", in EXR terminology). I think >>> that if we build this into maketx somehow, it can also add an attribute >>> into the header that identifies it as a UDIM file. >>> >>> IIRC, OpenEXR multi-part files are not allowed to have differing >>> resolutions for the parts. Is this not a fatal flaw here? Or in practice is >>> that not a problem for you? I would have thought that allowing the >>> different "tiles" to have differing resolutions (higher res for tiles >>> corresponding to large pieces of the model, etc) would be typical for UDIM >>> practice. No? >>> >>> >>> At one time there was a requirement that only the display windows were the >>> same, not necessarily the resolution of the data. So prior to calling the >>> 'exrmultipart' command, we used 'oiiotool --fullsize' to set all display >>> windows to that of the highest resolution in the file set. But then that >>> requirement was lifted, at least as of version 2.1.0 we no longer have to >>> set the display windows equal. From this doc: >>> http://www.openexr.com/TechnicalIntroduction.pdf >>> <http://www.openexr.com/TechnicalIntroduction.pdf> >>> >>> "An OpenEXR file may contain multiple independent images or “parts” with >>> different sets of image channels, resolutions and data compression methods." >> >> -- >> Larry Gritz >> [email protected] <mailto:[email protected]> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] <mailto:[email protected]> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> > -- > Larry Gritz > [email protected] <mailto:[email protected]> > > > _______________________________________________ > Oiio-dev mailing list > [email protected] <mailto:[email protected]> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > <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 -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
