Update: I think I was under the impression that we were always outputting these tags (XRESOLUTION, YRESOLUTION, RESOLUTIONUNIT) for every TIFF files and that they were probably set to something stupid by default, and thus changing our interpretation of [XY]POSITION to be relative to them would create a huge compatibility break.
But upon closer inspection of the code, it looks like we don't output them by default at all, only doing so if we are passed those attributes in the ImageSpec, which I think rarely happens. (I mean really, what apps in the VFX world would ever care to set the DPI as if it were on paper? For print applications, sure, but that's not our main audience.) So to the best of my knowledge, very few TIFF files will be found to be in the "ambiguous" state. Therefore, I'm going to propose a patch (probably not until I have a chance to mess with it over the weekend) to fix our interpretation of the POSITION fields to be in line with what we believe is the correct interpretation of the TIFF spec. > On Mar 1, 2017, at 2:29 PM, Larry Gritz <[email protected]> wrote: > > 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] > > -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
