Hi all, just joined the list and I thought I'd weigh in on this discussion
since I'm trying to manage some data/display window issues at the moment for
DWA.
(please forgive me if I'm arguing points already made - I've not read all the
past discussions yet)
Jono I have to disagree with you and Larry on this and heartily agree with Hugh.
I think you're overlooking the fact that DWA's notion of display windows is
quite rigid (a limited number of predefined display windows) while the EXR
display window can be different per image.
And it's not simply metadata because without a proper display window there's no
way to invert the data window's Y coordinate correctly for use in Y-up
applications (which is most apps these days) or to properly scale the image
data, or to properly conform the data window to another image's coordinate
system.
Think of the display window as the image intent (the target image,) while the
data window is simply the image contents floating around in space. You are
correct that the display window is 'simply metadata' in that it shouldn't
change over the course of an image sequence, but each and every image sequence
could have a different display window.
In fact - I'll make the argument that one additional important rectangle is
conspicuously missing from the EXR spec - the 'projection window'. This would
be typically identical to the display window for a normal projection render,
but would be larger for expanded viewport renders. This is often handled by
simply expanding the data window, and this generally works fine unless the data
window is cropped (tightly fit) around the active content - then you no longer
have all the information about the expanded viewport. The 'projection window'
is that missing info. You could theoretically reconstruct the projection
window from using the matrices in the exr, but that presupposes that those
matrices even exist...
I can speak authoritatively to Nuke's handling of this as separating the notion
of the data window from the display window (the 'Format' structure in
Nuke-speak) was an important part of Nuke's redesign in the late '90s which I
led.
Up until that point Nuke only had a data window and the lack of an image intent
caused havoc with image resolution management as artists were forced to do it
themselves - and you know how that goes…
The 'Format' filled in the missing information that an app needs to
automatically manage imagery without a ton of user input - Nuke's Reformat node
is a good example of how well this can work.
Nuke's Format structure does support the idea of a projection window as a
separate rectangle but unfortunately doesn't allow it to be negative - which
was a big oversight... This oversight was due to it being defined before EXR
arrived on the scene and all popular image formats started at 0,0. The Format
has what's called an 'image area' (an unfortunate term which came from working
with anamorphic imagery with a soundtrack area on the left - the 'image area'
meant the active photographed area with an potentially offset center of scale
and rotation.)
So to translate Nuke-speak:
'Format w/h' = projection window
'Format image area' = display window
'bbox' = data window
And about the oversight of the non-negative projection window - I believe that
the display window's lower-left should *always* be pinned at 0,0 while the
projection window would go negative, and must always be >= display window.
But...because of the existing EXR spec the display window would likely need to
used for the projection window, and 'image area' would need to be a newly
defined width/height parameter (the 'intent'..?)
All scaling would be tied to the 'intent' width/height.
i.e. in Y+ coords:
intent [120 60]
disp [-40 -40 160 100]
data [32 35 67 70]
|----------------------------|
| |
| |----| |
| |---------|------| |
| | | | | |
| | | | | |
| | |----|data | |
| | | |
| |----------------|intent
| 0,0 |
| |
|----------------------------|disp
-jonathan
> Short reply: I agree with Larry on this one.
>
> Longer reply:
>
> Based on how things have been going here at DWA, I'm increasingly
> seeing the "dislpayWindow" and simply metadata, and increasingly
> arbitrary metadata. It's useful for sure, but no everyone dealing with
> the image has the same notion of what the displayWindow is. For a long
> time, our displayWindows were the final delivery image size, and
> adding paddings added were outside the display window. But then it was
> noted that actually almost every artists needs to display (render,
> view and check) pixels outside the display window and that only a few
> people right at the end of the pipeline really care about only the
> pixels in it. (Lots of this was due to horizontal padding for last
> minute stereo shifts, as Colin mentions). So, today, our displayWindow
> is actually bigger than the final delivery image resolution.
>
> This is all to say that I think the "dataWindow" *is* the image, and
> the displayWindow is simply metadata. If I convert a EXR to a JPG, I
> want the dataWindow almost all the time. I think it's great if
> oiiotool has a option to "pad/crop the image to the display window"
> and this be easy to do when converting, but I don't think that should
> be the default behavior.
>
> Since we're playing with names, I like width/height as they are, but I
> wouldn't have used the terms "full_width" and ""full_height",
> preferring "display_width", etc.
>
> ---jono
>
>
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
