After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 618096 - Corrupt JPEG shows as black
Corrupt JPEG shows as black
Status: RESOLVED FIXED
Product: gdk-pixbuf
Classification: Platform
Component: loaders
git master
Other Linux
: Normal normal
: ---
Assigned To: gdk-pixbuf-maint
gdk-pixbuf-maint
Depends on:
Blocks:
 
 
Reported: 2010-05-08 10:29 UTC by adys.wh
Modified: 2014-11-03 18:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Truncated jpeg file (8.51 KB, image/jpeg)
2010-05-08 10:29 UTC, adys.wh
  Details
noexif_CMYK_conversion.patch (1.31 KB, patch)
2014-10-28 16:35 UTC, Matthieu Gautier
committed Details | Review
Image as loaded in Photoshop 2014.2.1 (86.51 KB, image/png)
2014-11-03 11:19 UTC, Mukund Sivaraman
  Details

Description adys.wh 2010-05-08 10:29:30 UTC
Created attachment 160559 [details]
Truncated jpeg file

The attached jpeg is corrupt (premature end) and shows black in eog, however the GIMP opens it fine.
Comment 1 Felix Riemann 2010-05-09 20:29:45 UTC
This is what we can get from GdkPixbuf after ignoring the error condition because of the broken image file.

So, fixing this is likely requiring changes there. Reassigning.
Comment 2 Bastien Nocera 2014-10-22 14:05:23 UTC
Confirmed with gdk-pixbuf 2.31.
Comment 3 Bastien Nocera 2014-10-27 20:19:44 UTC
Mathieu Gautier found that this file is an "Adobe CMYK" file, but isn't detected as such because there's no EXIF data in the file. GIMP defaults to files being Adobe CMYK.
Comment 4 Matthieu Gautier 2014-10-28 16:33:57 UTC
Here is my patch.

However, I'm not sure we should apply it:

Technically the file is loaded. It appears blacks cause of the wrong conversion to RGB made.

This patch remove a test to always use inverted CMYK.
So normal CMYK (so without exif flag) will be loaded has inverted.

Not sure it worth it if it is only to load a corrupted file.
Comment 5 Matthieu Gautier 2014-10-28 16:35:11 UTC
Created attachment 289534 [details] [review]
noexif_CMYK_conversion.patch
Comment 6 Bastien Nocera 2014-10-31 16:19:24 UTC
Mitch, Mukund, can you help?
Comment 7 Mukund Sivaraman 2014-10-31 22:48:44 UTC
This file seems to contain inverted CMYK values, but it contains no Adobe APP14 marker (X'FFEE') to indicate this. It contains an APP0 marker (that usually is not present when APP14 is present).

Beginning with some old version of PhotoShop, it started saving JPEG files with inverted CMYK values. To indicate that this was the case, it also added the APP14 marker so that applications which loaded such images can invert it.

In JPEGs embedded in EPS output too, PhotoShop used inverted CMYK values, but included a transform in the EPS using an image operator that inverted the values. This image operator was added so that no changes were necessary then in PostScript renderers. This is also why libjpeg doesn't automatically invert values for you.

For standalone JPEG files, if some app is going to put inverted CMYK values into it, it should add an appropriate APP14 marker (such as what PhotoShop does).

I'd say the image in the bug report is erroneous. (I use "I'd say" as opinion, as these things are not well documented.)

I suggest you close this ticket. What gdk-pixbuf does here is better than GIMP as it looks for the marker instead of assuming inverted values always.

It seems the image in this bug report was created by an "Intel JPEG Library". It's best the reporter asks them how to use it correctly.
Comment 8 adys.wh 2014-10-31 23:01:07 UTC
FWIW, chrome opens the image just fine as well. Any idea why?
Comment 9 Mukund Sivaraman 2014-11-03 11:19:29 UTC
Created attachment 289887 [details]
Image as loaded in Photoshop 2014.2.1

It seems PhotoShop now always assumes inverted CMYK values.

So please go ahead and apply the patch in comment #5, along with a comment there saying that such an assumption is now made.
Comment 10 Mukund Sivaraman 2014-11-03 11:28:17 UTC
(In reply to comment #8)
> FWIW, chrome opens the image just fine as well. Any idea why?

Web browsers are among the worst at implementing image file formats, so we should not usually use them as a reference, esp. when a standard or some historic context is available.

You seem to be keen on getting this file loaded properly in gdk-pixbuf. I assume then that you either created the file, or can contact the persons who created this file.

(1) I suggest adding the APP14 marker. Even older versions of gdk-pixbuf will handle it correctly then. It just adds a few bytes to the file size. libjpeg even has code to automatically insert this marker, but it seems you are using the "Intel JPEG Library", so perhaps you can find something to do it in its documentation.

(2) The file appears truncated. This in itself is not a problem in JPEG streams, but be aware that the file you have attached is truncated.
Comment 11 Mukund Sivaraman 2014-11-03 11:33:23 UTC
(In reply to comment #10)
> (2) The file appears truncated. This in itself is not a problem in JPEG
> streams, but be aware that the file you have attached is truncated.

Sorry, I just re-read the description and saw that you are aware of it. :)
Comment 12 Bastien Nocera 2014-11-03 18:50:50 UTC
commit 17cc1a484dd845ec5ec6d52172460deb72f5f086
Author: Bastien Nocera <hadess@hadess.net>
Date:   Mon Nov 3 19:24:28 2014 +0100

    tests: Add a test for inverted CMYK JPEG files
    
    https://bugzilla.gnome.org/show_bug.cgi?id=618096

commit a845d3d6dbd30f42e9bfae840d98faf3c6b0aaec
Author: Bastien Nocera <hadess@hadess.net>
Date:   Mon Nov 3 19:30:42 2014 +0100

    tests: Add error reporting to pixdata_equal()

commit 9d13f7887e5000ffb70e29fe9548d201dfb5eb2c
Author: Bastien Nocera <hadess@hadess.net>
Date:   Mon Nov 3 19:04:23 2014 +0100

    tests: Move pixdata_equal() to helpers

commit f91f7bd7bbb9e3543d72b79b860c3976b652ecb0
Author: Matthieu Gautier <dev@mgautier.fr>
Date:   Tue Oct 28 16:35:00 2014 +0000

    jpeg: Assume that CMYK JPEGs are inverted CMYK
    
    Photoshop seems to assume that CMYK JPEGs are in inverted CMYK format.
    We now do the same. Hopefully it won't cause problems as most CMYK files
    around are probably produced by that program.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=618096
Comment 13 Bastien Nocera 2014-11-03 18:51:32 UTC
Mukund, Matthieu, thanks a lot for the expertise and patch, respectively :)