Its a debug message; gnome-screenshot just lacks the log handler setup to not show these by default.

Hi Matthias,

I'm using F16, my concern is also for the missing /usr/bin/gcm-session which should be installed by package gnome-color-manager but which is not.

Actually this issue is caused by bug 667134.
so gnome-screenshot should use the new API provided by
gnome-settings-daemon

gnome-settings-daemon has no such API. I believe we would need to ask colord directly.
Richard, what API should we use instead of GetProfileForWindow?

I don't see this warning here (probably because bug #667134 is fixed).

But there's something I don't understand here, fundamentally: since my screens are now calibrated and managed with fullscreen color correction, the screenshots I take with gnome-screenshot or by simply pressing the printscreen key (optionally with the Alt modifier etc.) show up with the wrong colors when opening them with Eye of GNOME, as if they had an embedded color profile (unlike the premises of this bug report?) that gets applied twice (by the app and then with fullscreen color correction on top), which would seem exactly like what one would want it *not* to do.

Shouldn't screenshots be taken with the raw colors, without fullscreen color management affecting them? Does gnome-screenshot or gnome-shell take color correction into account and embed such information in the resulting images nowadays, or that's not the case?

I'm worried about those screenshot files being "tainted" with a profile when they shouldn't, which would result in them being misrendered on other computers as far as I can imagine - am I missing something? It's a bit confusing.


See also: https://bugzilla.gnome.org/buglist.cgi?query_format=advanced;short_desc=color%20colour;short_desc_type=anywordssubstr;resolution=---;product=eog

-> gnome-shell

This is a tricky issue; the shell/compositor does not currently know about the color profile in use, so the screenshot (taken by the shell) will be color corrected.
The ICC color profile should be attached to the picture though, so that your viewer can convert the colorspace. This used to work, see bug 613926 that describes the same use case, but then the colord API was removed and the code never ported to another one.

These days it's arguably the shell that should embed the color profile information into the image, since it also first saves the image to disk.

Okay, seeing as this hasn't had any activity for almost four years, I re-submitted this on GitLab here: https://gitlab.gnome.org/GNOME/gnome-shell/issues/272.

Hopefully that's allowed?

Of course it's allowed, but creating additional work that has to be spend on bug triaging instead of fixing issues isn't the most productive. But now that it's done, let's close this one to prevent the bug from being migrated to gitlab.