Add Image to screen

How-to
21

@kisvegabor I tried to convert my original and also picture which you converted, but result is still the same. I also tried set LV_COLOR_16_SWAP to 1 but there is also no difference (except that my colors are wrong).

22

@kisvegabor

Sorry for my late reply. I was busy looking after my daughter, very exausting ;-).

Back to topic:
I have on HW and Simulator #define LV_COLOR_DEPTH 16
JS converter did not help, as mentioned in a post before.

My Image:
2 Darstellung 1b - Intro AA.zip (13.9 KB)

Gimp:
If I open the picture in Gimp I get the folowing message:
gimp_color
Itā€™s german, but it says that the picture has the colorprofile ā€œsRGB IEC61966-2.1ā€. Maybe this can give a hint?

If I convert it and open Gimp, the Image is set to RGB-Mode.

23

And the converted image that I forgot to attache.
jsc_intro.c (677.0 KB)

24

@Night
All work well here. I suspect that the issue is somewhere else.

Iā€™m very curious about what happens there. Are you open to letting me try debugging it via TeamViewer?

25

@dronecz
I have no idea. :frowning:
Itā€™s easier to debug @Nightā€™s project so I hope yours and @Nightā€™s issue is the same and if find the issue there yours will be fixed too.

You can still one more thing:

  1. Create only the image object that is not working
  2. Enable logging with LV_LOG_LEVEL_TRACE
  3. Post the log here.

BTW, does it work with any other image?

27

Today we (or more @kisvegabor) found the main cause of the image-problem. In my case it was the data intepretation big or little endian. Because we have a big endian system, the lvgl librarie needs to know this too. @dronecz do you have also a big endian system?

lv_config.h

#define LV_BIG_ENDIAN_SYSTEM    1

Now the picture is shown on the display, but in wrong colors. @Kisvegabor means that this problem is connected to the image convertion. @embeddedt Is it somehow possible to add a flag to the image converter to creat big-endian version of the images too?

28

I can look into this if necessary, but to keep the C file size reasonable, it might be better for LVGL to handle the endianness conversion when itā€™s reading the image.

29

Itā€™d cause a significant performance drop. Now images are simple memcpy-ed to the draw buffers, but if LVGL handled the endianness, all pixels needed to be ā€œcorrectedā€ one by one.

What about generating a file as now just swap the bytes if a ā€œBig-endian checkboxā€ is ticked?

30

Ah; I see. If images are being rendered directly then they should definitely be stored with the right byte order. Iā€™ll look into adding it to the JS converter.

1 Like
31

Hi @embeddedt

Do you think that the JS converter for Big-Endian is ready the next view weeks? I just need some time frame to do my own time planing.

Thanks for your great work at LVGL.

32

I am looking into it now.

@kisvegabor Iā€™m a little rusty on endianness; should I interpret the final byte array as 16-bit integers (AB swapped to BA) or 32-bit integers (ABCD -> DCBA)?

I assume the array can safely be padded to the required multiple of bytes and LVGL will handle that properly on a big-endian system?

33

@embeddedt

Iā€™ve checked the drawer code and now it assumes that the alpha byte is always the last byte (if exists)
and the RGB part is simply copied to a color variable.

So here is the mapping:

  • 8 bit no alpha: do nothing
  • 8 bit alpha do nothing
  • 16 bit no alpha: swap the bytes
  • 16 bit alpha: swap the bytes and keep alpha on the last position
  • 32 bit no alpha: swap the color bytes: BGR->RGB
  • 32 bit alpha: swap the color bytes and keep alpha on the last position: BGRA->RGBA

I canā€™t test it on a big-endian device, but it should be good this way.

@Night
As quick hack you can modify the image files by replacing

#if LV_COLOR_DEPTH == 16 && LV_COLOR_16_SWAP != 0

with

#if LV_COLOR_DEPTH == 16 && LV_COLOR_16_SWAP

And similarly

#if LV_COLOR_DEPTH == 16 && LV_COLOR_16_SWAP

with

#if LV_COLOR_DEPTH == 16 && LV_COLOR_16_SWAP != 0
1 Like
34

Iā€™ve just pushed an experimental update to https://embeddedt.github.io/lv_img_conv/ with this feature added.

35

Right now the files are 100% identical if I hit the ā€œGenerate big-endian imageā€ button or not. Consequentialy colors are still wrong on the display.

36

:man_facepalming: I may have forgotten a step while adding the checkbox logic for the web interface; let me check.

37

The checkbox for the web was indeed a placebo. Sorry about that.

If you donā€™t mind, please give it another try when you have a chance. :slightly_smiling_face:

38

Now it works perfect with https://embeddedt.github.io/lv_img_conv/ :-). Thanks a lot!

Just for completion. It works also with the ā€œquick hackā€ from kisvegabor.

1 Like