What type of hex code for rgb does tft.pushImage needs in the array

[ChrisSkyr]

I want to make a program that converts png and jpeg images to a file of an array of the pixels in hex but I do not know what type of rgb does it needs to display the correct colour

[resnbl]

I think the answer for you is "RGB565" - each pixel is 16 bits comprised of 5 RED bits, 6 GREEN bits and 5 BLUE bits. You probably also want these 16 bits encoded as "little endian" to avoid a swapBytes() call. Next question is whether to create this file from the top row down or bottom row up: probably depends on how you plan to feed them to TFT_eSPI.

BTW: if you have a copy of ffmpeg on your machine (who doesn't?), you may be able to use:
ffmpeg -vcodec png -i <infile.png> -vcodec rawvideo -f rawvideo -pix_fmt rgb565 <outfile.raw>
but I haven't tried this yet.

Maybe others can comment on how much of a performance gain there is between processing a, for example, .BMP file and reading one row at a time, converting RGB24 to RGB565, and passing each row to pushImage(x, y, w, 1, rowBuff) [see the TFT_SPIFFS_BMP example program], or possibly reading in a whole file at once and passing the buffer to a single pushImage(x, y, w, h, imageBuff) call.

The latter approach will require a considerably larger buffer(s) (whole file vs 1 row) which may blow out low-memory machines. Another issue is a pure raw "just pixels" file (like ffmpeg creates) won't have the image width and height meta-data included. This implies hard-coded values in your filename or code which is just ugly...

[resnbl]

I did some testing and here are my results. I created a simple 64x64 pixel image using Python/PIL and saved it out as both .png and .bmp. I used ffmpeg to convert the .png to R565 format which outputs the bytes in "little-endian" format I named *.lsb. I then used the online ImageConverter to create a file with the bytes output in "big-endian" format I named *.msb as well as a .c/.h file I included with the program. I then uploaded these files to the LittleFS partion on my device and displayed them on the screen and the results are:

Format	size	setSwapBytes()	time (ms)	code
.png	167	*	*	not tested
.bmp	12342	true	19	Bodmer's drawBmp()
.lsb	8192	true	17	single read and pushImage()
.msb	8192	false	14	single read and pushImage()
.h	8192	true	3	no FS I/O

Although the .png file is much smaller, I did not try the "experimental" decoder for it.

Note the .bmp data here is stored "bottom" to "top" which basically requires it being processed one row at a time as in the drawBmp() function.

The .msb and .lsb files are 1/3 smaller than .bmp as well as faster to load. However, a full-screen 320 x 170 background image loaded in this manner would require a 108,800 byte buffer to read it in as a single operation, which is probably not going to work well.

One additional note: the timings above are with a LittleFS image containing more than 65 files. I retested with only the necessary 3 files and the times improved by more than 6 milliseconds. I'm not impressed with the read times for LittleFS.

My conclusion is that for smaller images, reading a custom format R565 file with a single operation may be worth my time to create a custom program for. (I would probaby add a few bytes of meta-data at the beginning: the width and height at a minimum.) But for larger images, the custom format may save SD/Flash space, but it will still need to be read in in smaller chunks to avoid memory issues. Note that the difference in load times is only a few milliseconds and may, or may not, be significant in a given application.

Of course, if program memory size is not an issue, creating a .c/.h file and including it is fastest.