{"id":4233,"date":"2020-08-19T20:00:41","date_gmt":"2020-08-19T18:00:41","guid":{"rendered":"https:\/\/msalamon.pl\/?p=4233"},"modified":"2025-12-27T16:17:52","modified_gmt":"2025-12-27T15:17:52","slug":"how-to-prepare-an-image-for-an-lcd-or-tft-display","status":"publish","type":"post","link":"https:\/\/msalamon.pl\/en\/how-to-prepare-an-image-for-an-lcd-or-tft-display\/","title":{"rendered":"How to Prepare an Image for an LCD or TFT Display?"},"content":{"rendered":"\n

When working with various graphic displays, you will almost certainly reach a moment when you need some graphics to display. After all, that\u2019s why we pick such a display<\/a>\u2014to show some icons or other bitmaps on it. Alright, but can we just drop a BMP or JPEG file into our microcontroller? Well, no! So how do we deal with such graphics? What should we use? I\u2019ll show you right away \ud83d\ude42<\/p>\n\n\n\n\n\n\n

\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

Table of contents for the entire SSD1327 OLED series:<\/strong><\/span><\/p>\n\n\n\n

Grayscale OLED on SSD1327 part 1<\/a>
<\/strong>Grayscale OLED on SSD1327 part 2<\/a>
<\/strong>How to prepare an image for an LCD or TFT display?<\/a>
<\/strong>Grayscale OLED on SSD1327 part 3<\/a><\/strong><\/p>\n\n\n\n

Image representation in a microcontroller<\/h1>\n\n\n\n

When putting an image into a microcontroller, you need to prepare it beforehand. Usually, such graphics take up quite a bit of space, so we store them in the microcontroller\u2019s Flash memory. To put something into Flash on STM32, it\u2019s enough to add the const<\/em> specifier to a variable or an array. The compiler will automatically place these variables in the Flash memory area. Simple, right?<\/p>\n\n\n\n

Ok, so you\u2019ve probably already figured out that we\u2019ll use variables to store images. Not single variables, but whole arrays. How are they built? We need to think about what an image actually is.<\/p>\n\n\n\n

Let\u2019s take a closer look at monochrome images, like the ones used on simple OLED displays<\/a>. One pixel can have two colors\u2014black or white. To store a single pixel, we really only need one bit. If we want an image for the whole OLED<\/a>, say 128\u00d764 px, then we need information about 8192 pixels. We would need 8192 variables indicating the color of each pixel.<\/p>\n\n\n\n

Not exactly. Since one pixel = one bit, why not pack it? After all, bytes can hold up to 8 bits. That\u2019s exactly what you do! Thanks to this, one 128\u00d764 px image takes \u201conly\u201d 1024 bytes.<\/p>\n\n\n\n

Which byte for which pixel?<\/h2>\n\n\n\n

The organization of pixels in such an array is extremely important. I usually stick to this convention of numbering pixels on displays. This organization is most often forced by the memory organization in the display. It\u2019s easier to do calculations for a single pixel and then send the whole array in bulk without extra tricks.<\/p>\n\n\n

\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

That\u2019s exactly how I number pixels on the display. Now how do we arrange this in an array? The same way as in the buffer for an OLED<\/a>! The first byte covers pixels in the first row (0,0) to (7,0), the second from (8,0) to (15,0), etc.<\/p>\n\n\n\n

The second line, i.e. Y=1, starts at byte (127\/8)+1, which is byte no. 16 in the array. Let\u2019s try to write an equation that selects the exact byte in the buffer.<\/p>\n\n\n\n

First X. The next byte in the buffer changes every 8 X\u2019s, i.e. image[(x\/8)]<\/strong>.<\/p>\n\n\n\n

Now Y. With each next line we jump forward by (resolution in X \/ 8) times the number of vertical lines, i.e. [Y*(LCDWIDTH\/8)].<\/p>\n\n\n\n

Now the depth in X and in Y must be added together. This gives us the byte selection as image[(x\/8) + (Y*(LCDWIDTH\/8))]<\/strong>.<\/p>\n\n\n\n

We found the correct byte. Now within that byte we have as many as 8 pixels. Which ones? The X\u2019s! Where will the least significant pixel in the byte be? In the most significant bit position of the byte, i.e. \u201creversed\u201d. So how do we find the value of that single pixel? Use a mask.<\/p>\n\n\n\n

For the zero-th pixel we need the MSB, so the mask will look like this\u20140x80 (0b10000000). For the second pixel it will be 0x40 (0b01000000). The third 0x20 (0b00100000). Do you see the relationship? The 1 moves to the pixel position counted from the left. So you just shift it by the pixel number. But wait! We have points 8-15. How do we use them?<\/p>\n\n\n\n

We\u2019ll need to use the remainder from division, i.e. modulo. We\u2019ll divide X, because that\u2019s where we need this information. By what do we divide? By 8.<\/p>\n\n\n\n

In the end, the color of a single pixel is (image[(x\/8) + (Y*(LCDWIDTH\/8))] & (0x80 >> (X%8))<\/strong>.<\/p>\n\n\n\n

That\u2019s a pretty complicated construct. For color displays<\/a>, where one byte = one color component of a pixel, it\u2019s a bit easier \ud83d\ude42 Or one pixel = 2 bytes, because a common color layout is RGB565. Then each next byte for X\u2019s is X*2,<\/strong> and a line has LCDWIDTH*2<\/strong> bytes. There\u2019s no division and modulo then, but you have to fight with proper shifting of colors so they fit correctly into those two bytes.<\/p>\n\n\n\n

Creating images \u2013 Image2Lcd<\/h2>\n\n\n\n

So how do we create the proper array from a BMP? By hand? Of course not! There are various programs for this, and I most often use the free Image2Lcd<\/strong>.<\/p>\n\n\n\n

The program is already quite old and you have to search around the Internet for it, because many links are dead. You can download this program together with the key here.<\/strong><\/a><\/p>\n\n\n\n

After installation, the program looks like it was written 10 years ago \ud83d\ude42<\/p>\n\n\n

\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

Everything you\u2019re interested in is basically on the left side.<\/p>\n\n\n\n

Output file type<\/strong> decides what the output file of the processed image will be. For an MCU, we\u2019re interested in C array (*.c)<\/em>, which we add to our project with source files, and Binary(*.bin)<\/em>, which we can put e.g. on a memory card.<\/p>\n\n\n\n

Scan mode<\/strong> sets the order and arrangement of subsequent bytes. This is what I wrote about above when arranging bytes. There\u2019s helpful guidance here in the form of a drawing of these bytes, with MSB (red) and LSC (blue) marked. What I use most often is Horizontal Scan<\/em>, but not always. For example, the default arrangement of bytes in the RAM memory of an OLED<\/a> with an SSD1306 controller is Data hor,Byte ver<\/em>. That\u2019s also how I have the RAM buffer arranged for these OLEDs<\/a>.<\/p>\n\n\n\n

BitsPixel<\/strong> determines the number of colors per pixel. Monochrome<\/strong> is what we care about for a regular OLED<\/a>. 4 colors is 2 bits, 16 colors 4 bits, 256 colors\u20148 bits, 4096 colors\u201412 bits, and then the more clearly labeled 16, 24, and 32 bits per pixel. What\u2019s important here is that pixels will be packed by default, so it\u2019s exactly what we want e.g. for monochrome.<\/p>\n\n\n\n

Max Width and<\/strong> Height<\/strong> lets us reduce the image we convert. Instead of resizing the source image, you can just limit it here.<\/p>\n\n\n\n

Next there are a few checkboxes. The first one is used to include a header with, among other things, the image size into the whole array. The first 6 bytes then are exactly this header.<\/p>\n\n\n\n

The next 3 checkboxes change the byte scan order and swap MSB and LSB within individual bytes.<\/p>\n\n\n\n

The last checkbox MSB First<\/strong> is useful when a pixel has more than 1 byte, like in color formats. Then we can decide the order of those bytes.<\/p>\n\n\n\n

How Image2Lcd works<\/h2>\n\n\n\n

How do we create an image for a microcontroller? We open any file via Open<\/strong>. Let\u2019s take my logo. It can be color.<\/p>\n\n\n

\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

On the left side I set the output as a C file, mono image, because I have a mono OLED<\/a> at hand, and I limited the width to 128 pixels. Automatically, the source preview (left) and the resulting image preview (right) were reduced to that size.<\/p>\n\n\n\n

At the bottom you have sliders. Depending on what final color format you want, you use the appropriate tab. I increased contrast and brightness so the characteristic elements of my logo stand out.<\/p>\n\n\n\n

But heeey! What is that watermark?! Exactly. You must remember to enter the registration key. This program used to be paid, but after it got old, the key was made available and it\u2019s free \ud83d\ude42<\/p>\n\n\n\n

You register in the bottom right in the Register<\/strong> tab. The key is in the package with the program.<\/p>\n\n\n\n

Now it\u2019s without the watermark. I noticed that sometimes the registration is not remembered and you have to do it again<\/strong>, so keep the key somewhere in your notes.<\/p>\n\n\n

\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

Now, when you save the file using the Save<\/strong> button, you\u2019ll get the converted *.C file. It looks like this.<\/p>\n\n\n\n

const unsigned char gImage_image[608] = { \/* 0X00,0X01,0X80,0X00,0X26,0X00, *\/\n0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0X05,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0X00,0XFE,0X40,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0X00,0X6F,0X80,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0X29,0XC7,0X80,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0X07,0X9B,0XC8,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0X03,0X3D,0XF0,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X01,0X4E,0X7E,0XF0,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0X3C,0XFF,0X79,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0X19,0XFF,0XBE,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X08,0X73,0XFF,0XDE,0X40,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0XE7,0XFF,0XEF,0X80,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0XCF,0XFF,0XF7,0X80,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X43,0X98,0XFE,0X3B,0XC8,0X00,0X00,0X00,0X0C,0X00,0X00,0X00,0X00,0X00,0X01,0X80,\n0X4F,0X30,0XC4,0X1D,0XF0,0X00,0X00,0X00,0X0C,0X00,0X00,0X00,0X00,0X00,0X01,0X80,\n0X26,0X70,0X00,0X1E,0XF0,0X00,0X60,0X00,0X0C,0X00,0X01,0X80,0X00,0X00,0XD1,0X80,\n0X1C,0XF0,0X02,0X1F,0X78,0X76,0XF3,0XC7,0XCC,0X7D,0XDB,0XC7,0X9F,0X81,0XF9,0X80,\n0X39,0XF0,0X42,0X1F,0XB8,0X7F,0X76,0X6C,0XCC,0XCD,0XFD,0XCD,0X9F,0X81,0XD9,0X80,\n0X33,0XF0,0XC2,0X1F,0XD8,0X77,0X77,0X00,0XCC,0X0D,0XDD,0XDD,0XDD,0XC1,0X99,0X80,\n0X33,0XF0,0XC2,0X1F,0XD8,0X77,0X73,0XC7,0XCC,0X7D,0XDD,0XD9,0X99,0X81,0X99,0X80,\n0X39,0XF0,0XC2,0X1F,0XB8,0X77,0X61,0XCC,0XCC,0XCC,0XDD,0XDD,0X99,0X81,0X99,0X80,\n0X1C,0XF0,0XC6,0X1F,0X78,0X36,0X64,0XEC,0XCC,0XCC,0XD9,0X9D,0X99,0X9D,0XB1,0X80,\n0X3E,0X78,0X86,0X1E,0XE0,0X36,0X67,0XC7,0XCC,0X78,0XD9,0X8F,0X19,0X9D,0XE1,0X80,\n0X0F,0X38,0X86,0X1D,0XF0,0X00,0X01,0X00,0X0C,0X00,0X00,0X00,0X00,0X01,0X81,0X80,\n0X07,0X9F,0XFC,0X3B,0XC8,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X01,0X80,0X00,\n0X03,0XCF,0XFF,0XF7,0X40,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X01,0X80,0X00,\n0X01,0XE7,0XFF,0XEF,0XA0,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X0A,0XF3,0XFF,0XDE,0X40,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0X79,0XFF,0XBA,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0X3C,0XFF,0X79,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X01,0X4E,0X7E,0XF0,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0X0F,0X3D,0XD0,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0X07,0X9B,0XC8,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0X29,0XC7,0X80,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0X01,0XEE,0X80,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0X00,0XFE,0X40,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0X05,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n0X00,0X02,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,\n};\n<\/pre>\n\n\n\n
The first thing I do is change the variable type to uint8_t and remove the gImage_ prefix from the array. That\u2019s how I like it.<\/p>\n\n\n\n
const uuint8_t image[608] = { \/* 0X00,0X01,0X80,0X00,0X26,0X00, *\/<\/pre>\n\n\n\n
The file is 608 bytes. What size is the image? We can either check it in the program.<\/p>\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n
You can also do it better. You can tick Include head data<\/strong> and have it in our image array. Thanks to this we can write code in such a way that it checks the dimensions by itself. If you don\u2019t tick it, then the header is still in the array, but commented out.<\/p>\n\n\n\n
const uint8_t image[608] = { \/* 0X00,0X01,0X80,0X00,0X26,0X00, *\/<\/pre>\n\n\n\n
These 6 bytes are \/* 0X00,<\/strong>0X01,0X80,0X00,0X26,0X00, *\/ \u2013 is MSB first \u2013 NO. This affects the byte order in the image dimensions!<\/p>\n\n\n\n
\/* 0X00,0X01,<\/strong>0X80,0X00,0X26,0X00, *\/ \u2013 bits per pixel = 1<\/p>\n\n\n\n
\/* 0X00,0X01,0X80,0X00,<\/strong>0X26,0X00, *\/ \u2013 pixels horizontally \u2013 0x0080 = 128<\/p>\n\n\n\n
\/* 0X00,0X01,0X80,0X00,0X26,0X00,<\/strong> *\/ \u2013 pixels vertically \u2013 0x0026 = 38<\/p>\n\n\n\n
You can already use such an array in your project. It works similarly with color images.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
As you can see, creating an image for a microcontroller is a piece of cake! Why search and reinvent the wheel when you could have asked me how to do it \ud83d\ude42<\/p>\n\n\n\n
Now you just need to generate it, put it into Flash, and display your graphics. The only thing missing is some kind of compression like RLE. I use it incredibly rarely myself, so I don\u2019t have a solution for this problem at the moment. If there\u2019s a need, I\u2019ll look for something.<\/p>\n\n\n\n
If you liked the article, buy something from me! \ud83d\ude42 https:\/\/sklep.msalamon.pl\/<\/a><\/strong><\/p>\n\n\n\n
If you noticed an error, disagree with something, would like to add something important, or simply feel like you\u2019d like to discuss this topic, write a comment. Remember that the discussion should be polite and compliant with the rules of the Polish language.<\/span><\/p>\n\n\n\n
Table of contents for the entire SSD1327 OLED series:<\/strong><\/span><\/p>\n\n\n\n
Grayscale OLED on SSD1327 part 1<\/a>
<\/strong>Grayscale OLED on SSD1327 part 2<\/a>
<\/strong>How to prepare an image for an LCD or TFT display?<\/a>
<\/strong>Grayscale OLED on SSD1327 part 3<\/a><\/strong><\/p>\n\n\n
\n            \n
\n    \n
\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n    <\/div>\n    \n
\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n    <\/div>\n<\/div>\n                \n\n
\n            <\/span>\n    <\/div>\n    <\/div>\n","protected":false},"excerpt":{"rendered":"
When working with various graphic displays, you will almost certainly reach a moment when you need some graphics to display. After all, that\u2019s why we pick such a display\u2014to show some icons or other bitmaps on it. Alright, but can we just drop a BMP or JPEG file into our […]<\/p>\n","protected":false},"author":1,"featured_media":3485,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_links_to":"","_links_to_target":""},"categories":[160],"tags":[176,174],"class_list":["post-4233","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-stm32","tag-programming","tag-stm32"],"_links":{"self":[{"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/posts\/4233","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/comments?post=4233"}],"version-history":[{"count":3,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/posts\/4233\/revisions"}],"predecessor-version":[{"id":4236,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/posts\/4233\/revisions\/4236"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/media\/3485"}],"wp:attachment":[{"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/media?parent=4233"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/categories?post=4233"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/tags?post=4233"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}