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
