Historically TouchGFX has provided support for 16-bit colors only (RGB565), as a way of reducing required memory for frame buffers and graphics assets and for speeding up the rendering of screens. With TouchGFX 4.5.0 we have introduced support for full 24-bit colors (RGB888) and this article will attempt to explain when to use 16-bit and when to use 24-bit colors in applications.
A note on supported platforms
The 24-bit format in TouchGFX is packed (i.e. it does not consume 32 bits per pixel). This frame buffer format is not supported by all TFT controllers. Notably the STM32F4/F7 TFT controllers does support this format, whereas the TFT controllers on NXP microcontrollers does not support this format. Meaning that for the latter, you can only use 16-bit colors with TouchGFX.
The 16-bit format
When TouchGFX is configured to run in 16-bit color mode it means that the frame buffers will have 16 bits of data per pixel. The graphical assets of the application (.png and .bmp files) are always in 24 bit colors, so the TouchGFX image converter will automatically convert these images to 16 bit as part of the code generation process during compilation. This conversion obviously results in the loss of some color information, but to alleviate this, the image converter applies a dithering algorithm which in practice makes it very difficult to tell that it is only 16-bit when the application is running. The benefits of 16-bit colors is that the amount of pixel data is reduced, and this has an impact on required RAM for frame buffers, required flash for graphics data and also the rendering time / frame rate, since the amount of data to transfer when drawing is smaller.
Weaknesses of 16-bit
While the dithering algorithm greatly helps, there are still cases when the visual result is not as good as 24-bit colors. The two main cases where there might be visual problems are:
- Bitmaps that contain highly detailed gradients of color
- Bitmaps where the alpha channel is a gradient
The 24-bit format
In the 24-bit format, the graphical assets are not dithered but rather displayed exactly as-is, without any modifications.
Weaknesses of 24-bit
The weaknesses of 24-bit colors are:
- Frame buffers and graphics data will take up 50% more space
- Rendering time will be longer due to increased amount of data. Rough estimate approx 25% increase.
The following screenshots show the same application running in 16 and 24 bit colors. The graphical assets used are 24-bit in both cases, with the 24-bit rendering thereby showing exactly the same as the input images.
How to decide on color format
The color format should never be of a higher resolution than what your display actually supports. So if your display is 16-bit, you should always choose this format. It is more common, however, to have an 18- or 24-bit color display. In this case, we still recommend sticking with 16-bit color format, for reasons of performance and memory footprint. In the vast majority of applications, you will not be able to see the difference visually. Only switch to 24-bit colors if you actually encounter something in your application that does not look good in 16-bit. We have tried to make it easy to switch between 16- and 24-bit, so moving your application to 24-bit does not require any changes to your UI code - it is merely a re-compilation (generation of assets) and some HAL code modifications to configure your TFT controller for 24bpp operation.
Enabling 24bpp colorsTouchGFX defaults to 16bpp colors. Please see this article for how to switch to 24bpp.