The problem with the NEF files crashing tiffinfo is the result of a field in the header with an incorrect data type, according to libtiff. Once tiff 3.8.2-10 makes it into the archive, you can run tiffinfo on the NEF file with output directed to /dev/null to see the warnings.
The problem is that libtiff's recovery code was incorrect, causing it to try to access fields that were not properly initialized. The bug manifested itself differently in 3.8.2 and the beta of 4.0.0. In both cases, a trivial fix was sufficient. I reported the problem against 3.8.2 here: http://bugzilla.maptools.org/show_bug.cgi?id=1896 and the problem against 4.0.0 (current CVS) here: http://bugzilla.maptools.org/show_bug.cgi?id=1895 I'm not going to mark this bug "forwarded" because I'm including the patch in the debian version and preparing a new upload. I expect that this will be fixed upstream since the problem is fairly simple and obvious once you actually look at the code in question. I will remove the test image from my system once I've gotten acknowledgment. I actually never looked at the image data. :-) --Jay -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
