The default bug view has changed. See this FAQ.

Improve BitmapUtils.getDominantColor to avoid returning gray-ish colors

RESOLVED FIXED in Firefox 23

Status

()

Firefox for Android
Graphics, Panning and Zooming
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: Margaret, Assigned: Margaret)

Tracking

Trunk
Firefox 23
ARM
Android
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Assignee)

Description

4 years ago
We are already trying to do this, but still failing in some cases. A few testcases that return a shade of gray instead of a color:
http://www.cnn.com/favicon.ico
http://boingboing.net/favicon.ico
http://www.amazon.com/favicon.ico

The first two are very red, so I wonder if we're doing something wrong with red hues. The third one is more about ignoring gray tones to return the dominant non-gray color.

There's some JS code in toolkit that looks a lot more complicated than what we're currently doing, maybe we can steal some ideas:
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/ColorAnalyzer_worker.js

See also bug 634139.
Bug 826780 also has some improvements we should take.
(Assignee)

Updated

4 years ago
Assignee: nobody → margaret.leibovic
(Assignee)

Comment 2

4 years ago
Created attachment 743868 [details] [diff] [review]
Clean up getDominantColor logic

So the problem with the red favicons is actually a bug with red. If maxH is 0 (red), we never end up updating maxS and maxV to return the correct color.

Looking through this code, I noticed that we don't actually do anything with sat or val, and we only keep track of maxS and maxV to put a color back together, so I decided to streamline the logic. We may want to actually compute S and V values for the dominant color in the future, but this just clarifies our current behavior.

I also found that the logic to skip black and white values was slightly off. We should be using an || instead of an &&. Fixing this returns yellow for the amazon.com logo.
Attachment #743868 - Flags: review?(wjohnston)
(Assignee)

Comment 3

4 years ago
Created attachment 743869 [details] [diff] [review]
Clean up getDominantColor logic

Oops, most recent changes didn't make it in here.
Attachment #743868 - Attachment is obsolete: true
Attachment #743868 - Flags: review?(wjohnston)
Attachment #743869 - Flags: review?(wjohnston)
Comment on attachment 743869 [details] [diff] [review]
Clean up getDominantColor logic

Review of attachment 743869 [details] [diff] [review]:
-----------------------------------------------------------------

This makes me nervous (but I know the old algorythm was prone to problems). Can you test a few webapps and see how we do (this should fix some bugs there too!)
Attachment #743869 - Flags: review?(wjohnston) → review+
(Assignee)

Comment 5

4 years ago
Created attachment 744284 [details] [diff] [review]
Improved patch

This patch does what the patch in bug 826780 was trying to do, keeping track of the average hue/saturation/value per bin, then using that to compute the dominant color that we return.

This patch also still fixes the bugs I mentioned in previous comments.
Attachment #743869 - Attachment is obsolete: true
Attachment #744284 - Flags: review?(bnicholson)
(Assignee)

Comment 6

4 years ago
Created attachment 744306 [details] [diff] [review]
Even more improved patch
Attachment #744284 - Attachment is obsolete: true
Attachment #744284 - Flags: review?(bnicholson)
Attachment #744306 - Flags: review?(bnicholson)
Comment on attachment 744306 [details] [diff] [review]
Even more improved patch

Review of attachment 744306 [details] [diff] [review]:
-----------------------------------------------------------------

Nice fixes.
Attachment #744306 - Flags: review?(bnicholson) → review+
(Assignee)

Comment 8

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/b036d96c4c87
https://hg.mozilla.org/mozilla-central/rev/b036d96c4c87
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 23
You need to log in before you can comment on or make changes to this bug.