OIIO's texture system does this, too: the "display window" (a.k.a. "full" size)
is the part that maps to texture space [0,1].
I still feel strongly that for the lowest level operations, ImageOutput should
write the data, the whole data, and nothing but the data -- it should never add
nor delete pixels values on its own, regardless of whether or not the format
supports the notion of separate display/view vs pixel/data windows.
The higher-level tools (iconvert, oiiotool) are another story entirely, and I'm
willing to bow to common sense, consensus, or precedent of other apps. The two
cases we care about are when the input image (a) has a data window smaller than
the display window (a crop window) or (b) has a data window larger than the
display window (overscan regions), but the output image format does not support
these notions at all (e.g. JPEG). What should happen? What do other programs
do?
Hugh implies that Shake would pad with some black (or some kind of settable
background color?), or crop to the display window. Do you agree?
Anybody familiar enough with Nuke to know what it does in these circumstances?
Jeremy, do you have an opinion on any of this?
-- lg
On Oct 17, 2011, at 7:59 PM, Simon Bunker wrote:
> I think I'd agree with Hugh. From a rendering viewpoint rather than a 2D one,
> txmake and tdlmake both consider the Display Window to be the actual image
> when converting from exr files. I can't remember txmake, but with tdlmake
> this was a real pain to deal with when it used the datawindow and was
> considered to be a bug (by us at least!)
>
> Simon
>
> On Sun, Oct 16, 2011 at 3:02 AM, Hugh Macdonald <[email protected]>
> wrote:
> Apologies for the delay in responding to the thread - I've been off on
> holiday for the past week or so.
>
> I think that the main disagreement here is (or will be) about which is what
> we care about more - pixel data, or image data.
>
>
> From the EXR Technical Introduction PDF
> (http://openexr.com/TechnicalIntroduction.pdf): (bottom of page 3)
>
> * The boundaries of an OpenEXR image are given as an axis-parallel
> rectangular region in pixel space, the display window.
> * An OpenEXR file may not have pixel data for all the pixels in the display
> window, or the file may have pixel data beyond the boundaries of the display
> window. The region for which pixel data are available is defined by a second
> axis-parallel rectangle in pixel space, the data window.
> * For a background plate that will be heavily post-processed, extra pixels,
> beyond the edge of the film frame, are recorded and the data window is set to
> (-100, -100) - (2019, 1179). The extra pixels are not normally displayed.
> Their existence allows operations such as large-kernel blurs or simulated
> camera shake to avoid edge artifacts.
>
> This implies to me that the *image* is the display window.
>
>
> In most of the image processing tools that we use (well, Shake and Nuke,
> anyway), if you were to load up an image with a display window of
> (0,0)-(2047,1555), but a data window of something like (400,400)-(500,500),
> it would be treating it internally as an image of resolution 2048x1556.
>
> I would expect, for example, the same behaviour between the following two
> commands:
>
> shake -fi colorwheel.exr -fo colorwheel.dpx
> oiiotool colorwheel.exr -o colorwheel.dpx
>
>
> While most people who have replied to this thread so far do seem to disagree
> with me on this (thanks Ciaran for agreeing!), I would suggest that, as OIIO
> is used more and more, people (like me) will start picking it up for the same
> kind of thing that we're using it for, and will find the same confusion.
>
> There was some mention in another thread that I started of getting OIIO
> integrated into tools like Nuke. If this were done, the default behaviour in
> the Write node would need to be what I've been pushing for. It would seem
> strange if OIIO inside of Nuke behaved differently from OIIO outside of Nuke.
> (And I suspect that there would be an outcry if the Nuke Write node acted the
> same as oiiotool currently does!)
>
>
> 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 18:09, Larry Gritz wrote:
>
>> On Oct 5, 2011, at 9:57 AM, Ciaran Wills wrote:
>>
>>> I'm with Hugh on this one - for formats that don't have data windows
>>> I'd expect to get the display window, with the pixel data
>>> padded/cropped to fit. Maybe it's from too many years of using Shake
>>> but that's what I'd see as the 'expected' behaviour.
>>
>> Honestly, I don't have a strong opinion on the default oiiotool behavior.
>> We'll let people comment for a couple days, and if the consensus is that
>> oiiotool should pad/crop when outputting to a format that doesn't support
>> separate display/data windows, I'll go along with it. My line in the sand
>> is simply that ImageOutput's should not add or delete pixel data on their
>> own.
>>
>>
>>> On an aside - display windows with the origin != (0, 0) are a pain in
>>> the arse, and I kinda wish EXR hadn't allowed them ;)
>>
>> It's a shame you can't even get those guys to return your phone calls. :-)
>>
>> --
>> 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
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
