GNOME Bugzilla – Bug 131975
Tiff multipage w/multiple warning msg.
Last modified: 2004-01-31 22:54:01 UTC
When I open a tiff w/multiple pages, it opens fine. However, I get the following warning messages: First, I get the following errors. tif: Unknown field with tag 33949 (0x849d) encountered And these two errors repeat for the number of pages in the tif. tif: Unknown field with tag 33950 (0x849e) encountered tif: Unknown field with tag 33951 (0x849f) encountered Here is a sample tiff image w/3 pages that demonstrates the warning messages I'm getting. http://epierce.freeshell.org/bugzilla/multipage.tif Let me know if I can provide any other info. Eric Pierce
From the TIFF Revision 6.0 spec: "An organization might wish to store information meaningful to only that organi- zation in a TIFF file. Tags numbered 32768 or higher, sometimes called private tags, are reserved for that purpose." The message comes from the libtiff library, so there's not much we can do here.
We could try to improve the error message. When libtiff gives this warning, do we have a chance to find out if it's about a private tag?
Well, libtiff defines TIFFSetWarningHandler() and TIFFSetErrorHandler() that are used by the GIMP tiff plug-in to intercept the libtiff warnings and errors and handle them using the private functions tiff_warning() and tiff_error(). Currently, both of these functions are simply passing the messages to g_logv(). We could do some simple pattern matching and intercept all messages containing "Unknown field with tag". Since these functions in the plug-in get all parameters (varags-style), we could even check if the tag number is greater than 32768. If you think that it would be an appropriate solution, then I could work on it and propose a patch tomorrow.
Perhaps it would be sufficient to differentiate the importance of the messages generated from libtiff. Messages coming from the libtiff warning handler could have a note about being harmless or purely informative. At some point we need to improve how messages from plug-ins are handled. I'd suggest we implement a scheme similar to the g_log mechanism in glib. Plug-ins can then tell GIMP about the severity level of their messages. GIMP can then display different dialogs for messages, warnings and errors and the user could choose to suppress messages below a certain level.
Yes, but note that the libtiff API does not include a severity level. This means that the tiff plug-in would have to do some pattern matching on the messages, then assign severity levels before passing them to the GIMP. This should not be too hard to do. So, should we set the milestone to Future and wait until we have a new API for passing messages, or should we try to fix only the problem reported here by just skipping the messages about unknown tags?
You said there are two levels of severity supported by libtiff (warning and error, via TIFFSetWarningHandler and TIFFSetErrorHandler) - this is good enough for our purposes. Cheers, Dave.
Well, this could be good if we wanted to limit ourselves to 2 levels, but I think that Sven's comment implied that we would have more than 2 levels (i.e., at least have a 3rd level that would be for informational messages). The problem with libtiff's warning messages is that some of them are more serious than others. For example, looking only in tif_dirread.c, there is the warning "unknown field with tag %d (0x%x) ignored", which should be ignored or considered as a simple informational message if a private tag (< 32768) is found, but should probably be reported as a real warning if this occurs with a standard tag. Also, the same file contains warnings such as: "TIFF directory is missing required \"%s\" field, calculating from imagelength" (where %s would be StripByteCounts). Still in that file: "wrong data type %d for \"%s\"; tag ignored". Some other files in libtiffs have warnings that indicate that some scanlines could be discarded. These sound like real warnings to me, because they could lead to data corruption if there is really something wrong in the file. That's why I think that we need more severity levels than "warning" and "error". We also need something less severe that can be ignored by the user.
Absolutely right. But for the moment we don't have this infrastructure. I was hoping we could get away with dropping tiff warnings and displaying tiff errors only.
I will work on bug #131975 and bug #132297. As a workaround for 2.0, I will modify the tiff_warning() function in the plug-in so that it ignores a few messages from libtiff (unknown tag for tags > 32768, and random access not supported). A better solution for a future release (2.2 or later) should allow the user to select which messages should be ignored, but this will require an improved infrastructure for passing messages from plug-ins and allowing multiple severity levels.
I think it is better to replace the annoying message boxes with the single scrollable window which will accumulate all the errors and warnings. Some TIFFs may be awfully broken and libtiff will complain on every scanline. It is not a usual case for the most users, though, but very frequent case for me. I can fill the separate entry with this feature request for one of the future GIMP versions, if you agree with my suggestion.
I have fixed the problem described here by skipping the warning message from libtiff if the tag is >= 32768. I have also submitted a new enhancement proposal for allowing the user to customize which message should be shown or hidden. See bug #133093. If you would think that it would be interesting to have all messages in the same dialog with a scrollbar, please submit a new enhancement proposal. 2004-01-31 Raphaël Quinet <quinet@gamers.org> * plug-ins/common/tiff.c (tiff_warning, tiff_error): Do not display the warning message about unknown tags for unregistered private tags (>= 32768). Fixes bug #131975. Do not display the error message about random access not supported for images using JPEG compression. Fixes bug #132297. It would be better to allow the user to customize which messages should be displayed or not, but this can be done in a future release.