desktop-packages team mailing list archive

[Misaki <1436595@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Most images have their values shifted upwards when displayed in eog, and
I don't think it is intentional. Reporting this as a bug is complicated
because I am not sure if some programs, such as eog, change their
display of an image based on screen settings for colorspace or gamma. I
am not an expert on graphics, but something does seem to be wrong.

So at least for my computer, eog seems to stretch out the range just
above a 0 value. A very dark area will have a clear contrast between the
totally black pixels, with a value of zero, and the ones just above it.
In one image I tested, eog did not display any pixels with a value in
the range of 1 to 5, as in the histogram of a screenshot of eog's
display of the image.

In comparison, a screenshot of Firefox's display of the same image had
numerous pixels in the 1~5 range. The GIMP image editor displayed this
image the same as Firefox, with the histogram showing that the pixels
were being displayed without any adjustment.

Basically, if a lot of different programs display things differently and
inconsistently, some of them have to be wrong, and it seems likely that
eog is. Due to inconsistencies, I'm not actually sure what is the
correct, or the best way to display images, which might be different
from the correct way.

Programs used to test, convert, and display images:
imagemagick
ffmpeg (for conversion) and avplay (for display, since ffplay isn't provided on my distribution)
eog
Firefox
vlc
GIMP

I thought Firefox was displaying non-stripped pngs the same as eog does,
but it's actually slightly different. While gray areas are about the
same as eog, red areas are slightly darker in Firefox.

A description of how various programs display images:
vlc seems to be the same as avplay, and both are different from either Firefox or eog. Dark red is a bit more like brown or orange, while contrast for luminosity or luminance (?) seems to be higher; I am just noting that it is different. This is for a png image.

I thought eog was displaying all images the same way, until I
encountered a png that worked differently. I thought eog was displaying
this png without any adjustments, as it's slightly darker than how eog
displays other pngs, but it's actually slightly darker with more intense
colours than how other programs display the same image. But for all
other images, eog seems to make them slightly brighter.

Firefox displays jpgs without any adjustment, but most pngs are slightly
brighter. As described, this is slightly different than how eog makes
images brighter. If an image is converted with -strip action in
imagemagick, Firefox shows the png without adjustments. A png output
from ffmpeg is also displayed without adjustments. It seems to be
related to the 'png:sRGB : intent=<value>' property but that would be a
Firefox bug. It's relevant because it seems to adjust the display of
images in a way that's similar to eog, though still different. If a
stripped png is converted again without applying the -strip action
again, Firefox will display it as adjusted; that is, brighter. This is
also part of the evidence that the adjustment in Firefox, and therefore
in eog, is a bug.

GIMP displays images without an adjustment, so darker than eog for most
images.

The 'display' utility from imagemagick displays images the same as GIMP,
without any apparent adjustments.


So GIMP, display from imagemagick, and Firefox all display jpgs as slightly darker than eog, without mostly skipping over the range of values just above 0. GIMP and 'display' show most pngs as darker than eog, while Firefox displays some pngs as darker than eog while others are displayed similar but with slightly darker reds it seems.

I think all the images I've looked at had 'colorspace: sRGB' in their
properties when I looked at them with 'identify' from imagemagick or
exiftool., so if that's somehow related it doesn't seem like programs
should display images differently. They probably all had 'gamma: 0.45'
in 'identify' (though this shows up as gamma: 2.2 in exiftool I think),
so I don't think that should affect image display either.

For the unusual png that eog displays differently, none of the ways I
used to convert it caused the output to be displayed in eog the same as
the original. These methods included 'convert' from imagemagick with and
without the -strip action; convert with jpg output; ffmpeg with png
output; and GIMP exporting as png with background color and gamma tested
(so four GIMP outputs total). The reason for testing background color
was that 'png:bKGD' is part of the output from 'identify' when the
-strip action isn't used with 'convert', and non-stripped pngs are
treated differently in Firefox so they could potentially also be treated
differently in eog, but as it turned out they weren't treated
differently in eog.

In 'identify's output, the original png does have very slightly
different numbers under Chromaticity, with five of eight numbers
different by 0.0001. I don't know if that's supposed to affect display
of the image at all. Under the 'Properties' subsection, either the
stripped or the nonstripped version are similar to the original image.
The output of 'identify' for the 'png:sRGB intent=<value>' property
changes each time 'identify' is run on the same file, but both the
original and the stripped version (which is displayed normally in
Firefox, unlike non-stripped) have a value of around 'intent=32500±300'.
For the stripped png, 'intent=0' but the other values under the
Properties subsection are the same as the original other than adding a
'png:bKGD' field which the stripped version doesn't do.

In exiftool, the non-stripped png from 'convert' has the fields 'Gamma :
2.2' and 'SRGB Rendering : Perceptual', but neither the original nor the
stripped version have these fields. It's possible that somehow, if some
fields exist eog assumes certain values for other fields, but the reason
this particular png is displayed differently in eog than other pngs is a
mystery.

As a note, comparing the way different programs display images is easier
using the zoom function in Compiz, as well as the window transparency
function to line up images.

Most images being displayed lighter in eog than in many other programs
might not be a bug; I am filing this bug report because it appears to be
one. Maybe I should have tried asking under Questions but I doubt anyone
except the package maintainers could provide a correct answer, due to
inconsistency between different programs.

I am using Ubuntu 14.10, with eog (GNOME image viewer) version 3.12.2.

** Affects: eog (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to eog in Ubuntu.
https://bugs.launchpad.net/bugs/1436595

Title:
  Images too bright

Status in eog package in Ubuntu:
  New

Bug description:
  Most images have their values shifted upwards when displayed in eog,
  and I don't think it is intentional. Reporting this as a bug is
  complicated because I am not sure if some programs, such as eog,
  change their display of an image based on screen settings for
  colorspace or gamma. I am not an expert on graphics, but something
  does seem to be wrong.

  So at least for my computer, eog seems to stretch out the range just
  above a 0 value. A very dark area will have a clear contrast between
  the totally black pixels, with a value of zero, and the ones just
  above it. In one image I tested, eog did not display any pixels with a
  value in the range of 1 to 5, as in the histogram of a screenshot of
  eog's display of the image.

  In comparison, a screenshot of Firefox's display of the same image had
  numerous pixels in the 1~5 range. The GIMP image editor displayed this
  image the same as Firefox, with the histogram showing that the pixels
  were being displayed without any adjustment.

  Basically, if a lot of different programs display things differently
  and inconsistently, some of them have to be wrong, and it seems likely
  that eog is. Due to inconsistencies, I'm not actually sure what is the
  correct, or the best way to display images, which might be different
  from the correct way.

  Programs used to test, convert, and display images:
  imagemagick
  ffmpeg (for conversion) and avplay (for display, since ffplay isn't provided on my distribution)
  eog
  Firefox
  vlc
  GIMP

  I thought Firefox was displaying non-stripped pngs the same as eog
  does, but it's actually slightly different. While gray areas are about
  the same as eog, red areas are slightly darker in Firefox.

  A description of how various programs display images:
  vlc seems to be the same as avplay, and both are different from either Firefox or eog. Dark red is a bit more like brown or orange, while contrast for luminosity or luminance (?) seems to be higher; I am just noting that it is different. This is for a png image.

  I thought eog was displaying all images the same way, until I
  encountered a png that worked differently. I thought eog was
  displaying this png without any adjustments, as it's slightly darker
  than how eog displays other pngs, but it's actually slightly darker
  with more intense colours than how other programs display the same
  image. But for all other images, eog seems to make them slightly
  brighter.

  Firefox displays jpgs without any adjustment, but most pngs are
  slightly brighter. As described, this is slightly different than how
  eog makes images brighter. If an image is converted with -strip action
  in imagemagick, Firefox shows the png without adjustments. A png
  output from ffmpeg is also displayed without adjustments. It seems to
  be related to the 'png:sRGB : intent=<value>' property but that would
  be a Firefox bug. It's relevant because it seems to adjust the display
  of images in a way that's similar to eog, though still different. If a
  stripped png is converted again without applying the -strip action
  again, Firefox will display it as adjusted; that is, brighter. This is
  also part of the evidence that the adjustment in Firefox, and
  therefore in eog, is a bug.

  GIMP displays images without an adjustment, so darker than eog for
  most images.

  The 'display' utility from imagemagick displays images the same as
  GIMP, without any apparent adjustments.

  
  So GIMP, display from imagemagick, and Firefox all display jpgs as slightly darker than eog, without mostly skipping over the range of values just above 0. GIMP and 'display' show most pngs as darker than eog, while Firefox displays some pngs as darker than eog while others are displayed similar but with slightly darker reds it seems.

  I think all the images I've looked at had 'colorspace: sRGB' in their
  properties when I looked at them with 'identify' from imagemagick or
  exiftool., so if that's somehow related it doesn't seem like programs
  should display images differently. They probably all had 'gamma: 0.45'
  in 'identify' (though this shows up as gamma: 2.2 in exiftool I
  think), so I don't think that should affect image display either.

  For the unusual png that eog displays differently, none of the ways I
  used to convert it caused the output to be displayed in eog the same
  as the original. These methods included 'convert' from imagemagick
  with and without the -strip action; convert with jpg output; ffmpeg
  with png output; and GIMP exporting as png with background color and
  gamma tested (so four GIMP outputs total). The reason for testing
  background color was that 'png:bKGD' is part of the output from
  'identify' when the -strip action isn't used with 'convert', and non-
  stripped pngs are treated differently in Firefox so they could
  potentially also be treated differently in eog, but as it turned out
  they weren't treated differently in eog.

  In 'identify's output, the original png does have very slightly
  different numbers under Chromaticity, with five of eight numbers
  different by 0.0001. I don't know if that's supposed to affect display
  of the image at all. Under the 'Properties' subsection, either the
  stripped or the nonstripped version are similar to the original image.
  The output of 'identify' for the 'png:sRGB intent=<value>' property
  changes each time 'identify' is run on the same file, but both the
  original and the stripped version (which is displayed normally in
  Firefox, unlike non-stripped) have a value of around
  'intent=32500±300'. For the stripped png, 'intent=0' but the other
  values under the Properties subsection are the same as the original
  other than adding a 'png:bKGD' field which the stripped version
  doesn't do.

  In exiftool, the non-stripped png from 'convert' has the fields 'Gamma
  : 2.2' and 'SRGB Rendering : Perceptual', but neither the original nor
  the stripped version have these fields. It's possible that somehow, if
  some fields exist eog assumes certain values for other fields, but the
  reason this particular png is displayed differently in eog than other
  pngs is a mystery.

  As a note, comparing the way different programs display images is
  easier using the zoom function in Compiz, as well as the window
  transparency function to line up images.

  Most images being displayed lighter in eog than in many other programs
  might not be a bug; I am filing this bug report because it appears to
  be one. Maybe I should have tried asking under Questions but I doubt
  anyone except the package maintainers could provide a correct answer,
  due to inconsistency between different programs.

  I am using Ubuntu 14.10, with eog (GNOME image viewer) version 3.12.2.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions