1 bit depth BMP created with ImageMagick all black using GxEPD2

Correct, if your OS is 64bit, 64bit apps get installed in "/Program Files" and 32bit go in the "/Program Files (x86)" folder.

Woo-Hoo. This Win10 PC defaults to PowerShell which is horrible. I found cmd.exe and everything works nicely.

I have created some BMP files with different color depth. I get different values in the colorsimportant field e.g. 2, 16, 256

But the result is horrible.

I have a lot of learning to do.

IrfanView tends to do this stuff for you e.g. if you ask it to reduce to 16 colours it makes the "best possible" Palette and the end result looks good.


I'm executing this via a function in firebase, which has 'convert' available to the environment, so its not something I can do by hand.

this is the line that gets executed:

convert **from_filename.png** -filter point -resize "176x264>" -dither FloydSteinberg -define dither:diffusion-amount=85% -monochrome -colors 2 **output_filename.bmp**

I have made a safer calculation for MCUFRIEND_kbv examples:

        if (bmpDepth <= PALETTEDEPTH) {   // these modes have separate palette
            bmpFile.seek(bmpImageoffset - (4<<bmpDepth)); //54 for regular, diff for colorsimportant
            bitmask = 0xFF;

your edit would be:

        if (depth <= 8)
          if (depth < 8) bitmask >>= depth;
            file.seek(imageOffset - (4<<depth)); //54 for regular, diff for colorsimportant
          //file.seek(54); //palette is always @ 54

Thanks for your sample command. I am struggling with ImageMagick.
I have created tractor_1.bmp tractor_4.bmp tractor_8.bmp with ImageMagick
and created tractor_11.bmp tractor_44.bmp tractor_88.bmp with IrfanView

ImageMagick creates bigger headers on all 3 files. And creates a RLE bitmap for the 256-colour file.
My programs reject the RLE flag as an unsupported format.

I have attached a ZIP.


Edit. Added output6.bmp to ZIP. This was generated by Irfanview with Blue graphics and Cyan background.
Jean-Marc’s program should distinguish between the two colours i.e. Cyan->WHITE and Blue->BLACK

magick tractor10.jpg -depth 1 -colors 2 tractor_1.bmp
magick tractor10.jpg -depth 4 -colors 16 tractor_4.bmp
magick tractor10.jpg -depth 8 -colors 256 tractor_8.bmp

tractors.zip (76.2 KB)

What command are you using with imagemagick to create them?

Using the simple command produced rubbish BMP files.
Most importantly the 256-colour BMP defaults to using RLE8 compression (which I don’t support)
Not only does it produce RLE8 but the RLE8 files are bigger than uncompressed files!

I have improved my ImageMagick commands e.g.

magick convert tractor10.jpg -compress none -type palette -dither FloydSteinberg -colors 256 -depth 8 tractor_8.bmp

magick convert marilyn-monroe-9412123-1-402.jpg -resize 20% -compress none -type palette -dither FloydSteinberg -colors 2 -depth 1 marilyn_1.bmp

My original tractor JPEG is 276x182. I do not change the size
My original Marilyn JPEG is 1200x1200. I resize it to 240x240

If anything, ImageMagick seems to produce a slightly better monochrome than IrfanView.

Although there is a lot to learn, the command line ImageMagick is much more powerful than a GUI.

I don’t know whether you own a colour TFT e.g. to view all the BMP in colour.
I would like to know whether Jean-Marc’s sketch displays them on EPaper and how effectively.

You can obviously view the BMP files on the PC to see what they should look like.
256-colour Palette is very good.
16-colour Palette is surprisingly good.
2-colour Palette is as good as you can expect.


bitmaps2.zip (187 KB)

Version 1.2.2 of my library GxEPD2 is available.

  • fixed BMP handling, e.g. for BMPs created by ImageMagick

@rlightner, @david_prentice, thank you for your contributions.



What is your opinion of color BMP rendered on a monochrome EPaper ?

If I build a monochrome Palette e.g.

            for (col = 0; col < n; col++) {
                pos = read32(bmpFile);    //map palette to 5-6-5
                uint8_t r = (pos & 0xFF0000) >> 16;
                uint8_t g = (pos & 0x00FF00) >> 8;
                uint8_t b = (pos & 0x0000FF) >> 0;
                palette[col] = (r + g + b < 0x0180) ? 0x0000 : 0xFFFF;  //monochrome
                //palette[col] = tft.color565(r, g, b);  //regular color
                //palette[col] = ((pos & 0x0000F8) >> 3) | ((pos & 0x00FC00) >> 5) | ((pos & 0xF80000) >> 8);

The 16-color and 256-color BMPs look a bit bleached. Adjusting the 0x0180 threshold helps but is not as good as ImageMagick or IrfanView.

I presume that EPaper users will often want to create good monochrome.

Incidentally, a 16-Grayscale OLED looks pretty good. Much like my surprise with 16-color BMP.



What is your opinion of color BMP rendered on a monochrome EPaper ?

It is in any case a (bad) compromise. And it is even worse with 3-color e-paper, b/w/r or b/w/y.

I think it is preferable to have the user generate and adjust a b/w or 3-color BMP for his purpose.

But my BMP examples just should be able to render any BMP bitmap. I didn't experiment with thresholds, and the code may even be wrong, at least earlier versions were.

I didn't pay much attention testing your tractor bitmaps so far, they looked more or less the same. Maybe I take a second look tomorrow, and also at your bitmaps2, and on b/w/r e-paper.

Maybe I should mention that some SPI b/w e-paper displays can be used to show 4 grey levels, using a special waveform table and the fact that the "previous" and "new" buffer provide 2 bits per pixel, normally used for differential update. Parallel IF e-paper displays usually have 16 grey levels.