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 nvizible – 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
