Refactor modm:ui:color

[TomSaw]

While working on #604 the fragmentation of Colors (modm::ui::color and modm::glcd::Color) forced me to this PR.

Key changes

• Integrated modm::glcd::Color (Rgb565) with modm::ui::color
  • Backwards compatible: named constructors still work glcd::Color::black(), glcd::Color::white() a.s.o.
• New "Color" Brightness to be used with Grayscale and Monochrome Displays, Simple dimmed LEDs
• New Color-Factory color::RgbHtml returning color::Rgb by by HTML-Colornames
• Moved colors into own dir ../modm/ui/color and seperate *.hpp
• Replaced ::toHsv(...), ::toRgb(...) with constexpr conversion constructors.
  • You can now simply type color_display.setColor(color::Rgb(255, 0, 0)) or color_display.setColor(color::Hsv(0, 100, 100)) to submit pure Red in Rgb565 format.
  • Also check /src/modm/ui/led/rgb.hpp where setColor(Hsv color) and fadeTo(Hsv color, uint16_t time) has become rudimentary.

Performance

Using conversion constructors is defacto more elegant. I've compared the compilates: No differences ...

• ... no matter if you compare old vs new implementation
• ... no matter if you compare various constructors for one and the same color:
  • color_display.setColor(color::Rgb565(0xF800))
  • vs color_display.setColor(color::Rgb(255, 0, 0))
  • vs color_display.setColor(color::Hsv(0, 100, 100))

[salkinium]

So far so good!

[TomSaw]

Hey @salkinium please check color::Brightness. I've quickly sketched the RgbT(BrightnessT<_T> brightness) conversion constructor. What's the right reverse of the formula???

8bpp Grayscale
8bits per pixel, but grayscale! This uses the following formula to map colors onto their perceived brightness:
Luminence: (0.2125 * red) + (0.7154 * green) + (0.0721 * blue)

/test/modm/ui/color/color_test.hpp unveils asymetries on forward-backward conversion (Rgb -> Hsv -> Rgb). I think it's normal cause information is lost on conversion but really that much?

Edit: Got some new ideas and investigate this in another session... color_test.hpp is work in progress Stay tuned...

[TomSaw]

Have you looked into the upainter colors? They are already implemented for a lot of formats and tested and fairly fast with some basic bit optmizations and include implementations for all of the Porter&Duff composition operations (original paper). Some of these operations are also supported in hardware by the STM32 DMA2D, which is why I initially implemented them.

I'm busy with work so this slowed down. Let me finish up the color-tests + CI-claims so you can merge the state. The impros fit the goal of "refactoring color" and are worth being shared with the folks! @salkinium

These Rgb-Calculations, Saturated-stuff and upainter-integrations then receive their personal silent hours in a fresh PR.

[salkinium]

I refactored your branch a little myself instead of giving you a bazillion comments. I mostly changed style and removed some top-level using namespace foo; in headers which would leak into the whole code.

Apart from the relative/normalize color functions I'm happy with this now!

[TomSaw]

I'll check it firstly in the morning + and gonna add these tests so we can clean the table:

Got pretty good drive today optimizing the dusty graphic algorithms witch is lots more fun.

[TomSaw]

Didn't want to touch the relative/normalize stuff in Rgb since it doesn't hurt me (to much), I actually have no usage for it and especially didn't want to break someone's algos.

[TomSaw]

Few more sessions general improvements on the graphics API and my head is ready to study upainter and see what we can make with all of it.

[salkinium]

I extracted the weird RGB normalize into their own standalone function.

[TomSaw]

I extracted the weird RGB normalize into their own standalone function.

Wunderbar. I've been very dismotivated to do that... thanks @salkinium 🍬

[TomSaw]

... instead, i've made great strides with the graphics functions. Anything has become so badly fast.. coming soon. need to cleanu and prepare a good presentation cause i wanna change the APIs.