lv_img_conv: support other modes like 'P'

[NeroBurner]

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: #1985

[NeroBurner]

@ekirchman please review

[github-actions]

Build size and comparison to main:

Section	Size	Difference
text	369768B	-16B
data	940B	0B
bss	63516B	0B

[FintasticMan]

Looks good to me!

[ekirchman]

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]

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

InfiniTime/src/resources/lv_img_conv.py

Line 141 in 84e9425

elif args.color_format == "CF_INDEXED_1_BIT": # ignore binary format, use color format as binary format

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 😅

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]

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.

[ekirchman]

I agree with @FintasticMan that due to the color format being the same the file size shouldn't different if at all