GNOME Bugzilla – Bug 671780
gnome-bg: improve "representative colour" algorithm
Last modified: 2012-10-24 14:58:07 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.
(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.
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".
We should still consider improving the algorithm for reasons of perception, however. Bug 661042 has some very interesting work in that direction.
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