OK, that sounds reasonable. I will add that to the current patch under review.
> On Jul 17, 2015, at 2:21 PM, John Burnett <[email protected]> wrote: > > Ah, got it - makes sense. Thanks for digging in! As for the defaults, I'd > lean towards making the --prman option imply "OIIO is doing everything it can > to make prman happy with the resulting tx file". In that context, I'd > definitely vote for having --prman imply tiff:write_exif=0 (especially since > even the latest prman is using libtiff 3.8.2). > > On Thu, Jul 16, 2015 at 5:13 PM, Larry Gritz <[email protected] > <mailto:[email protected]>> wrote: > This pull request I think allows you to fix this: > https://github.com/OpenImageIO/oiio/pull/1185 > <https://github.com/OpenImageIO/oiio/pull/1185> > > As explained in the PR, it requires an extra argument on the maketx command > line to set the special metadata that controls whether the Exif metadata is > suppressed. (In particular, you will add to the maketx arguments: --attrib > "tiff:write_exif" 0) > > I would entertain requests to make this happen automatically any time the > --prman option to maketx is used. But so far it doesn't happen by default. > > > > > On Jul 16, 2015, at 4:41 PM, Larry Gritz <[email protected] > > <mailto:[email protected]>> wrote: > > > > OK, I think I understand what's going on here. Certain older versions of > > libtiff did not properly understand the Exif-containing metadata. Our code > > checks the TIFF version it's compiled against, and doesn't use this if its > > libtiff is too old to get it right. But it doesn't really consider the case > > of OIIO (with modern libtiff) writing the texture file which is destined to > > be read by a different application that uses a much older libtiff (in this > > case, PRMan). > > > > I think perhaps the right thing to do is to make an option to suppress > > output of the Exif data when writing TIFF, in order to make a file that's > > safe for apps with older libtiff. > > > > Question: Do you think this should happen automatically whenever you use > > the --prman flag to maketx, or should it be a completely separate argument > > to maketx? > > > > > > > >> On Jun 17, 2015, at 7:40 PM, John Burnett <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> We are running into metadata issues with tif files created in oiio 1.5.16 > >> (after upgrading from 1.4.8). In both cases, we are building against > >> libtiff 4.0.3. > >> > >> As a repro, I started with a plain exr created with oiio 1.4.8: > >> > >> oiio-1.4.8/oiiotool --pattern checker 128x128 4 --ch R,G,B,=1.0 -d half > >> -o checker.exr > >> > >> And then created tx files with both 1.5.16 and 1.4.8 as a baseline: > >> > >> oiio-1.4.8/maketx --prman -o oiio-1.4.8.tx checker.exr > >> oiio-1.5.16/maketx --prman -o oiio-1.5.16.tx checker.exr > >> > >> Using tiffinfo built with libtiff 4.0.3 on oiio-1.5.16.tx image shows the > >> following printed to stderr: > >> > >> tiffinfo oiio-1.5.16.tx > /dev/null > >> TIFFFetchDirectory: Sanity check on directory count failed, zero tag > >> directories not supported. > >> TIFFReadCustomDirectory: Failed to read custom directory at offset 28686. > >> > >> ...and oiio-1.4.8.tx image shows no such issues. > >> > >> Lastly, using the tiffinfo that ships with prman 19 shows the following > >> (I'm not sure what version of libtiff prman is using, but the message > >> makes it look like it's 3.x): > >> > >> prman/bin/tiffinfo oiio-1.5.16.tx > /dev/null > >> TIFFReadDirectory: Warning, oiio-1.5.16.tx: wrong data type 13 for > >> "EXIFIFDOffset"; tag ignored. > >> > >> ...which is the base problem here - renders are spitting out the above > >> warning for all texture reads. > >> > >> tiffdump shows the two tx files are largely the same, except the 1.5.16 tx > >> has an extra TIFFTAG_EXIFIFD tag at the end of the 0th directory. The > >> biggest relevant source diff I can see between the two oiio versions is > >> TIFFOutput::write_exif_data. I'm half wondering if the > >> TIFFSetDirectory/TIFFSetField calls at the bottom of that method are > >> failing in some way, but this is literally the second time I've ever > >> looked at the tiff format and source, so it's a shot in the dark :). > >> > >> I have the above three image files I can mail over if that would be > >> helpful (checker.exr, oiio-1.4.8.tx, and oiio-1.5.16.tx). > >> > >> John > >> > >> _______________________________________________ > >> Oiio-dev mailing list > >> [email protected] <mailto:[email protected]> > >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > >> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> > > > > -- > > Larry Gritz > > [email protected] <mailto:[email protected]> > > > > > > _______________________________________________ > > Oiio-dev mailing list > > [email protected] <mailto:[email protected]> > > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> > > -- > Larry Gritz > [email protected] <mailto:[email protected]> > > > _______________________________________________ > Oiio-dev mailing list > [email protected] <mailto:[email protected]> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> > > _______________________________________________ > 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
