added contrast methods

[daveheitzman]

added methods to Color::RGB to calculate the contrast between two RGB colors

[trans]

On the surface at least, this looks like a good addition.

Is anyone actively maintaining color gem?

[daveheitzman]

looks like it hasn't been touched by halostatue for almost 2 years. it's a good gem, and my addition to it isn't scientific. I'd love to see a good, reliable contrast function.

dave

---

From: 7rans reply@reply.github.com To: David Heitzman daveheitzman@yahoo.com Sent: Thursday, February 23, 2012 11:56 PM Subject: Re: [color] added contrast methods (#1)

On the surface at least, this looks like a good addition.

Is anyone actively maintaining color gem?

---

Reply to this email directly or view it on GitHub: https://github.com/halostatue/color/pull/1#issuecomment-4151959

[trans]

If you are sure about the API (ie. the methods names, parameters and return types) then a "non-scientific" implementation is okay. It can be improved in good time.

I think this is a very good gem too, and I'd like to see some API improvements to make it easier to use and a few feature additions. If that could happen I would likely make it a back-end dependency of the ansi gem.

Maybe if there is no word after a while, I will spin it off as color2 gem ?

[daveheitzman]

i'll check over the code and make sure it's right. if so, we could contact halostatue and see if he wants you or me to maintain the gem. otherwise, we could fork it, but only if we have significant additions to make to it.

dave

---

From: 7rans reply@reply.github.com To: David Heitzman daveheitzman@yahoo.com Sent: Friday, February 24, 2012 12:43 PM Subject: Re: [color] added contrast methods (#1)

If you sure about the API (ie. the methods names, parameters and return types) then a "non-scientific" implementation is okay. It can be improved in good time.

I think this is a very good gem too, and I'd like to see some API improvements to make it easier to use and a few feature additions. If that could happen I would likely make it a back-end dependency of the ansi gem.

Maybe if there is no word after a while, I spin it off as color2 gem ?

---

Reply to this email directly or view it on GitHub: https://github.com/halostatue/color/pull/1#issuecomment-4162536

[halostatue]

Hey, guys. If someone wants to help maintain the gem, then please let me know.

That said, @daveheitzman, I'm not sure that the calculations indicated are ideal—and there’s no tests. There's already a #brightness_diff and a #color_diff in lib/color/palette/monocontrast.rb that were constructed in part with W3C accessibility guidelines in mind. I haven't yet looked deeper, but I think it may be possible to make this viable in this way.

[halostatue]

I'm leaving the pull open although this code probably won't be accepted as is given the note above; I am interested in incorporating some variation of it—and have had it sitting around in a repo for consideration for almost two years.

[daveheitzman]

truthfully, what I"d like to provide is a method that receives a color and a desired minimum contrast and returns an object that contains or generates a set of colors that meet that minimum contrast requirement. The use case for it is something like, I have a background, and I want to know what colors I can use that will be legible against it.

I have not written this method. Perhaps I'll take a look at it again.

[halostatue]

That might be related to the Palette stuff that I already have in place.

[halostatue]

Hey, @daveheitzman—I think that @armahillo may have provided a good basis for this with the #delta_e94 implementation, as long as we're in the sRGB space. I have wanted to implement colour spaces for a while to enable XYZ and Lab* transformations and I think that I'm understanding this better (and @armahillo’s links included a great resource in Bruce Lindbloom’s site from which I'll be able to implement more of this).

What do you think?

[daveheitzman]

Uh.. not sure having a static analysis tool (Hound) put all its comments in here is a good idea. Can they be put under their ticket # ?

Anyway, regarding issue of how to calculate contrast between colors in the rgb space. here is a little comparitor app so you can see how the two methods differ.

Neither seems to do better than about 80%

http://stormy-thicket-6794.herokuapp.com/colores

[armahillo]

There are newer formulae (CIE2000, for example) that might be more effective, but they use math functions i am less familiar w in ruby. On Apr 27, 2014 4:11 PM, "David Heitzman" notifications@github.com wrote:

Uh.. not sure having a static analysis tool (Hound) put all its comments in here is a good idea. Can they be put under their ticket # ?

Anyway, regarding issue of how to calculate contrast between colors in the rgb space. here is a little comparitor app so you can see how the two methods differ.

Neither seems to do better than about 80%

http://stormy-thicket-6794.herokuapp.com/colores

— Reply to this email directly or view it on GitHubhttps://github.com/halostatue/color/pull/1#issuecomment-41507441 .

[daveheitzman]

http://stormy-thicket-6794.herokuapp.com/colores

this provides a side-by-side comparison of the 3 algorithms. Each sorts a set of random colors according to its contrast against a background, from greatest to least contrast.

[halostatue]

Disabling hound. Interesting, but ultimately not useful and I don't have time to configure it to my own tastes.

[halostatue]

I have to look at this a bit further, but I suspect that it might not be as hard as you think. #closest_match is definitely not going to work, but being able to use the ΔE94 algorithm in order to get a distance between colours may actually be able to make what you've but together a little more scientific.

I'm going to be trying to get a new version of color out soonish, but I fear that more time is going to be tied up in the next release of diff-lcs—it turns out that a bug that I thought was fixed hasn't been fixed, and my test has been bogus all of this time. :(

[daveheitzman]

I don't have much of an opinion on #closest_match, except that it seems a bit overly specific a method for this library.

My hope would be to provide the best #contrast method we can. My experimentation is suggesting that #delta_e94 is not better than my implementation.

I am working on implementing delta_e2000, maybe that will show better results.

[halostatue]

I think #closest_match, as a wrapper for #delta_e94, isn't a bad thing to have. It suggests at least one other method which hasn't been implemented (#furthest_match), and being able to specify a match range wouldn’t be bad, either.

BTW, your code here has been integrated into Color, but you have to require 'color/rgb/contrast' to get them, as I considered them experimental.

I'm looking forward to playing with this codebase again—there's things that I'm doing manually that should probably be done using Matrix, and I think that we've got the tools and I have a better understanding to be able to start implementing absolute colour spaces with reference white points, allowing better transformations of colours through CIE L_a_b* space.

[daveheitzman]

Okay, this is getting frustrating. I just entered an implementation for ew2000 which came straight from the research paper (don't bother with the wikipedia explanation-they didn't get the formulas quite right.) Anyway, to sum up, it doesn't seem any better at detecting low contrast than the other 3 algos.

Here: http://stormy-thicket-6794.herokuapp.com/colores

watch as the 4 attempt to sort by contrast. draw your own conclusions, I guess.

Also, my e2000 implementation is not 100% perfect. There are 1-2 cases where my e2000 is a little off from Sharma's test data, but mostly it's good. I'll put an update out if and when I get it 100% perfect.

[halostatue]

Sorry—I don't mean to frustrate you. Your app here has basically proven that the values you chose are good.

I think what I'm going to do is backtrack your implementation so that I can describe what colour spaces it works best in; I'm pretty sure yours is assuming a 2.2 gamma, and that suggests sRGB on modern displays (IIRC, Apple switched to 2.2 gamma rather than its traditional 1.8 gamma a few years ago). As I start implementing other colour space support, we'll probably need to talk about different constants for different colour spaces, gammas, and white points (see http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html for information).

[daveheitzman]

It is not you that is frustrating. It is frustrating that an algorithm developed by xerox seems no better than a common folk solution from the php ghetto.

Let me do a little reading up on colour spaces, gammas and white points. I'm ignorant on these matters. I might read Sharma's entire paper. Perhaps he provides solutions to correct for differences deriving from these constants.

[halostatue]

Fair enough.