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