Great, thanks! I'll try the build out early next week at work to make sure prman is happy there...
(sent from mobile. sry for grmmar) > On Jul 17, 2015, at 3:02 PM, Larry Gritz <[email protected]> wrote: > > 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]> wrote: >>> This pull request I think allows you to fix this: >>> 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]> 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]> >>> >> 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] >>> >> 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 >>> >>> -- >>> Larry Gritz >>> [email protected] >>> >>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] >>> 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
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
