MicroPython Forum (Archive)

You'll probably want to use CPython and something like Pillow to read in an arbitrary image, decode it, rotate it, and colorspace convert it, then write out the python source.

There is a really easy way to do this. In the end what you want to achieve is to have a bock of memory(bytearray) that can be sent to the epaper screen via SPI that will display the image. The data will need to be 1 bit per pixel so 1 byte will hold the data for 8 pixels. The easist way to do this is with almost any common image editing software and edit the image till it is correct resoulution and in moncome 1 bit mode then save it as a BMP file (BMP format is without any compression and just straight image data). In your program just open this BMP file as a binary file then seek to position 55 (the fist 54 bytes are header bytes) Then just load the rest of the bytes into a buffer as is and send it to the epaper via SPI and bam the image will be there. There is some example of this at the waveshare wiki see at the bottom of https://www.waveshare.com/wiki/1.54inch_e-Paper_Module

As I understand it you want to load the binary data from a binary file then convert it to a py file so 1 byte of biniary data will be replaced by several bytes of text data in the py file e.g 3 bytes of biniary data of zeros will look like this in py text b'\x00\x00\x00' and require a total of 15 bytes to store in the py file then MicroPython has to load this file 5 times larger into memory and compile it back into the 3 bytes it represents.

It is much easier to have image data in a biniary file and just load it directly from file to memory.

Here is an example of me doing this with a TFT screen and text. I used Photoshop to create the correct resolution image and saved it as 16 bit image (the TFT is 16 bit colour not 1 bit colour like epaper). The font file I created the same way where the font is stored in the file as binary data.

https://www.youtube.com/watch?v=4OeWaat3jZs

dhylands wrote: ↑

Thu May 17, 2018 6:12 am

if your source PNG was an 24-bit-per-pixel image and you wanted a 1-bit-per-pixel PNG file.

@dhyands it is my understanding that PNG files are 32bit per pixel not 24bit per pixel like JPEG files as PNG format has 4 channels not 3 channels like most other images files

@OutoftheBOTS_ I agree with the one-bit BMP approach.

Alas rendering is not as simple as you suggest if the image being displayed is smaller than the screen. The contents of the file needs to be written to the correct locations in the framebuf, paying regard to the number of rows and columns in the bitmap. Things get more interesting if the start coordinates don't align with a byte boundary.

Examples may be found in my Writer class which renders 1-bit monochrome font glyphs onto a framebuf. In this instance the origin (top left corner) of the glyph's position on the display and the glyph's dimensions are arbitrary.

It's conceptually simplest to render graphics on a bit-by-bit basis as done here. It is slow, but then e-ink displays are. The faster way is bit blitting.

Thanks for the links pythoncoder, I will read over then later tonight.

Alas rendering is not as simple as you suggest if the image being displayed is smaller than the screen.

This is correct and I do have some routines to do this. But if you just want a simple approach then when you edit the image in the image editor (photoshop in my case) ensure it is the correct resolution by scaling or cropping then you can just dump from BMP file to screen memory via SPI and the image will appear

OK, I am now using mono-bitmaps and are able to convert the image to a bytearray using PIL (pillow.image).

I can also write the image (icon) to the screen at whatever position I require, but when I use the writer class to add text next to it, it appears to overwrite the icon, and vice versa.

But if I repeatedly issue the display_frame() function, then the page toggles between just the icon, and the text frames, it almost appears that there are 2 separate pages.

OutoftheBOTS_ wrote: ↑

Thu May 17, 2018 7:05 am

(the fist 54 bytes are header bytes)

Be careful with that, might be true in most of the cases but unfortunately not all. I know most Stackoverflow answers etc will tell you the same but it's basically wrong, see BMP standard, the safer way is to read the actual offset of the image (offset 10 in the header) and seek to that.

What "standard"? BMP is a huge pile of incompatible formats, there is no standard.

deshipu wrote: ↑

Thu May 17, 2018 12:40 pm

What "standard"? BMP is a huge pile of incompatible formats, there is no standard.

Which makes the 54 even more error prone I guess.

But you're right, my mistake, it's not a standard in the sense of 'ISO standard xxx'. Let's just call it 'the widely used BMP file format' then as described here for instance: https://en.wikipedia.org/wiki/BMP_file_format

stijn wrote: ↑

Thu May 17, 2018 1:28 pm

But you're right, my mistake, it's not a standard in the sense of 'ISO standard xxx'. Let's just call it 'the widely used BMP file format' then as described here for instance: https://en.wikipedia.org/wiki/BMP_file_format

Which of the 4 different formats described there?