Yes, the crop/pad is optional, though consensus seems to be that it should be
the default (matching the behavior of both Nuke and Shake, if I understand
correctly). We'll have an option to turn it off.
The alternative (for example, in the case of a small data window traveling
across the display over the course of a shot) would be saving the frames out as
individual crops and losing all the original placement information. So you
couldn't composite the resulting frames or even display them properly with the
right placement.
The bottom line is that if you are doing computations on images with differing
data and pixel windows, you really should be outputting the results to a format
that supports that concept. Just like you should save textures to formats that
support tiles and MIPmapping, and you should be saving HDR data to a format
that supports some kind of floating-point pixels (half or float). In all those
cases, there are good and bad format choices, but we still want the tools to do
the most reasonable thing possible when giving those instructions.
-- lg
On Oct 19, 2011, at 4:11 AM, Colin Doncaster wrote:
> I agree with everything up to c. d should be optional, either do or don't I
> wouldn't care but it would be nice to NOT crop if you don't want to - though
> I imagine this was quietly implied.
>
> cheers
> --
> Colin Doncaster
> Peregrine Labs
> http://peregrinelabs.com
>
> On 2011-10-19, at 2:34 AM, Larry Gritz wrote:
>
>> a) ImageOutputs write pixels they are sent, as they currently do (no change
>> needed).
>>
>> b) But the ImageOutput::supports() method can be extended to allow the app
>> to query if the image format supports separate display/data windows.
>> Proposed syntax: supports("displaywindow")
>>
>> c) Add a simple, single utility function to handle the auto crop/pad:
>>
>> ImageBufAlgo::FixToDisplayWindow (ImageBuf &img, const std::string
>> &format)
>>
>> If the named format does not support display windows (or unconditionally,
>> if format == ""),
>> pad and/or crop the image so that its pixel data window exactly fills the
>> display window.
>> Padding is black, unless img's ImageSpec contains metadata
>> "oiio:bordercolor"
>> (of type float[nchans]) specifying a different border color to use for
>> pixels beyond the
>> data window.
>>
>> d) Change the default behavior of oiiotool and other image-writing utilities
>> to call this when writing images.
>>
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
