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

[Barnaby Robson]

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