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've submitted a pull request (Issue #176) for a fix for this. It works as
follows:
ImageOutput::supports() now has an extra feature that it may expect -
'datawindow'. Currently, only EXR, RLA and TIF return true for this.
In the open() function for each of ImageOutput's subclasses, instead of setting
'm_spec = userspec;', they now call 'stash_spec(userspec);'. This sets m_spec,
but also, if supports('datawindow') returns false, sets m_spec.width =
m_spec.full_width, m_spec.height = m_spec.full_height, etc.
Lastly, in ImageBuf::write(), if the ImageOutput that it's going to write to
does not support('datawindow'), and the ImageBuf's width/height/etc don't match
full_width/full_height/etc, then it calls ImageBufAlgo::crop() to create a new
ImageBuf object with the right amount of data in, and then calls write() on the
new ImageBuf object.
Any thoughts? I'm thinking that the method for padding/cropping could be more
efficient, but I didn't want to be changing the ImageBuf in place, just in case
it had wider-ranging effects.
Hugh Macdonald
nvizible – VISUAL EFFECTS
[email protected]
+44(0) 20 3167 3860
+44(0) 7773 764 708
www.nvizible.com
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
