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
