I think I'd agree with Hugh. From a rendering viewpoint rather than a 2D one, txmake and tdlmake both consider the Display Window to be the actual image when converting from exr files. I can't remember txmake, but with tdlmake this was a real pain to deal with when it used the datawindow and was considered to be a bug (by us at least!)
Simon On Sun, Oct 16, 2011 at 3:02 AM, Hugh Macdonald <[email protected] > wrote: > Apologies for the delay in responding to the thread - I've been off on > holiday for the past week or so. > > I think that the main disagreement here is (or will be) about which is what > we care about more - pixel data, or image data. > > > From the EXR Technical Introduction PDF ( > http://openexr.com/TechnicalIntroduction.pdf): (bottom of page 3) > > * The boundaries of an OpenEXR image are given as an axis-parallel > rectangular region in pixel space, the display window. > * An OpenEXR file may not have pixel data for all the pixels in the display > window, or the file may have pixel data beyond the boundaries of the display > window. The region for which pixel data are available is defined by a second > axis-parallel rectangle in pixel space, the data window. > * For a background plate that will be heavily post-processed, extra pixels, > beyond the edge of the film frame, are recorded and the data window is set > to (-100, -100) - (2019, 1179). The extra pixels are not normally displayed. > Their existence allows operations such as large-kernel blurs or > simulated camera shake to avoid edge artifacts. > > This implies to me that the *image* is the display window. > > > In most of the image processing tools that we use (well, Shake and Nuke, > anyway), if you were to load up an image with a display window of > (0,0)-(2047,1555), but a data window of something like (400,400)-(500,500), > it would be treating it internally as an image of resolution 2048x1556. > > I would expect, for example, the same behaviour between the following two > commands: > > shake -fi colorwheel.exr -fo colorwheel.dpx > oiiotool colorwheel.exr -o colorwheel.dpx > > > While most people who have replied to this thread so far do seem to > disagree with me on this (thanks Ciaran for agreeing!), I would suggest > that, as OIIO is used more and more, people (like me) will start picking it > up for the same kind of thing that we're using it for, and will find the > same confusion. > > There was some mention in another thread that I started of getting OIIO > integrated into tools like Nuke. If this were done, the default behaviour in > the Write node would need to be what I've been pushing for. It would seem > strange if OIIO inside of Nuke behaved differently from OIIO outside of > Nuke. (And I suspect that there would be an outcry if the Nuke Write node > acted the same as oiiotool currently does!) > > > Hugh Macdonald > *n**vizible** – VISUAL EFFECTS > * > [email protected] > +44(0) 20 3167 3860 > +44(0) 7773 764 708 > > www.nvizible.com > > On 5 Oct 2011, at 18:09, Larry Gritz wrote: > > On Oct 5, 2011, at 9:57 AM, Ciaran Wills wrote: > > I'm with Hugh on this one - for formats that don't have data windows > > I'd expect to get the display window, with the pixel data > > padded/cropped to fit. Maybe it's from too many years of using Shake > > but that's what I'd see as the 'expected' behaviour. > > > Honestly, I don't have a strong opinion on the default oiiotool behavior. > We'll let people comment for a couple days, and if the consensus is that > oiiotool should pad/crop when outputting to a format that doesn't support > separate display/data windows, I'll go along with it. My line in the sand > is simply that ImageOutput's should not add or delete pixel data on their > own. > > > On an aside - display windows with the origin != (0, 0) are a pain in > > the arse, and I kinda wish EXR hadn't allowed them ;) > > > It's a shame you can't even get those guys to return your phone calls. :-) > > -- > 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 > >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
