GNOME Bugzilla – Bug 792770
JPEG image renders black on-screen
Last modified: 2018-02-25 12:24:08 UTC
eog-3.26.2-1.fc27.x86_64 Summary: Some JPEGs display black or mostly black, in eog, but display correctly in Firefox and GIMP. The example JPEGs that exhibit this problem all come from a DSC-RX100M3. Detail: The DSC-RX100M3 creates two kinds of JPEGs: standalone, and an embedded preview in a Raw file. The problem JPEGs are the latter. Standlone JPEGs appear to render OK in eog, but the extracted thumbnail/preview renders all or mostly black. Attached Screenshot from 2018-01-21 19-46-18.png shows the JPEG opened in GIMP and eog simultaneously. The original image _DSC7988.JPG as extracted from the Raw can be provided unmodified upon request. It's 1MB. I'm attaching DSC7988-2ca.jpg which has been modified in GIMP (curves to add contrast, and slightly increase saturation) and then saved with slightly more compression than the original, reducing the file size. Yet it exhibits the same problem as the original. The attached image includes tags showing author "Chris Murphy" and licensing (CC BY 4.0) per https://creativecommons.org/licenses/by/4.0/ and applies to the original and all derivatives. I stipulate I'm the sole author of this work, and the entire frame shows objects that are not newer than 2nd century CE.
Created attachment 367192 [details] screenshot showing problem ego displays black (or nearly so) where GIMP is displaying the image as expected.
Created attachment 367193 [details] sample JPEG image exhibiting problem Just to make it clear with the specific entry for uploading this image: The attached image includes tags showing author "Chris Murphy" and licensing (CC BY 4.0) per https://creativecommons.org/licenses/by/4.0/ and applies to the original and all derivatives. I stipulate I'm the sole author of this work, and the entire frame shows objects that are not newer than 2nd century CE.
It looks like eog tries to build a simple color profile based on the whitepoint and gamma information in the Exif data. Stripping off the Exif information makes the image show correctly. I wonder why pretty much all is mapped to black (or something very close to it).
The Exif white point and chromatiticies in the sample JPEG match up exactly with Adobe RGB (1998) white point and primaries. I can't parse the Gamma tag value of 213286004/0 reported by (lib)exif utility, but anything between 1.8 and 2.4 is sane even though the spec for Adobe RGB is defined by a gamma 2.2 function. Strictly speaking, stripping away Exif defining the encoding as Adobe RGB, likely in favor of an sRGB rendering or display RGB (uncorrected), means the image isn't shown correctly (it'll be washed out). Certainly it's more correct than pretty much all black though. I'm virtually certain Firefox and GIMP ignore Exif color space information, and just push the decoded RGB to the display stack uncorrected.
Well, GIMP actually assumes sRGB in this case: https://github.com/GNOME/gimp/blob/13dcd876e593f4ed5e89a44956cc9802a12f485d/libgimp/gimpimagemetadata.c#L180 I don't what Firefox does here. This is the main reason I disabled that code for now, since I doubt the generated profiles are actually helping if the editing apps don't update/respect them anyway. We now assume sRGB as well in that case. Also, if we were to switch to Exiv2 for metadata parsing we'd have a problem as the gamma Exif tag is not exported there. commit 9eceea6e8f21bdeb731a799e14d6ac562057ae18 Author: Felix Riemann <> Date: Sat Feb 3 14:36:22 2018 +0100 EogMetadataReaderJpg: Disable color profile generation from Exif tags The code's currently not really error safe (divides-by-zero) and image editing apps like GIMP don't seem to take these tags into account either and just assume sRGB in that case. So, it's currently doubtful if these generated color profile are actually helping. https://bugzilla.gnome.org/show_bug.cgi?id=792770 --- This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.
*** Bug 793800 has been marked as a duplicate of this bug. ***