Thread: [GM-help] identify doesn't detect truncated gif file (GIMP does)
Swiss army knife of image processing
Brought to you by:
bfriesen
From: Alan J. <ala...@gm...> - 2012-07-09 21:09:54
Attachments:
icn_enlarge.gif
i.gif
|
Hi Ubuntu 12.04 seems to have switched me to GraphicsMagick. I had a nice script to scan for corrupt images, but it's stopped working now it's calling gm's "identify" instead of the ImageMagick version. Like ImageMagick, the manpage claims that "identify" will "report if an image is incomplete or corrupt". Like ImageMagick, the manpage is... well, I'd call it a documentation bug :). $ ls -l icn_enlarge.gif -r-------- 1 alan alan 200 Jul 9 21:41 icn_enlarge.gif $ dd bs=1 count=199 if=icn_enlarge.gif of=i.gif 199+0 records in 199+0 records out 199 bytes (199 B) copied, 0.00120877 s, 165 kB/s $ gm identify i.gif i.gif GIF 17x17+0+0 PseudoClass 32c 8-bit 199 0.000u 0:01 GIMP loads the image, but briefly shows an error in the status bar "EOF/read error on image data." When I posted a similar problem on the ImageMagick forums, <http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=20045, the answer was that I needed to use "-regardwarnings" to get errors reflected in the exit code, and "-verbose" to trick ImageMagick to decode all the image data. (Hence my disillusionment with the broad-brush statement in the manpage). But GraphicsMagick doesn't support -regardwarnings, so my script doesn't work any more. For GraphicsMagick, the manpage suggests that "+ping" might help, but it still doesn't recognise the gif file as being truncated. Is this a bug? Is there some other option I need, in order to request the desired behaviour? Alan |
From: Bob F. <bfr...@si...> - 2012-07-09 22:50:23
|
On Mon, 9 Jul 2012, Alan Jenkins wrote: > > For GraphicsMagick, the manpage suggests that "+ping" might help, but it > still doesn't recognise the gif file as being truncated. Is this a bug? Is > there some other option I need, in order to request the desired behaviour? Using 'gm identify +ping file.gif' is reasonable. You could also use gm convert file.gif null: Which reads the file and tosses the result. It does seem like there is a bug if the file is truncated but the software does not report that. What version of GraphicsMagick is Ubuntu providing? Use gm -version | head -1 to find that out. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: <gl...@co...> - 2012-07-09 23:02:01
|
----- Bob Friesenhahn <bfr...@si...> wrote: > What version of GraphicsMagick is Ubuntu providing? Use > > gm -version | head -1 > > to find that out. Also please type "which identify" or "type identify" to find out where it's installed. Ubuntu 12.04 seems to put ImageMagick's "identify" in /usr/bin, at least until very recently, so it seems curious to me that you are getting GM instead of IM. Glenn |
From: Bob F. <bfr...@si...> - 2012-07-10 01:44:22
|
On Mon, 9 Jul 2012, Alan Jenkins wrote: > Ubuntu 12.04 seems to have switched me to GraphicsMagick. I had a nice > script to scan for corrupt images, but it's stopped working now it's calling > gm's "identify" instead of the ImageMagick version. > > Like ImageMagick, the manpage claims that "identify" will "report if an image > is incomplete or corrupt". Like ImageMagick, the manpage is... well, I'd > call it a documentation bug :). This may be a case of "If a tree falls in the forest and no one is around to hear, does it make a noise?". It does not seem that the byte you trimmed is necessary to read the image and since it is never requested, there is no failure: % gm identify -format "%#" icn_enlarge.gif 8862d711c58f8f95e52d0d1847149aecb13525d998b75290a505d960cf680668 % gm identify -format "%#" i.gif 8862d711c58f8f95e52d0d1847149aecb13525d998b75290a505d960cf680668 Notice that the computed signatures are the same. Regardless, GraphicsMagick is not an image format validator. Many somewhat defective files may exist that people still want to be able to read. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Philip N. <phi...@gm...> - 2012-07-10 07:01:23
|
On Tue, Jul 10, 2012 at 12:50 AM, Bob Friesenhahn <bfr...@si...> wrote: > It does seem like there is a bug if the file is truncated but the > software does not report that. I don't know -- I would have expected an "identify" function to read only the file header, if the file format supports that sort of thing, which is typically near the beginning of the file; and if the header is complete, to return successfully. I wouldn't expect it to read the whole file and check the file length against the image data size in the header, or to compute checksums for chunks (if the file format supports that) and compare them against the data, and that sort of thing -- though a "verify" function which *does* do that could be useful, I wouldn't expect that as part of an "identify" function. Cheers, Philip -- Philip Newton <phi...@gm...> |
From: Bob F. <bfr...@si...> - 2012-07-10 13:28:44
|
On Tue, 10 Jul 2012, Philip Newton wrote: > On Tue, Jul 10, 2012 at 12:50 AM, Bob Friesenhahn > <bfr...@si...> wrote: >> It does seem like there is a bug if the file is truncated but the >> software does not report that. > > I don't know -- I would have expected an "identify" function to read > only the file header, if the file format supports that sort of thing, > which is typically near the beginning of the file; and if the header > is complete, to return successfully. Normally identify works in 'ping' mode which is expected to be as quick as possible. The +ping option was really added to assist with testing but is useful to force reading all the data as well. > I wouldn't expect it to read the whole file and check the file length > against the image data size in the header, or to compute checksums for > chunks (if the file format supports that) and compare them against the > data, and that sort of thing -- though a "verify" function which > *does* do that could be useful, I wouldn't expect that as part of an > "identify" function. Agreed. Being excessively pedantic might block reading many files. Regardless, I did study the code again last night and will be shoring up the error checking/handling a bit more. It still will only check what it is already accessing and still does not detect file trucation by a single byte. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |