Guru
Joined: 11/12/2012
Location: United KingdomPosts: 11174
| Posted: 06:55pm 14 May 2020 |
Images
In this post we will look at the pros and cons of the image formats supported by the CMM2: jpg, gif, png, and bmp
We will start by putting the CMM2 into MODE 2,16 i.e. 640x400 RGB565 and for testing purposes I have saved the same image in all 4 formats
File sizes are as follows
> list files "caja.*"
A:/
18:50 14-05-2020 768054 caja.bmp
18:50 14-05-2020 217064 caja.gif
18:49 14-05-2020 233823 caja.jpg
18:51 14-05-2020 506373 caja.png
0 directories, 4 files
>
A:/
18:50 14-05-2020 768054 caja.bmp
18:50 14-05-2020 217064 caja.gif
18:49 14-05-2020 233823 caja.jpg
18:51 14-05-2020 506373 caja.png
0 directories, 4 files
>
And times to load in milliseconds
> mode 2,16
> timer=0:load bmp "caja":?timer
541.699
> timer=0:load gif "caja":?timer
728.09
> timer=0:load jpg "caja":?timer
216.345
> timer=0:load png "caja":?timer
509.873
> timer=0:load bmp "caja":?timer
541.699
> timer=0:load gif "caja":?timer
728.09
> timer=0:load jpg "caja":?timer
216.345
> timer=0:load png "caja":?timer
509.873
So JPGs are small and load much faster than anything else. The reasons for this are twofold; first there is less data to read from the SDcard, second the STM32H743 includes a hardware jpg decoder so the CPU isn't used.
So we use jpgs for everything? perhaps not.....
There are two main downsides with the jpg format on the CMM2:
1. jpgs do not support transparency
2. jpgs cannot be bigger than the current display resolution. If we tried to load a 800x600 jpg while in MODE 2 we would get an error. This is because the hardware decoder uses information from the way we have set up the page in LTDC to determine how to decode the image. We would also get an error even with a 640x400 jpg if we tried to load it with an x,y offset other than 0
LOAD JPG file$ [, x, y]
One third limitation of the jpg support on the CMM2 is that it does not support progressive encoding. This is a technique that was developed for web use where a picture would appear fast but with low resolution and then the detail would "progressively" appear. This limitation is easily overcome by using any decent graphics program on your computer to save the image normally.
What about png files?
The only format to support transparency so the only choice in some applications
Reasonably fast to load
but:
1. Decoding png files eats memory. Even with 5MB available we cannot decode a 800x600 image so 640x400 is the biggest that can be practically supported
2. png cannot be bigger than the current display resolution. If we tried to load a 640x400 jpg while in MODE 3 we would get an error. We would also get an error even with a 320x200 png in mode 3 if we tried to load it with an x,y offset other than 0
3. The CMM2 only supports RGB888 and ARGB8888 formats - files are comparatively large
Next up gif files
The only format to support animations
GIF files can be bigger than the screen format or overlap the screen edge
GIF files are small
but:
1. slow
2. Only 256 colours used out of the palette of 65536
Finally bmp files
The safe option
BMP files image can be bigger than the screen format or overlap the screen edge
SAVE IMAGE saves BMP files
No practical limit on the image size, but of course only part of a very large image can be displayed.
but:
full-colour BMP files are 3 bytes per pixel + header i.e. large
A BMP image loads a line at a time from the bottom up which may not be what you want
I'll add to this post tomorrow and look at IMAGE RESIZE and IMAGE ROTATE
Edited 2020-05-15 05:05 by matherp