RE: [Openexr-devel] The Data Window and how to handle it ...

[Barnaby Robson]

Hi Florian,

Thanks for the reply.

Maybe I didn't explain this well enough but I am actually a big
fan of the data window / display window feature of OpenEXR.
I fully understand it and my software handles it very well.

My disappointment came when I noticed that other software
on the market did not handle it well. 

This is what made me try to find a solution to that problem.

Obviously the best thing would be for companies to fix their 
programs so that they respect the data window / display window.
But, being a realist (/pessimist!), I think that it won't happen for quite 
a while, if ever.

I understand your point of view though. Why should the OpenEXR
format try to fix something that you have already found a solution for?
I agree that a 3rd (optional) window is slightly confusing but
it is the only thing that works across the board at this time.
 
Thanks again for listening.

barnaby


-----Original Message-----
From: Florian Kainz [mailto:address@hidden
Sent: Monday, January 16, 2006 8:44 PM
To: Barnaby Robson
Cc: address@hidden
Subject: Re: [Openexr-devel] The Data Window and how to handle it ...


Hi Barnaby,

I have to admit that I don't particularly like the idea of introducing
a third "window" attribute to describe the extent of the image that is
stored in an OpenEXR file.

The data window / display window concept may be somewhat confusing, but
it implements two features that are desirable for actual production use:

1) The image file contains pixels outside the area that is normally
    displayed.   The extra pixels avoid edge artifacts during image
    processing operations such as repositioning or filtering with
    kernels that extend beyond the edge of the display.

2) In order to save time, only the pixels inside a small region of
    the overall image have been computed.   Pixels outside this region
    are unknown.  We don't want to store the unknown pixels in the
    file, but we have to store the size and location of the known
    region relative to the display boundaries.

Given that the display window and data window are being used, we can't
simply withdraw this feature from OpenEXR.  With a "domain of definition"
window it would be possible to handle case 2 by setting the display and
data windows equal to the display boundaries, placing the upper left
corner at (0,0).  However, this would not cover case 1.  In addition,
application programs that don't correctly handle the display and data
windows still wouldn't be able to deal with existing image files where
the display and data windows are not aligned.  Those programs need to
be fixed, with or without the domain of definition window.

A while ago, ILM added a set of test images to the OpenEXR sample image
collection, specifically to help application writers test their handling
of the data and display windows.  The exrdisplay program displays those
test images the way we think they should be displayed.  (See files README
and t01.exr ... t16.exr in the DiѕplayWindow subdirectory.)

Florian


Barnaby Robson wrote:
> Hello
>  
> A natural thing that I, and I am sure many other developers, have done 
> is to write an application to be
> run as a post rendering step that reads an image, calculates the axially 
> aligned bounding box of the
> non zero data inside the file and then proceeds to write out a new file 
> with the display window left as is
> and the dataWindow set to that bounding box. 
>  
> The problem with this type of program is that the resulting file is not 
> handled well by other apps.
>  
> It has been my experience so far that the dataWindow / displayWindow 
> concept is not
> well standardized across applications.  For example if you open an 
> OpenEXR file in
> Photoshop CS2 or Framecycler 2.7 the only thing displayed is the 
> contents of the dataWindow.
> Whereas if you open the same image in Shake, for example, your image is 
> sized according to the
> displayWindow and the only pixels read are those in the intersection of 
> the display and data
> windows. ( With the Shake DOD is set to the dataWindow ). 
>  
> I understand that negative values in the displayWindow / dataWindow are 
> difficult to resolve
> because you have to translate the image to the standard (0,0) origin 
> of the application via
> transforming or cropping. However I feel that (e.g.) Photoshop's 
> interpretation is not good
> as it is destructive to the file.  (If you resave the file you lose
> the original displayWindow which gets set to the dataWindow.)
>  
> In light of this problem I have changed my program to now save the AABB 
> of the non black portion
> of the file as a custom attribute in the header like so:
> 
> header.insert ("domainOfDefinition" , Imf::Box2iAttribute ( 
> computedDataWindow ) );
> 
> So .. my question is this ..
> At the moment the only solution to the problem of the display and 
> data windows 
> not being handled by other applications properly is to throw away 
> the dataWindow completely.
> As applications such as Shake are optimized by describing a DOD and this 
> is valuable information
> do we want to standardize an attribute name so that in the interchange 
> of images between facilities
> we can recognize it and use it ? 
>  
> Maybe we can even promote it to one of the standard attributes in 
> ImfStandardAttributes.h ?
>  
> I am not suggesting my name (domainOfDefinition) is the best at all ..
> I would be happy to take on any name that is decided upon.
>  
> The change to the Shake reader is fairly easy and now our facility is 
> set up for using this scheme.
>  
> You only need to add this code to the NRxOpenEXRReader::readHeader method.
>  
> hasFileHeaderDOD = false;
> if (!hasError) {
>     const Imf::Box2iAttribute *dod =
>     exrHeader->findTypedAttribute <Imf::Box2iAttribute> 
> ("domainOfDefinition");
>     if (dod)
>     {
>         Imath::Box2i displayWindow = exrHeader->displayWindow();
>         Imath::Box2i box = dod->value();
>         fileHeaderDOD.X1 = box.min.x - displayWindow.min.x;
>         fileHeaderDOD.X2 = box.max.x - displayWindow.min.x + 1;
>         fileHeaderDOD.Y1 = box.min.y - displayWindow.min.y;
>         fileHeaderDOD.Y2 = box.max.y - displayWindow.min.y + 1;
>         hasFileHeaderDOD = true;
>     }
> }
>  
> and this code to the eval method.
>  
> } else if (p == fOut->dod()) {
>     readHeader();
>     Imath::Box2i displayWindow = exrHeader->displayWindow();
>     Imath::Box2i dataWindow = exrHeader->dataWindow();
>     outputDod.X1 = dataWindow.min.x - displayWindow.min.x;
>     outputDod.Y1 = dataWindow.min.y - displayWindow.min.y;
>     outputDod.X2 = dataWindow.max.x - displayWindow.min.x + 1;
>     outputDod.Y2 = dataWindow.max.y - displayWindow.min.y + 1;
>     if (hasFileHeaderDOD)    
>     {
>     p->set(&fileHeaderDOD);
>     }
>     else
>     {
>     p->set(&outputDod);
>     }
> } else if (p == fOut->oBuf()) {
>  
>  
> Obviously you need two additional member variables (NRiIRect 
> fileHeaderDOD; bool hasFileHeaderDOD;)
> in exrFormat.h
>  
> Ok that's it ... what do you think ?
>  
> barnaby
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel