Short reply: I agree with Larry on this one. Longer reply:
Based on how things have been going here at DWA, I'm increasingly seeing the "dislpayWindow" and simply metadata, and increasingly arbitrary metadata. It's useful for sure, but no everyone dealing with the image has the same notion of what the displayWindow is. For a long time, our displayWindows were the final delivery image size, and adding paddings added were outside the display window. But then it was noted that actually almost every artists needs to display (render, view and check) pixels outside the display window and that only a few people right at the end of the pipeline really care about only the pixels in it. (Lots of this was due to horizontal padding for last minute stereo shifts, as Colin mentions). So, today, our displayWindow is actually bigger than the final delivery image resolution. This is all to say that I think the "dataWindow" *is* the image, and the displayWindow is simply metadata. If I convert a EXR to a JPG, I want the dataWindow almost all the time. I think it's great if oiiotool has a option to "pad/crop the image to the display window" and this be easy to do when converting, but I don't think that should be the default behavior. Since we're playing with names, I like width/height as they are, but I wouldn't have used the terms "full_width" and ""full_height", preferring "display_width", etc. ---jono On Wed, Oct 5, 2011 at 4:53 AM, Hugh Macdonald <[email protected]> wrote: > What about the situation (which is more of the case for me) where the data > window is far smaller than the display window. > I would still far prefer the default behaviour to be to use the display > window and then a -dataWindow toggle that sets it to the full data window > (either enlarging or shrinking) > 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 12:39, Colin Doncaster wrote: > > Hi there - > I'm not too sure if this falls under the remit of what OIIO should manage > but there's also the argument that you're data window is what you care about > right now and your full_x/y is what you might need in the future. In the > past we've used this when rendering stereo elements, the data window is the > HD frame with a larger area ( usually horizontally ) for post stereo > adjustments - especially useful when dealing with parallel stereo output. > Most of the time the file format stays the same through out the pipeline ( > so it's a non issue ) but there are instances where DPX versions of the > files are created where the meta data is read from the EXR and passed > through the pipeline as a side car xml. > I think the command line option should be a toggle -displayWindow which > limits the output to the display window. Defaulting to using the full > window feels more correct as it always seems safer to retain data than > discard it. > cheers > -- > Colin Doncaster > Peregrine Labs > http://peregrinelabs.com > On 2011-10-05, at 3:20 AM, Larry Gritz wrote: > > On Oct 3, 2011, at 6:34 AM, Hugh Macdonald wrote: > > We discovered last week that, if we took an EXR with a data window that was > not it's display window (let's say, for example, that the display window is > 2048x1556, but the data window has the soundtrack area cropped off, and is > 1828x1556, with an xoffset of 220), if you used oiiotool to convert this EXR > to a DPX, the DPX would end up the size of the data window and not the size > of the display window. > > I was pretty long-winded before, so let me reply once again as simply as > possible: > > I think the behavior of the ImageOutput implementations is correct and > doesn't need modification. What you really want is a new oiiotool command > that means "pad or crop to the display window size" that you execute right > before output. (Open question: should this be unconditional, with the user > expected to use that option when outputting to a format that doesn't support > separate display/data windows? Or should option only do the padding for > formats that don't support data/display windows, necessitating the > supports() changes that Hugh suggests?) > > > -- > 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 > > _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
