Different image viewers, different color -- pulling my hair out

Processing
1

I’m on Kubuntu 18.10, with an Nvidia graphics card.

I finished work on a photo in GIMP, and exported to PNG. The resulting image looks different depending on the software I use to view it.

Gimp has no color management enabled, and the image itself is using no embedded/assigned profiles, etc. I exported to regular 8bpp PNG.

Having dealt with this kind of thing before, my first thought was that it was a color calibration thing: I use custom calibration profiles I generated for my monitors. But I don’t think that’s it: setting them all to default profiles, or playing with the gamma slider through the nvidia X server settings, whatever I do affects the monitors, of course, but the differences between the image viewers remains the same. So it seems like it isn’t caused by monitor profiles or nvidia driver issues (e.g. one program using a certain rendering pipeline vs another not, etc.) ?

Gimp and feh look the same, and what I’m considering/wanting to be “correct”.

Firefox shows the image as brighter, especially in the low ranges.

Geeqie and gwenview look the same as each other (bad): much brighter image, and with a noticeable color shift. Like, this isn’t subtle.

Here’s a screenshot of feh vs gwenview to illustrate. (Feh window is overlapping the gwenview window.) (Note: you can ignore the halo around the edge of the overlapping window border: that’s obviously just window manager decoration.)

What the heck is going on here? I read some years ago about Firefox using a slightly unusual but arguably good alternative sRGB profile… but this dramatic difference among apps is alarming. Are they all inventing their own gamma curves and profiles?

I feel like this is likely user error but I can’t figure out how! The whole reason I use monitor-based correction rather than per-program color management is to avoid this kind of thing, yet here I am again. :slight_smile:

Any help? Thanks in advance!

2

As far as I know, if you care about rendering colors correctly (or at least as best as possible), not using color management in your applications is a bad bad idea.

To my knowledge, if you feed an application with an image without any color profile embedded, then the application does whatever it feels like (what it was programmed to do in such cases).

A couple links if you’re interested about the oddities of color management (or lack of it):

Those are about browsers, but most probably the problem is the same with image applications

3

You need to calibrate your monitors and set your applications to use color management. I don’t think feh is color managed, and web browsers assume sRGB. In geeqie you need to enable color management. I don’t know of gwenview is color managed.

4

Thanks! But I have my system set up so that everything is going through the color profile, system-wide. I.e. no app is color managed, but the display itself has the profile applied at the monitor level (via dispwin), so all images are corrected for on the display. Meaning, it should be moot whether or not an individual app is color managed, because I’m not doing any correction at the app level (and it is disabled for all of these apps).

Further, the image itself has no profile associated or embedded, so it doesn’t seem like that’s a factor.

As a corroborating example, if I change the monitor profile using dispwin, the output of all of these viewers changes accordingly: they are all affected by that new profile, but the per-app differences remain. I conclude that the differences between them are happening before the monitor color correction, and that’s my concern and question.

(Unless these apps or dispwin are buggy, so they are adjusting their rendered image based on the monitor profile, and then the display system is erroneously applying the color shift a second time, or something crazy like that?)

5

@XavAL – yeah that’s basically my concern: that absent color management these apps are all making up their own approach, and that seems pretty crazy to me. I mean if one used perceptual and one used relative colorimetric or something subtle, that’s no big deal. But sRGB is a pretty standard thing (with minor tech differences aside) and to deviate as starkly as that demo image I linked to demonstrates is nuts to me.

I’ll try exporting with an embedded profile and see if it helps any… [edit: nope, no change. I also had “save gamma” unchecked for PNG export so I enabled that… no change.]

6

Apps need colour management as well as the system. Unfortunately, it isn’t as simple as setting it up in one place.

7

Hmmm… when I apply the color profile system-wide, it does indeed affect the apps’ display windows… I’m confused… are you saying that the pipeline/setup is broken in some other way?

I know that some desktop environments have “system profiles” that, once configured, are just there and available for use but depend on color-managed apps taking advantage of them. I’m not using that method.

Again, I’m using dispwin, which sets the profile at the video card level, and all the apps reflect that: they change with the profile.

Any clarification/correction is appreciated!

edit: said another way, I don’t think this is monitor profile related. When I disable all of it, the issue persists, as described above.

8

Think of it this way. In my room, there is a light switch. I turn on the light switch and nothing happens. I have to connect a lamp to a socket and switch the lamp on.

Less abstractly, if I want to print the image, I also have to make sure that the printer and paper are colour managed via soft proofing and the correct firmware and settings.

9

Another analogy: imagine that every app, display and os talk in a different language, and you want them all to have a discussion. The only reasonable way is to tell them all to talk exactly in the same language.

Every system, device, and application you want to show the right colors must be color managed. Preferably with custom profiles built for each one (if possible).

But even then, there are applications that do what they want, no matter what (I’m talking specifically about Chrome)

So color management is the way to go, but most probably there will be issues that will need to be solved.

10

You need to do this whether or not you’ve got all the pieces working. A viewer needs to know the tone and color to which an image is encoded, and that information is in the embedded profile. Without that, all the investigation and tweaking you do of the color management pieces will not work.

11

Thanks – I had been working under the (apparently incorrect) assumption that absent any color management in the video card, OS, or app, image viewer apps would take an image (with no associated profile) and just display it without altering the color/gamma/etc, i.e. they would assume the worldwide standard of sRGB (or some slight variant of the sRGB profile they might be using). [edit: setting aside Mac gamma questions for the moment.]

I mean, clearly I’m wrong, given the dramatic gamma and color shifts here (which persists when I am doing no color management anywhere), but this is the issue I’m trying to get at. The issues with Chrome/Firefox/etc displaying images differently comes down to embedded profiles, and rendering intents, right? I’m talking about the case where there are no profiles involved anywhere, there is no rendering intent issue (because it’s a regular 8-bit image with no associated profile) and the images still look (very) different in different apps (i.e. more different than variants of sRGB could explain.)

Maybe the apps are using a different rendering pipeline, and therein lies the difference/bug/whatever?

I know that I should use color management if I want to get true colors. That’s not my goal: I’m trying to understand what particular mechanisms are causing this under the hood of my system so I can better predict how this image will look on the open web.

12

There are a least 2 ways on linux for application to determine the output color profile on linux: X atom and colord. If you have different profile for each, then apps will output different image based on which way they determine the output profile. You can check it via darktable-cmstest.

(However darktable 3.0.1 and 3.0.2 has bug and doesn’t apply input profile by default)

13

So, to try to narrow this down, is the difference you’re seeing in tone, or color, or both?

I just looked at the source code of both gwenview and feh; gwenview uses LittleCMS, so I’ll assume it’s color managed; feh has no color management code I can find. Given this, looking at your gamma_difference.png, I would speculate your display profile has a problem, maybe in the blackpoint…

14

Mmmkay so I might be getting a clue, here…

I thought setting profiles via dispwin was a video-card-level operation, but it seems clear that I was wrong about that, correct? It’s merely yet another way to associate profiles with displays that apps can ignore or obey at their discretion?

If I disable KDE’s autostart for “Color Daemon” (which I assume is colord), voilà: feh and gwenview are identical.

The confusing bit is that if colord is enabled, changing profiles affects both feh and gwenview (indeed the whole desktop), which gives one the impression that they are both running through the color correction that the profiles are enacting. But it would seem that there is some additional layer of processing that only gwenview accesses when colord is alive, thus causing the differences. Supporting this theory is the fact that the differences in the image are “the same” regardless of which profile is set: you can see the profile switching in both, but the relative differences between the images remains. So it seems like this mysterious “extra processing” is causing the issues, as opposed to the particular ICC profile per se.

A remaining question is why firefox renders in yet a third way. Perhaps it applies the “mysterious processing” and not the profile, or vice versa, or some other black magic? [edit: whatever it is is also colord related: when colord is disabled, firefox also looks identical to the others.]

@ggbutcher – I’m seeing both tone and color differences. Illustrative screenshot is here. (That’s feh and gwenview overlapping.) Thanks for checking the code!

@danny – I can’t find a ppa or any other easy way to install the recent darktable on my Kubuntu 18.10 install… looks like darktable-cmstest goes back a few versions so I tried to install an older one but now I broke my darktable install entirely, so that’s a miss for now. Any other way to query that information? I can provide the output of “colormgr get-devices-by-kind display” for example, if this is still information worth gathering. “xlsatoms | grep -i ICC” returns “537 _ICC_PROFILE”, but I doubt that’s useful.