How to get proper transparency on images ? I have noise on rendering

luc-github · August 8, 2019, 12:55pm

First thank you for this amazing library:smiley:

I am using ESP32 + ILI9488 screen and XPT2046 touch, under window the lv_arduino-2.0.3 library with TFT_eSPI-1.4.11 library and latest ESP32 git core

my LV_COLOR_DEPTH is 16
and I have set LV_COLOR_TRANSP LV_COLOR_MAKE(0xFF, 0x00, 0xFF) (issue is same with original color)

I have converted this jpg with online converter tool using True color chroma keyed and Binary RGB565 to bin file

logo
I use Paint.net to create initial image

The generated bin file is copied to SPIFFS partition, I have wrote a SPIFFS wrapper following online documentation and it seems working.

The issue is that global rendering of picture is noisy, still some dots appear around not transparent areas when should be transparent
Here the picture : (sorry for quality)

here a zoom for reference, purple follow the line and noise purple dots are all around

I have tried every format and settings in online converter - redo the picture to be sure the noise does not come from original picture, I use jpg because png rendering is not correct, like a blue filter on image.
If I use full transparent image (filled with transparent color) no noise, image is fully transparent =>ok
If I do not use transparent color, no noise but image of course has no transparency=>ok

Do I miss some settings ? Do I do something wrong ?
Or it is a bug with transparency ? Or with Online converter ?
I do not know where to look at, thanks for your help

embeddedt · August 8, 2019, 1:01pm

You’ll have to use PNG if you want it to work properly. JPEG compression will mess up the chroma keying.

luc-github · August 8, 2019, 1:19pm

OK thank you, it is good to know jpg is not the good choice for transparency

I will focus on png then, it may be some default settings when saving that are not corrects.

luc-github · August 8, 2019, 1:43pm

Seems I tested all settings but right one

By default when saving png Bit Depth was set to Auto-detect which bring random rendering depending on content: black image, blue image, etc, set 8 bits or 32 bits give same results, but looks like 24bits is ok, no noise, proper rendering.
Windows Paint does not give choice and seems ok out of the box.

I am not familiar with image settings, I was confused with LV_COLOR_DEPTH 16 so did not tried the 24bits.

thank you for the help, really appreciate

embeddedt · August 8, 2019, 2:05pm

(cc @kisvegabor)

This is interesting. Ideally the image converter should be able to handle PNGs of any depth. Maybe this is something we need to look into? I’ll test it soon.

kisvegabor · August 9, 2019, 12:58pm

I’ve never tested it but I assume with lower color depth it tells the pixel values as they are. So if Red has 0…31 range it doesn’t scale it up to 0…255.

I’ve added a note about it on the converter’s site: Littlevgl - Beginner's Photo Editor Blog

luc-github · August 17, 2019, 2:52pm

One note about transparency, may be it is a known issue :
Using Theme will affect transparency rendering, for example using green as transparent color will stay green in image if Mono theme is used but will be transparent with default theme.

kisvegabor · August 17, 2019, 3:36pm

Could you send the converted image?

Which color depth do you use?

luc-github · August 17, 2019, 4:26pm

Well this is embarassing - it seems I am back to square 1 - issue I thought coming from theme, came in fact from conversion, even in normal theme transparency is not taken in account, (using new snap feature)

![logo|200x150]
I enclose the original png file : logo.zip (2.5 KB)
and the converted file
esplogo.c (1.5 MB)

done by :

and related conf settings

/* Maximal horizontal and vertical resolution to support by the library.*/
#define LV_HOR_RES_MAX          (480)
#define LV_VER_RES_MAX          (320)

/* Color depth:
 * - 1:  1 byte per pixel
 * - 8:  RGB233
 * - 16: RGB565
 * - 32: ARGB8888
 */
#define LV_COLOR_DEPTH     16

/* Swap the 2 bytes of RGB565 color.
 * Useful if the display has a 8 bit interface (e.g. SPI)*/
#define LV_COLOR_16_SWAP   0

/* 1: Enable screen transparency.
 * Useful for OSD or other overlapping GUIs.
 * Requires `LV_COLOR_DEPTH = 32` colors and the screen's style should be modified: `style.body.opa = ...`*/
#define LV_COLOR_SCREEN_TRANSP    0

/*Images pixels with this color will not be drawn (with chroma keying)*/
#define LV_COLOR_TRANSP    LV_COLOR_LIME 

/* Enable anti-aliasing (lines, and radiuses will be smoothed) */
#define LV_ANTIALIAS        1

I am sure I was able to do transparency before, but not anymore
The difference is before I used external binary when now I use C array, I think.

embeddedt · August 17, 2019, 5:01pm

Check that LV_COLOR_LIME has the same RGB value as the green pixels in your PNG file (using something like GIMP). It’s possible that they are slightly different shades of green. You might need to modify LV_COLOR_TRANSP appropriately.

luc-github · August 17, 2019, 5:05pm

yes it does,

#define LV_COLOR_LIME LV_COLOR_MAKE(0x00, 0xFF, 0x00)

kisvegabor · August 17, 2019, 5:15pm

It’s working for me:

    LV_IMG_DECLARE(esplogo)
    lv_obj_t * img = lv_img_create(lv_scr_act(), NULL);
    lv_img_set_src(img, &esplogo);

What do you get for this?

    printf("%d\n", lv_img_color_format_is_chroma_keyed(esplogo.header.cf));

It should be 1.

luc-github · August 17, 2019, 5:59pm

Yes it is - I even revert to initial sample code an just add the image
ESP32_TFT_eSPI.zip (22.0 KB)

Still no transparency - I am really lost

luc-github · August 17, 2019, 6:10pm

ok changing in lv_conf.h

#define LV_COLOR_TRANSP LV_COLOR_MAKE( 0x00, 0xFF, 0x00)
to
#define LV_COLOR_TRANSP LV_COLOR_MAKE( 0xFF, 0x00, 0xFF)

and changing to same color in png and transparency is back with sample code that previously failed,
and this is the color I used in inital test

So my config does not like green

luc-github · August 17, 2019, 6:46pm

and I confirme now ok on my main program.

and to come back to the note : the issue is not the theme, transparency works well with mono theme

Sorry for the confusion - I did not trigged the root cause properly

Issue is definively the green transparency not seen on my 16 Bit depth system, could it be because of this bit depth and so color 0x00, 0xFF, 0x00 can not be reached due to RGB565 ?

It is not a real problem now I know ^_^: Png 24bit and 0xFF, 0x00, 0xFF for transparency color

kisvegabor · August 18, 2019, 4:00am

The first pixel in the converted image has 0xe0, 0x07 value. It’s Little endian so the real value is 0x07, 0xe0. In binary 0000 0111 1110 000. In RGB565 R00000, G111111, B00000. So the converted image should be fine.

The chrome keying is handled here:

github.com

littlevgl/lvgl/blob/bbb0d2f60efc7154597928bfeef94b377ce870d3/src/lv_draw/lv_draw_basic.c#L504


    lv_opa_t px_opa = *(px_color_p + LV_IMG_PX_SIZE_ALPHA_BYTE - 1);
    if(px_opa == LV_OPA_TRANSP)
        continue;
    else if(px_opa != LV_OPA_COVER)
        opa_result = (uint32_t)((uint32_t)px_opa * opa_result) >> 8;
} else {
    px_color = *((lv_color_t *)px_color_p);
}


/*Handle chroma key*/
if(chroma_key && px_color.full == disp->driver.color_chroma_key.full) continue;


/*Re-color the pixel if required*/
if(recolor_opa != LV_OPA_TRANSP) {
    if(last_img_px.full != px_color.full) { /*Minor acceleration: calculate only for
                                               new colors (save the last)*/
        last_img_px  = px_color;
        recolored_px = lv_color_mix(recolor, last_img_px, recolor_opa);
    }
    /*Handle custom VDB write is present*/
    if(disp->driver.set_px_cb) {

It should be worth some debugging to see what have happened.

luc-github · August 18, 2019, 8:07am

Ok I will check and report later

luc-github · August 18, 2019, 8:55am

I have added line 504 :

if ((col == 0)&& (row == 0)) {
                    printf("chroma_key: %#08X, px_color.full:%#08X, chroma_key && px_color.full:%#08X, disp->driver.color_chroma_key.full:%#08X\n",chroma_key, px_color.full, chroma_key && px_color.full, disp->driver.color_chroma_key.full);
                }

with

#define LV_COLOR_TRANSP    LV_COLOR_MAKE(  0xFF, 0x00, 0xFF)

and purple image bg I got transparency and output is :
chroma_key: 0X000001, px_color.full:0X00F81F, chroma_key && px_color.full:0X000001, disp->driver.color_chroma_key.full:0X00F81F

with

#define LV_COLOR_TRANSP    LV_COLOR_MAKE( 0x00 , 0xFF, 0x00)

and green image bg I do not get transparency and output is:
chroma_key: 0X000001, px_color.full:0X0007E0, chroma_key && px_color.full:0X000001, disp->driver.color_chroma_key.full:0X00F8

I enclose the 2 images sources and mcve
ESP32_TFT_eSPI.zip (50.9 KB)

Edit : I realize I misread chroma_key && px_color.full == disp->driver.color_chroma_key.full
should be : chroma_key && (px_color.full == disp->driver.color_chroma_key.full) to avoid confusion, but output is still meaninful

Let me know if you need me to add more info on debug

embeddedt · August 18, 2019, 11:00am

What is the RGB type of the image before conversion? 16-bit or 32-bit?

luc-github · August 18, 2019, 11:11am

I use 24bits as this is the one working for me with the online converter as mentioned earlier
-
same used for green background and purple background