Chroma Keying about lv_img_conv

[embeddedt]

I don't think the screen needs to have an alpha channel; the alpha values are consumed by LVGL in the rendering process (e.g. for rendering widgets behind the image).

[embeddedt]

@tvanfossen Thanks for opening this. I agree that the dithering logic could be improved in this scenario so I'll see what I can do. I also like the idea of having the converter handle chroma-keying the image for you.

I cannot reproduce the first part of your issue, where pink pixels are still visible on the LCD even if dithering is not enabled. Here is the command I am running:

./lv_img_conv.js img.png -f -c CF_TRUE_COLOR_CHROMA -o ~/work/lv_newproj/lv_sim_eclipse_sdl/test.c -i test_img

I am then using the resulting image in the PC simulator by creating an image object and setting its source - no other changes.

When I tried putting the simulator in 16bpp mode, I can see that the edges of the hand might be very slightly pink, but only if I zoom in on the individual pixels in GIMP. On the simulator itself I can't tell.

[kisvegabor]

indexed should do an even better job as you can have a semi-transparent colors too. E.g. opa=25%, 50%, 75%, etc.

[kisvegabor]

If transformations are also required you can do 4 things:

• Use chroma keying without having alpha channel (result in jagged edges)
• If you always place the images on this dark background you don't need alpha channel. Just use TRUE_COLOR format and the dark background on the image too
• Use TRUE_COLOR_ALPHA images (3 bytes/pixel)
• Use the new transformation feature of LVGL. It renders the widget into a buffer first and rotates that buffer. The only difference is that you need to use style_transform_angle and lv_img_set_angle(). It will temporarily allocate a buffer equal to the size of the transformed widget. To great thing in it is that the children are transformed as well.

[tvanfossen]

Original image used in both examples below to generate c array is slightly different than chroma colored image above. It leaves the dithering from original transparent image from above in place instead of making it all white.

Using the above as part of an invoke call to generate images from a provided folder produces the below image on LCD, hard to see but see a non-uniform pink edge around the image (so sounds like a 16bpp issue here, or indirectly an issue with how I was trying to leave dithering from png in place)

Using the above with dithering on, seeing a uniform pink edge around the image. Nominally would prefer to leave dithering on

Obviously a bit hard to see given the resolution of the screen against camera artifacts, but in all cases, LVGL is doing what its supposed to in not drawing the chroma color (0xFF00FF)

[embeddedt]

@tvanfossen Sorry for the delay in getting back to you. I'm still unable to reproduce this so I must be doing something wrong. I tried your second image with this command:

./lv_img_conv.js -d true -f -c CF_TRUE_COLOR_CHROMA -o hand.c hand.png

However, it looks perfect on my screen:

I don't doubt that there's an issue here, and your explanation makes sense. However, I need to figure out how to reproduce it to fix it. Did I miss something?

[tvanfossen]

What color depth are you displaying on-screen? Could it be an issue only present in 565 displays?

[embeddedt]

I am using LV_COLOR_DEPTH = 16.

…

On Sun, May 8, 2022 at 10:20 AM tvanfossen ***@***.***> wrote: What color depth are you displaying on-screen? Could it be an issue only present in 565 displays? — Reply to this email directly, view it on GitHub <#17 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKHTVAFM3LGJSHKZJHHDCTDVI7ESBANCNFSM5TZHZQGA> . You are receiving this because you commented.Message ID: ***@***.***>

[tvanfossen]

hand.zip
hand_dither.zip

These are the c array files being converted (with and without dithering)

I can confirm that I do not see this issue on the TFT simulator, but DO see this issue on the LCD

Tried both dithered and undithered c arrays on simulator and see no pink outline in either case. Simulator set to use color depth 16 with swap

On the LCD, the same c arrays both produce a pink outline

[tvanfossen]

Overlaid the hand images onto a parent lv_obj_t grey circle as in the examples on LCD screen provided above for sanity, seeing the same case of no pink outline showing in simulator.

[embeddedt]

@kisvegabor Any ideas why SDL and an actual LCD would display an image differently, if they are both using the same color depth?

[kisvegabor]

It seems there is a problem with the image:

So the image has alpha channel too. When I removed the Alpha channel in GIMP, the image looks like:

Okay, the extra pixels are not not pink but blue, but I believe it causes the problem.

[tvanfossen]

interesting, odd that it converts to blue? For the SDL sim to not show an outline, but on an LCD to show, with the same bitmap, seems to imply a problem in the display driver as well?

[kisvegabor]

Does the other colors look correct on your device? E.g. if you set the bg color of rectangle to lv_color_hex(0xff0000) will it be red?

[tvanfossen]

Yes, all other colors appear as intended

[kisvegabor]

I have no idea why they turn to purple . 🙁 Probably we could track it, but I think there is no defined behavior (at least I not defined it when implemented the image renderers 😄 ) when chroma keying and alpha are used together.

Does chorma keying works well if you remove the alpha channel?

[tvanfossen]

Removing every bit of transparency from PNG will give a properly colored image, but then results in jagged edges due to lack of dithering

Have tried a few different ways in gimp to keep the dithering in place while replacing alpha with chroma, with no luck

[kisvegabor]

For an image like this I suggest using e.g. INDEXED_4BIT. With this you have 16colors in a palette and any of these colors can have any alpha value.

[tvanfossen]

I'll give indexed a shot - was trying chroma keying to be able to layer images/widgets on top of each other nicely

[tvanfossen]

Would there be any issues with that on an RGB565 screen without an alpha channel?

[tvanfossen]

This 100% resolves the issue with dithering in chroma keying, but introduces a separate issue

When producing bitmaps from PNG assets (the hand png from above with alpha channel) with CF_INDEXED_8_BIT, image looks perfect on screen, exactly as desired.

However, rotation and zoom animations no longer perform as expected on these images. I might just be missing something simple as I havent used the indexed color in LVGL as of yet.

....

Which after a moment of checking the docs

So while an indexed image resolves the issue with chroma keying, it breaks animations that would otherwise be applied normally to a chroma keyed image

[tvanfossen]

For reference, the same screen/animations with the chroma keyed image asset

[tvanfossen]

Will give the transform a try!