Make contrast/"best color" algorithm cleverer

[rugk]

STR

Set these options: Qr code color: #9494E2 background color: #6B6B1D

What should happen: The "best color" should fulfill their own requirement and not yield an error/rwarning message.

Ideas for implementation

1. [x] Somehow get what value that was last changed by the user, and change this value, instead of always the background color (if I remember correctly). Or just do it by random? DONE in https://github.com/rugk/offline-qr-code/commit/c62016602966424de8043b6696c3d5cd71d8d266
2. [ ] Do not use exact contrast, but add some randomness.
3. [ ] Self-check the color and generate a new random one if it does not match the contrast requirement. Note: The loop must somehow make sure it does not run indefinitively. So stopping at some point would be possible, but does not actually solve our problem here. Better increase the "randomness factor" with each run. :smile:

Or does someone can come up with some maths, for the "best color" here, so the algorithm does not have to guess in a loop?

/cc @ENT8R, @LMLB

(follow-up of https://github.com/rugk/offline-qr-code/issues/19)

Edit: The new algo should not override the "getContrastColor", i.e. that should still be exposed. We may then not use it, but I consider it is a nice thing for such a module.

[rugk]

For obvious reasons it mostly happens, when you select two very light or two very dark colors.

[rugk]

I already implemented the first part. Apart from this, I think, this is now an easy issue and something I really would like to get some input on how to do it best.

As for implementation it mostly only happens in the Colors module, so it is quite constrained.

[rugk]

This can even result in a loop… 🤔

[rugk]

Oh I found a bug. See https://github.com/rugk/offline-qr-code/commit/21c544a4be46e48e6560b7cd660b95c1c83c9da7. I used the inverted color on the wrong element. This mitigates this problem a bit. Just for visually appealing I would still suggest to still mix in some randomness.

For some reason, however, it does still show an info message (<4.5 contrast ratio) for these colors:

#78c272 #873d8d

And these are contrast colors – at least if you press the button it does not change anything. However, the contrast ratio is still only 3.16. So the contrast code does not seem to have a bug, but actually the code to invert colors is also simple – as we have implemented it here. Or is it actually correct that the inverted color does not have to have a high contrast? 🤔

The same e.g. works with the colors in the first example I gave in the originating post.

It seems to be reproducible when both colors seem to be from the "middle" here:

…i.e., when they are not very bright, but rather mixed with grey. Or maybe I am totally wrong here.

If you choose two grey colors and maybe even make them split nearly 50:50 between dark and white, they of course are also inverted colors, but have a really low contrast… 😐

[rugk]

Maybe https://www.utdallas.edu/~melacy/pages/2D_Design/Itten_ColorContrasts/IttenColorContrasts.html is a read, which could help. As the "inverted" color should actually be called "complementary" color…