Development version for v9

[kisvegabor]

Hi @embeddedt,

In v9 the the name the usage of the color formats has been changed. Do you have a little bit of free time to add some minor modifications to the image converter and push it to a dev branch?

These are the new color format options_

• Native RGB (LV_COLOR_FORMAT_NATIVE): It's resolved to LV_COLOR_FORMAT_L8/RGB565/RGB888/XRGB8888 internally according to LV_COLOR_DEPTH. Same as LV_IMG_CF_TRUE_COLOR in v8.
• Native ARGB (LV_COLOR_FORMAT_NATIVE_WITH_ALPHA): It's resolved to LV_COLOR_FORMAT_AL88/RGB565A8/ARGB8888 internally according to LV_COLOR_DEPTH. Same as LV_IMG_CF_TRUE_COLOR_ALPHA in v8.
• LV_COLOR_FORMAT_RGB565_CHROMA_KEYED
• LV_COLOR_FORMAT_RGB888_CHROMA_KEYED
• There is no LV_COLOR_FORMAT_XRGB88888_CHROMA_KEYED as there ARGB8888 is a better option with the same size.
• Alpha 8 (LV_COLOR_FORMAT_A8): Alpha 1, 2 and 4 are removed
• Indexed 1/2/4/8 (LV_COLOR_FORMAT_I1/2/4/8)
• These color formats are included in Native RGB and Native ARGB but it'd be great to select them individually too:
  • LV_COLOR_FORMAT_L8
  • LV_COLOR_FORMAT_A8
  • LV_COLOR_FORMAT_AL88
  • LV_COLOR_FORMAT_RGB565
  • LV_COLOR_FORMAT_RGB565A8
  • LV_COLOR_FORMAT_RGB888
  • LV_COLOR_FORMAT_XRGB8888
  • LV_COLOR_FORMAT_ARGB8888

[embeddedt]

Sure, I can make these changes. To clarify, the main difference I'm seeing is that there are now options that expose each of the internal color formats (RGB565, RGB888, ARGB8888) which were previously not possible to set directly at all (they were simply forced based on the system's LV_COLOR_DEPTH).

As I understand it these types of previously internal options should now be possible to choose manually in addition to the automated selection via LV_COLOR_FORMAT_NATIVE. Is that correct?

I was also confused whether Native ARGB should be a top-level option to choose as well or if that was just included for the purposes of the explanation, since you mentioned "for ARGB images there is no common define which is resolved".

[kisvegabor]

Sure, I can make these changes.

Amazing, thank you!

As I understand it these types of previously internal options should now be possible to choose manually in addition to the automated selection via LV_COLOR_FORMAT_NATIVE. Is that correct?

Yes, it's correct 🙂

I was also confused whether Native ARGB should be a top-level option to choose as well or if that was just included for the purposes of the explanation, since you mentioned "for ARGB images there is no common define which is resolved".

In the weekend I was thinking about it and I found that actually we can add a LV_COLOR_FORMAT_NATIVE_WITH_ALPHA option which will be resolved to AL88, RGB565A8 or ARGB8888.

It means that we should have AL88 support too.
Note that L8 is the brightness of the pixel calculated as 0.2126*R + 0.7152*G + 0.0722*B.

I've added AL88 to the list.

[embeddedt]

I've pushed a WIP version of this to dev. It's turned out to be significantly more work than I anticipated, as I have been working on it slowly and the refactoring was also more extensive than I first understood. 😆

Current state of affairs:

• Most of the renames should be done (this was straightforward).
• There is no support for converting individual formats yet. The current converter logic was hardcoded to generate the special sub-formats when the top-level true color format is provided, so I need to think of a clean way to untangle that logic.
• The special LV_COLOR_FORMAT_XXX_CHROMA_KEYED options are not supported yet.
• I have not tested whether the resulting image actually compiles with LVGL v9.
• The web converter UI still uses the old color format names.

To test it it should be enough to checkout the dev branch and run npm start.

[kisvegabor]

Take your time! It'd help to test things, but not a blocking thing at thins moment. 🙂

I've tried out a few things and here i what I found:

• LV_IMG_PX_SIZE_ALPHA_BYTE was removed but I added _LV_COLOR_NATIVE_WITH_ALPHA_SIZE.
• In case of NATIVE_ALPHA 16 bit doesn't use the RGB565A8 format
• LV_COLOR_16_SWAP is also removed

[Viatorus]

Hello,

is there any update on this or what is the preferred way to generate images offline for v9?

[kisvegabor]

You can check out this Python script.

FYI, I've implemented a highly simplified version of the online converter for v9 here: https://lvgl.io/tools/imageconverter_v9

[itavero]

@kisvegabor Moving forward, will the Python script be the new tool to be used for converting images? Or will lv_img_conv still be the preferred approach?

We're building a new application now for which wanted to use the observer feature from LVGL v9, but we also want to add something to our build process to handle the conversion of the assets we need.
It's unclear now, in the long term, which option would be preferred (e.g. what's the roadmap/plan?).

[kisvegabor]

The Python script is recommended.

I keep lv_img_conv with a limited features set for novice users who prefer using the online converter. Once will be able to run the Python script online, lv_img_conv will be fully depreciated.

[itavero]

Thanks for the clarification. I'll see where I can place a feature request to get SVG support in the Python script.

As a side note, for fonts, lv_font_conv is still the preferred tool, right?

[kisvegabor]

Thanks for the clarification. I'll see where I can place a feature request to get SVG support in the Python script.

Just open an issue here

As a side note, for fonts, lv_font_conv is still the preferred tool, right?

Yes, it is.