Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

GM returns 0 when failing on corrupted image

Help
2012-11-26
2013-03-27
  • Hi all,

    I've just upgraded GM to 1.3.16 and one of my tests is now failing.
    It seems that GM returns 0 though it fails processing a corrupted image.

    ci@factory-server-01:~$ gm convert corrupted.jpg -rotate '90.0' -quality '90.0' out.jpg
    gm convert: Unsupported marker type 0xb5 (corrupted.jpg).
    ci@factory-server-01:~$ echo $?
    0
    

    With the previous version (1.3.12), it returns an error code (1).

    ci@factory-server-01:~/gm-1.3.12-q8/bin$ ./gm convert ~/corrupted.jpg -rotate '90.0' -quality '90.0' ~/out.jpg
    ./gm convert: Unsupported marker type 0xb5 (/home/ci/corrupted.jpg).
    ci@factory-server-01:~/gm-1.3.12-q8/bin$ echo $?
    1
    

    Are you aware of this?

     
  • Same behaviour with GM 1.3.17

    ci@factory-server-01:~/gm-1.3.17/bin$ ./gm convert ~/corrupted.jpg -rotate '90.0' -quality '90.0' ~/out.jpg
    ./gm convert: Unsupported marker type 0xb5 (/home/ci/corrupted.jpg).
    ci@factory-server-01:~/gm-1.3.17/bin$ echo $?
    0
    ci@factory-server-01:~/gm-1.3.17/bin$ ./gm -version | head -n1
    GraphicsMagick 1.3.17 2012-10-13 Q16 http://www.GraphicsMagick.org/
    

    To help you reproduce the problem, the corrupted image can be found here : http://depositfiles.com/files/nr13jo0mr

     
  • It would be helpful if you would open a formal GraphicsMagick bug report and attach your file to it.

    Did you check to see if 'out.jpg' was written and if it includes useful image content?  It may be that the message is a warning rather than error.

     
  • The purpose of your download service is to force the person doing the download to view porn sites while they are trying to download the file. Please open a bug report and upload the problem file to SourceForge so I don't have to be subjected to this.

     
  • @Bob, Thanks for the heads up.  If I had happened access that from work, no more job for me.

     
  • I did happen to access it from work.  Luckily no one was watching.  It is amazing what they can do with pop-up windows.  Thank goodness there was no audio.

     
  • Sorry for the upload site, it seems it's more convenient to upload than download files there…

    I've just raised this bug: https://sourceforge.net/tracker/?func=detail&aid=3590310&group_id=73485&atid=537937

    But I could not upload the corrupted file, I got "Uploaded file must be no larger than 256k.".
    Mine is 1.2MB and I think it's better not to alter it.
    Do you know where I could upload this file?

     
  • I've just done a new test and tried to rotate one more time the output file. This time, I got no error.

    ci@factory-server-01:~$ gm convert corrupted.jpg -rotate '90.0' -quality '90.0' out.jpg
    gm convert: Unsupported marker type 0xb5 (corrupted.jpg).
    ci@factory-server-01:~$ gm convert out.jpg -rotate '90.0' -quality '90.0' out2.jpg
    ci@factory-server-01:~$
    

    It may be that the message is a warning rather than error.

    I think you're right.
    The next question is how GM should behave in this case? Should it gracefully perform the operation and indicate that it succeeds (despite the error line in the console), or should it abort the operation (no output file) and explicitely fail (return code != 0)?

     
  • Looking at the change history, I see that this new behavior is intentional.  See http://www.graphicsmagick.org/NEWS.html#december-24-2011.  There are a number of JPEG error handling fixes including "JPEG reader now treats an unhandled EXP marker as a warning rather than a hard error."  A bug report had been filed because GraphicsMagick was failing to read some valid JPEG files.

     
  • If you really think that I should look at your file (already knowing that a change was made to allow GM to finish reading the file), you can send it to my email address bfriesen AT simple.dallas.tx.us.

    The output file is likely smaller because the compression options are different.  Try adding

    -define jpeg:preserve-settings
    

    and see if that helps. This option causes the original compression settings to be estimated and re-applied if the nature of the image has not changed.

     
  • OK
    But in this case, the jpeg files are corrupted, so an error would be legitimate.

    I've made several tests by randomly truncating jpeg files. GM displays various error messages, but always returns 0.
    The only way I got a failure from it is to truncate the beginning of the jpeg file.

    ci@factory-server-01:~$ gm convert test.jpg -rotate '90.0' -quality '90.0' out.jpg
    gm convert: Not a JPEG file: starts with 0x94 0xa4 (test.jpg).
    ci@factory-server-01:~$ echo $?
    1
    

    Console outputs can be useful, but the return code is the only way to know if a command went fine. We use im4java (a Java wrapper for GM/IM) and I know that it only relies on the return code to throw exception or not.
    In our case, catching image processing errors is more important than be able to process corrupted images.

    In my opinion, GM should process the operation if it can, but it should return a non zero code if something bad happened.

    Maybe a new option could set how GM behaves in this case?

     
  • Returning zero for a truncated JPEG is bad, particularly if a warning/error message was reported.  Can you attach a problematic truncated JPEG to a bug report?  This may be worthy of a different bug report since truncation is a different issue than skipping over an unsupported chunk in the JPEG.

     
  • Ok, I've attached a little and corrupted file to the bug ticket.

    But corrupting jpeg is quite easy. Open a jpeg file in a text editor, and put a child / monkey in front of it :)

     
  • As mentioned in the bug report, I think that GM is doing the "right thing" in that it reports libjpeg reported warnings as warnings, and errors as errors.  Only errors cause non-zero to be returned to the environment.  We could add a new option to cause warnings to be reported as errors.

     
  • Hi,

    I've seen that the bug ticket has been closed as "won't fix".
    Does this mean that the current behaviour will still apply?

    > "It is decided that GM will report an error if libjpeg reports an error, and just a warning if libjpeg reports a warning"

    How can we catch these errors and warnings, from command line usage?
    What will be the return code in case of warning or error?

     
  • If libjpeg reports an error, then GM will abort the read and return 1.  If libjpeg reports a warning, then the image file will be read (as best possible), and 0 is returned to the environment.  The JPEG library reports a wide variety of warnings and it is not feasible for GM to guess which ones are benign or result in a corrupted image, particularly since it does not know what the JPEG library is doing when the warning is produced.

    I don't want to block anyone from reading from their precious image collection full of family memories, but written by a JPEG writer which causes IJG JPEG to complain.

    It is true that GM's JPEG warning/error handling code has been improved during the 1.3.X cycle.

    This decision was reached after discussion with Glenn Randers-Pehrson, who has assisted with maintaining the GM JPEG code and is also the maintainer of libpng for many years.

     
  • > "I don't want to block anyone from reading from their precious image collection full of family memories, but written by a JPEG writer which causes IJG JPEG to complain. "

    That's a reasonable point, but on the other side, we currently have no way to catch these corruptions, if we don't want this lax policy.
    This is why an option to define how GM should behave in this case could have been a good solution, for all parts.