feat(draw/sw): added support for LV_COLOR_FORMAT_L8

[zjanosy]

Description of the feature or fix

Implemented rendering L8, RGB565, RGB888 and ARGB8888 into L8 canvas.
Implemented rendering L8 format image into L8, RGB565, RGB888 and ARGB8888 canvas.

Notes

Documentation, examples and tests are WIP.

[liamHowatt]

All changes make sense to me at first glance.

L8 cogwheel image looks okay on COLOR_DEPTH 8, 16, 24, 32.
L8,RGB565,RGB888,ARGB8888 cogwheel image looks okay on COLOR_DEPTH 8.
Blending untested.

It's a large space of possibilities to test. The eventual test cases will reveal any non-obvious problems.

[razor5k]

Hi,
does it make sense to add integer rounding before divide operations?

//example
static inline uint8_t lv_color_luminance(lv_color_t c)
{
return (uint8_t)((uint16_t)(77u * c.red + 151u * c.green + 28u * c.blue) >> 8);
}
//to
static inline uint8_t lv_color_luminance(lv_color_t c)
{
return (uint8_t)((uint16_t)(77u * c.red + 151u * c.green + 28u * c.blue + 128) >> 8);
}

[zjanosy]

Hi, does it make sense to add integer rounding before divide operations?

I don't think it would be visible, and it would be a little bit slower. In fact, this formula is already an approximation, so I would not bother. Maybe an even simpler (and faster) approximation would do, like ((c.red << 1) + (c.green << 2) + c.blue) >> 3, although this may need some scaling to reach the maximum value of 255.
Here is a comparison of using the "real" formula and the crude approximation:


There is little visible difference, except that the latter is a bit darker (which could be fixed by an additional scaling, but then we loose the performance gain -- if there is any on modern architectures).

[razor5k]

You made a valid point not to round. If you don't see a huge difference, it may be better to be faster.

[kisvegabor]

Hey,

Thank you or the PR! It was already requested by a lot of people! 🙂

I've tested it like this:

  lv_demo_widgets();

  lv_draw_buf_t * draw_buf = lv_snapshot_create_draw_buf(lv_screen_active(), LV_COLOR_FORMAT_L8);
  lv_snapshot_take_to_draw_buf(lv_screen_active(), LV_COLOR_FORMAT_L8, draw_buf);

  lv_obj_clean(lv_screen_active());
  lv_obj_t * canvas = lv_canvas_create(lv_screen_active());
  lv_canvas_set_draw_buf(canvas, draw_buf);

You can notice that

• the center of the slider is empty
• the shadow below the the buttons are missing

lv_demo_render(LV_DEMO_RENDER_SCENE_FILL, LV_OPA_50);

ARGB as reference

---

I've updated the tests to support rendering to L8 and added the reference images as well for this test case. It seems there are a few places where the rendering is not correct. Could you take a look at these?

[kisvegabor]

The CI passing for me locally, but here is an off by one error here. Do you have any idea why the rendering can be platform dependent?

[kisvegabor]

FYI, the issue is here:

So when a scaled ARGB8888 image is blended to L8.

[kisvegabor]

And it's passing now. We will see if the passing or the failure have happened by "accident".

I've discussed it with @zjanosy that he will update lv_demo_render with blending A8 and RGB565A8 images too (so use these as source and not destination)

[kisvegabor]

I've just fixed the code formatting issue.

[kisvegabor]

Use an include similar to the other images.

[zjanosy]

Fixed.

[kisvegabor]

I've removed the accidentally changed test files.

The rest is looking good!

[FASTSHIFT]

Why was it modified? it comes from this fix: #5979

[kisvegabor]

I reverted it.

[XuNeo]

Should it be lv_color8a_t?

[kisvegabor]

lv_color16a_t is really misleading as lv_color16_t is RGB565. lv_color_al88_t would be cleanest, but it's different style. lv_color8a_t can be a good trade off.

[zjanosy]

While I agree that lv_color16a_t is not the best name, the naming scheme was that the number in the color format name indicates the number of bits of the value. Therefore I think color8a is a bit misleading, too, because it suggest that it is a 8 bit value, which it is not. Maybe lv_color8a8_t would be better (although ARGB8888 is called lv_color32_t, and not something like lv_color24a or lv_color24a8).
Certainly, the cleanest solution would be to call them as the corresponding color format is called, i.e.:
lv_color32_t -> lv_argb8888_t
lv_color16_t -> lv_rgb565_t
lv_color16a_t -> lv_al88_t
But this would likely break too much code.

[kisvegabor]

Actually we can rename these by adding typedef lv_color_argb8888_t lv_color32_t in lv_api_map_v9.h.

[XuNeo]

lv_color32_t -> lv_argb8888_t
lv_color16_t -> lv_rgb565_t
lv_color16a_t -> lv_al88_t

I agree with it. But it should be lv_color16_t --> lv_al88_t where 16 means it takes 16bits. There will be lv_color[32|24|16|8]_t.

Actually we can rename these by adding typedef lv_color_argb8888_t lv_color32_t in lv_api_map_v9.h.

Let's go for it. It can be a separate PR. We can merge this massive achievement firstly.

[XuNeo]

Is the luma here should be called lumi(nance) instead?

[zjanosy]

Yeah, luma and luminance are different terms:
https://www.geeksforgeeks.org/difference-between-luma-and-luminance/
But honestly I don't know which is the correct name in our case.

[kisvegabor]

Merged, thank you!

[GorgonMeducer]

I plan to add the Arm-2D (Helium) support for L8. In fact, in arm-2d, we call L8 the GRAY8.

[kisvegabor]

Amazing, thank you in advance!