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 671780 - gnome-bg: improve "representative colour" algorithm
gnome-bg: improve "representative colour" algorithm
Status: RESOLVED OBSOLETE
Product: gnome-desktop
Classification: Core
Component: Background
unspecified
Other All
: Normal enhancement
: ---
Assigned To: Desktop Maintainers
Desktop Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-03-10 16:11 UTC by Allison Karlitskaya (desrt)
Modified: 2018-09-21 16:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Allison Karlitskaya (desrt) 2012-03-10 16:11:42 UTC
Presently, we use a plain numerical average of the red/green/blue channels of each pixel value to determine the "representative colour" of the background image.

This has two potential problems.

The first is that the selected colour is probably not the best choice, for two reasons.  One is because selecting based on h/s/v is probably a perceptively better choice than r/g/b.  Second is because the image may have two predominant shades and we'd be better to select one of them rather than taking the average of both.

The second issue is that performance of our approach may be bad.
Comment 1 Allison Karlitskaya (desrt) 2012-03-10 16:18:17 UTC
(In reply to comment #16 of bug 671750)
> Ryan, did you mesure how long takes the pixbuf_average_value() computation?

On my laptop it takes about 9ms of extra work.
Comment 2 Allison Karlitskaya (desrt) 2012-03-10 16:42:53 UTC
For comparison, it takes 175ms to load and render the image into the pixbuf and at least an additional 22ms to copy it to the X server (I only measure time taken in the gnome-bg process -- some additional processing may still be happening on the server after my timer finishes).

I'd therefore consider the additional performance overhead "rather small".
Comment 3 Allison Karlitskaya (desrt) 2012-03-10 16:51:09 UTC
We should still consider improving the algorithm for reasons of perception, however.  Bug 661042 has some very interesting work in that direction.
Comment 4 Allison Karlitskaya (desrt) 2012-03-12 17:38:50 UTC
Some more considerations:

 - have a list of nice-looking (dark?) colours and pick the closest one to that (ie: we can avoid ugly-looking colours that way).  The tango colours are a possible choice here

 - do the histogram "bucket" approach from bug 661042

 - consider using the fact that we have a list of representative colours (and not just one) to publish a colour from each of the X geometries (northwest, north, northeast, west, centre, east, southwest, south, southeast) so that programs can discover the colour in relevant regions
Comment 5 GNOME Infrastructure Team 2018-09-21 16:31:56 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-desktop/issues/39.