Here's the proposed patch related to this: https://github.com/OpenImageIO/oiio/pull/1631
It makes me nervous. (Though I'm also not happy about the software misinterpreting the field.) Turns out that many digital cameras write JPEG files with the density (aka RESOLUTION) tags having particular values, presumably so that if imported into a document or printed, it will end up with a reasonable default size on paper. But if you convert that file to TIFF, it will carry the resolution fields with it. If you then crop the TIFF, you'll have that combination of non-1 resolution and non-0 origin whose interpretation will change with this patch. I try to mitigate by having the TIFF reader examine the "Software" metadata field and trying to detect an OIIO version number, in which case I can know quite certainly if it was written by an OIIO from before the patch and adjust behavior accordingly. But this won't work for non-OIIO apps. Bottom line: if you EVER use TIFF files with crop windows (non-0 origin), please look over this patch very carefully, maybe test it out before we commit, to identify any fatal problems that would indicate that we shouldn't merge this. > On Mar 2, 2017, at 10:50 AM, Larry Gritz <[email protected]> wrote: > > 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 -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
