It's been pointed out (see discussion here: https://github.com/OpenImageIO/oiio/issues/1623) that when reading and writing TIFF files, OIIO is storing the image offset in in the TIFF fields XPOSITION & YPOSITION, always in pixel space units (e.g. 100,50 means the pixel data is like a crop window with origin is 100 pixels to the right and 50 pixels down from the theoretical image plane origin), regardless of the settings for XRESOLUTION, YRESOLUTION, and RESOLUTIONUNIT.
But the TIFF spec itself seems clear that the POSITION fields ought to be in the same units as are described by RESOLUTION and RESOLUTIONUNIT. So for example, if RESOLUTION=72.0 and RESOLUTIONUNIT=inches (meaning that the image represents 72 pixels per inch), then the crop window described about ought to have values XPOSITION=100/72 and YPOSITION=50/72, not 100 and 50. (The POSITION fields are "rational" numbers, not integers, which provides an additional clue about their original intent.) Now, if [XY]RESOLUTION=1.0, then of course these two cases are the same. OIIO has always saved image origin as integer pixel units, and I strongly suspect that the origin (excuse the pun) of this behavior is compatibility with various renderers that behaved the same way since the dawn of time. (PRMan?) A few apps have been identified that use these fields the "right" way. (Plenty more ignore these fields altogether, not supporting crop or overscan.) My question is: can we identify any apps that depend on the "wrong" interpretation? Is it even possible to correct this without widespread chaos? One way to stage a fix would be first to make sure that all OIIO output would be properly interpreted by both correct and incorrect readers. That is, any TIFF file with a nonzero origin would force RESOLUTION to be 1.0. And then in a later release, we can make the reader do the "right" thing. But even with this change to make TIFF output work for both old and new readers, you can't, for example, have a nonzero origin and a "resolution" of 72 pixels per inch. You also can't have non-square pixel aspect ratio, since that requires XRESOLUTION and YRESOLUTION to differ (and therefore one most be non-1.0). And there's still the matter of how the readers will recognize a file from an old writer and behave appropriately (though in OIIO's case, the "Software" field may be a reliable indicator). Feedback welcome. -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
