Showing results for 
Search instead for 
Did you mean: 

Colour conversion issue STM32f429 L8 8BPP Mode

Andrew Stevenson
Associate II
Posted on August 17, 2017 at 18:07

Hello all,

I'm using the STM32F429 Discovery Kit and running the LTDC in 8 BPP (L8) mode. I have STemWin and am displaying their colour bar sample. I have a problem with colour conversion where the colour bars appear correct in the WIn32 simulator but are incorrect on the discovery kit.

For the simulator I have in LCDConf.c:



On the discovery I have:

&sharpdefine COLOR_CONVERSION_0 GUICC_323


In both cases I am using the default palette.

Can anyone advise me which of the other many colour conversions would be the correct one to use on the discovery so that the colours match the simulator?

Thank you,



#stm32cubef4-ltdc #lcd #stm32f429-discovery #color #stemwin
ST Employee
Posted on August 18, 2017 at 18:06


Could you be more precise regarding 'incorrect colors' ?

My point is that LTDC's L8 format is an indirect color format, either 8-bits luminance (greyscale only) or using a specific Look-up table (i.e. a different palette) but the color conversion you use in EmWin assumes that for each pixel you have 8 bits as : BBBGGRRR...


Posted on August 19, 2017 at 10:05

Ensure that you are using the same colour palette on your board and the PC. To save memory and calculation time, do the conversion on your PC using a picture editing software ( I use Gimp ). I created a image with an optimised colour palette (STM32_CLUT-L8_Palette.bmp) and a little C lib ( with exactly the same palette (and extended possibilities when using RGB888 or RGB565 instead of CLUT L8). Use the colour palette in Gimp to adjust your images to the palette or create a new image / icon / GUI element or whatever you need. Save the colour indexed images as a BMP to read them from SDcard or convert them to a C-file with BmpCvtDemo.exe included in STemWin. Within your CubeMX generated project, you can load the optimised Palette to the LTDC registers like this:

HAL_LTDC_ConfigCLUT(&hltdc, (uint32_t *)RGB_colours_getPaletteBGR32(), 256, 0);

HAL_LTDC_EnableCLUT(&hltdc, 0);

Now you can write to the framebuffer and create a Colour Bar test image ( STM32_CLUT-L8_colourbar.jpg ).

Read a indexed image from flash or SDcard and write it to the frame buffer to see the result (STM32_CLUT-L8_BMP.jpg ). It will look like viewed on the PC in Gimp.

Even at high resolutions, fluid animations are possible like seen in the last part of this video with a STM32F429i-Disco Board:

Except of the TFT resolution, we are doing the same thing on the STM32F429i-Disco.

Best regards,

Markus Horbach.


Attachments :

STM32_CLUT-L8_Palette.bmp :

STM32_CLUT-L8_colourbar.jpg : :

STM32_CLUT-L8_BMP.jpg :
Posted on August 21, 2017 at 19:19

Hi Markus,

Thank you very much for your reply once again. Please also see my comments to Nicolas earlier in the thread.

At this stage, it looks like something may be going wrong with the CLUT. I used the debugger to check that all 256 entries for the CLUT are being sent down and they are.

To test whether I could get the correct colours on the screen, I split the frame buffer up into five bands hoping to write from top to bottom the colours black, blue, green, blue and white. Note for this I am not using STemWin but just writing data straight into memory. This way I have complete control over what is going into the frame buffer.

According to the CLUT being sent down, the index values and their associated RGB values for this test are:

Index 0, RGB 0x000000 (Black)

Index 5, RGB 0x0000FF (Blue)

Index 30, RGB 0x00FF00 (Green)

Index 220, RGB 0xFF0000 (Red)

Index 255, RGB 0xFFFFFF (White)

The resulting image was as follows:


Of course, this is all assuming in L8 mode that the pixel format is D7 D6 D5 D4 D3 D2 D1 D0. I've not read anything in ST's data sheets to suggest it isn't that way.

It's interesting that you configure the CLUT before enabling it. The STemWin Hello World sample I am working off does it in the opposite order, it enables the CLUT then sends the values down. I believe the CLUT settings aren't being acted on because when I change the RGB value for say, index 0, to any other colour nothing changes on screen. Tomorrow, I will enable the CLUT after sending down the table and see if that makes any difference. 

Another question that occurred to me is whether putting the input pixel format to L8 changes anything on the parallel bus side such as number of lines, encoding of colour format, etc. My FAE is telling me that no changes need to be made to the configuration of the ILI9341 to accomodate the switch to L8 but perhaps this is something you could confirm? Presently, I have not changed the ILI9341 setup at all. 

Best Regards,


Posted on August 22, 2017 at 16:03

>It's interesting that you configure the CLUT before enabling it.

As far as i know, you can not configure the clut if it is busy converting the framebuffer to RGB colours aka draw the Screen.

>unsigned int *ptr_BGR32_Palette;

>Index 5, RGB 0x0000FF (Blue)

Please notice that the CLUT Needs 32 bit colour values in ABGR 32 bit Format, not RGB 24 bit.

This might be wrong and not enough Bytes to fill the whole CLUT completely resulting in wrong colours.

Did you use my RGB_colours Lib like recommended ?

>My FAE is telling me that no changes need to be made to the configuration of the

> ILI9341 to accomodate the switch to L8

The ili9341 is connected with 18 data lines on the STM32F429i-disco, you can use the LTDC with 18 or 16 bit mode.

With CLUT mode enabled, the 24 bit colour values are reduced to the selected Output by removing the lower unnecessary bits of each colour channel. The Ili9341 doesnt care because the LTDC is drawing the Image.

Best regards,


Thanks for big explain, but you reply to 6year old topic