InfiniTimeOrg / InfiniTime

Firmware for Pinetime smartwatch written in C++ and based on FreeRTOS
GNU General Public License v3.0
2.63k stars 902 forks source link

lv_img_conv: support other modes like 'P' #1989

Closed NeroBurner closed 5 months ago

NeroBurner commented 5 months ago

Support other image modes like P, which uses 8 bits per pixel and a color palette to save space.

Luckily the Pillow module can do the mode conversion for us.

Fixes: https://github.com/InfiniTimeOrg/InfiniTime/issues/1985

NeroBurner commented 5 months ago

@ekirchman please review

github-actions[bot] commented 5 months ago
Build size and comparison to main: Section Size Difference
text 369768B -16B
data 940B 0B
bss 63516B 0B
ekirchman commented 5 months ago

Is there any reason we don't want to use try and handle each mode separately? GIMP and Gwenview can even can tell that these images have transparency to them. And at least before they're converted to RGBA, 'P' type images are smaller in file size than RGBA images

NeroBurner commented 5 months ago

CF_INDEXED_1_BIT is a special case, that is essentially a P image with just one bit, so a color palette with two colors, in our case hard coded to black and white https://github.com/InfiniTimeOrg/InfiniTime/blob/84e942555fbeb21a811920c83f355e70397a5071/src/resources/lv_img_conv.py#L141

Other than that I don't really know why we "only" have ARGB8565_RBSWAP and CF_INDEXED_1_BIT. I just converted the nodejs script to python because I was tired of the nodejs dependencies to break :sweat_smile:

You may look at the original javascript based lv_img_conv script here: https://github.com/lvgl/lv_img_conv

My guess is, that any binary format this script can produce is in some way usable by LVGL. Maybe only a subset of those are usable by PineTime, but I honestly don't know


In any case, I hope your original issue is resolved with this. If so please approve the PR :)

FintasticMan commented 5 months ago

The output is controlled entirely by the color_format and binary_format options, so converting the input shouldn't have any effect on the output. This means that you don't need to be concerned about the file size being bigger with the "RGBA" mode.