GxEPD2 - Yellow tint displaying fullsize dithered images on GDEY073D46

Other Hardware Displays
1

Hi

I have been succesfully runnning the "GxEPD2_WiFi_Example.ino" from the (awesome) "GxEPD2" library examples using the 5.65 inch Eink 7-color display from waveshare to display photographs (reduced to the 7 color palette with imagemagik using dithering).

However, recently I got my hands on its bigger brother, the GDEY073D46 7.3 inch 800x480 7-color and was exicted to get it up and running.

Now comes the strange part:

  • Small solid color example images (600x448) look good
  • Small dithered example images (600x448) look good
  • Large solid color example images (800x480) look good
  • Large dithered example images (800x480) look awful. They have muted colors and a yellowish tint.

Here are some screenshots I took (with fixed-white balance):

7_3_cropped
7_3_cropped1920×1440 286 KB

7_3_full
7_3_full1920×1440 288 KB

The issue can be reproduced by just resizing one of the example images used in "GxEPD2_WiFi_Example.ino" sketch to 800x480, uploading it to a (local) webserver and displaying it

And here is my setup:

Hardware

  • ESP32 Lolin D32 pro
  • Waveshare 7.3inch e-Paper HAT
  • GDEY073D46 7.3 inch 800x480 7-color Eink display
  • VIN of e-Paper HAT attached to 3v pin from ESP32

Software

  • Arduino IDE 1.8.19
  • GxEPD2 Library Version 1.52
  • "GxEPD2_WiFi_Example" from library examples (w/ modified image url)

Links

What I tried

  • Tried supplying 3.3v from a separate power supply (with some extrac capacitors for good measure) instead of the ESP32 3.3v pin, but no success
  • Switching lolin D32 board with another dev board, but no success
  • Made the code changes for the "clever reset circuit" suggested by @ZinggJM, but no success

Did anybody here have similar experiences?
Or might this just be a bad batch of eink display or e-Paper hat?

What I noticed, is that on the original github repo from waveshare, there are no full size (800x480) and dithered example images, only one or the other... Maybe the display is not even cabable of displaying those and it was just omitted there to cover up the fact?

2

@dechrigi118, Hi, welcome to the forum!

There are some points to consider:

  • the panel waveshare uses may be different than the panel I have from Good Display
  • the waveform table is in OTP memory of the controller
  • the refresh time may be different, because of different waveform tables

Therefore we need to find out if the issue is caused by refresh timeout(s).

Please post diagnostic output from Serial Monitor.

Jean-Marc

3

Hi Jean-Marc

Hi, welcome to the forum!

Thank you!

Therefore we need to find out if the issue is caused by refresh timeout(s).
Please post diagnostic output from Serial Monitor.

Ok, I see. Below is the output for the serial monitor with diagnostics enabled (which is just calling display.init method with an serial_diag_bitrate if I understand correctly):

Christian

P.s: Sorry while posting those serial outputs, I realized that I was somewhat vague/unprecise in describing the pictures displayed my first post - While the small pictures (that display correctly) are 640x448 actual 'colored' pixels, they are then padded with white pixels in the BMP to fill the whole 800x480.

Small dithered example images (600x448 filled with actual image pixels, the rest is just padded white pixels) from above post which display correctly:

downloading file "photoframe_image_0001.bmp"
_PowerOn : 171999

connecting to 192.168.0.42
requesting URL: http://192.168.0.42/testimages_7_3/photoframe_image_0001.bmp
request sent
HTTP/1.1 200 OK
headers received
File size: 192118
Image Offset: 118
Header size: 40
Bit Depth: 4
Image size: 800x480
bytes read 192118
loaded in 15738 ms

connecting to 192.168.0.42
requesting URL: http://192.168.0.42/testimages_7_3/photoframe_image_0001.bmp
request sent
HTTP/1.1 200 OK
headers received
File size: 192118
Image Offset: 118
Header size: 40
Bit Depth: 4
Image size: 800x480
bytes read 192118
loaded in 14464 ms

connecting to 192.168.0.42
requesting URL: http://192.168.0.42/testimages_7_3/photoframe_image_0001.bmp
request sent
HTTP/1.1 200 OK
headers received
File size: 192118
Image Offset: 118
Header size: 40
Bit Depth: 4
Image size: 800x480
bytes read 192118
loaded in 14417 ms

_Update_Full : 35250999
_PowerOff : 144999

Large dithered example images (all 800x480 are filled with actual image pixels) from above post which has muted colors and yellow tint:

downloading file "photoframe_image_0002.bmp"
_PowerOn : 171999

connecting to 192.168.0.42
requesting URL: http://192.168.0.42/testimages_7_3/photoframe_image_0002.bmp
request sent
HTTP/1.1 200 OK
headers received
File size: 192118
Image Offset: 118
Header size: 40
Bit Depth: 4
Image size: 800x480
bytes read 192118
loaded in 14426 ms

connecting to 192.168.0.42
requesting URL: http://192.168.0.42/testimages_7_3/photoframe_image_0002.bmp
request sent
HTTP/1.1 200 OK
headers received
File size: 192118
Image Offset: 118
Header size: 40
Bit Depth: 4
Image size: 800x480
bytes read 192118
loaded in 14441 ms

connecting to 192.168.0.42
requesting URL: http://192.168.0.42/testimages_7_3/photoframe_image_0002.bmp
request sent
HTTP/1.1 200 OK
headers received
File size: 192118
Image Offset: 118
Header size: 40
Bit Depth: 4
Image size: 800x480
bytes read 192118
loaded in 14430 ms

_Update_Full : 35256999
_PowerOff : 144999
4

If it helps to pinpoint the issue, here is the large image (that displays with the yellowish tint) that was used for the second image taken in the first post:

5in65f3_resized
5in65f3_resized800×480 281 KB

I had to convert it to JPG first to upload it here though, since the forum does not accept uploading BMPs :slight_smile:

5

Hi Christian,

Thank you for the additional information!

The diagnostic output shows normal refresh times. Close to the time I measured with my panel.
And it confirms that a palette is used: Bit Depth: 4.

I think the issue is with the color discriminator used in GxEPD2. My attempt into this unknown field certainly is suboptimal. But it works with the pictures from Waveshare.

Could you provide the numeric color values used in this palette?
Could you provide the unconverted BMP file, maybe in a zip-file?

See also GxEPD2.h for the primary colors used by GxEPD2:

// color definitions for GxEPD, GxEPD2 and GxEPD_HD, values correspond to RGB565 values for TFTs
#define GxEPD_BLACK     0x0000
#define GxEPD_WHITE     0xFFFF
// some controllers for b/w EPDs support grey levels
#define GxEPD_DARKGREY  0x7BEF // 128, 128, 128
#define GxEPD_LIGHTGREY 0xC618 // 192, 192, 192
// values for 3-color or 7-color EPDs
#define GxEPD_RED       0xF800 // 255,   0,   0
#define GxEPD_YELLOW    0xFFE0 // 255, 255,   0 !!no longer same as GxEPD_RED!!
#define GxEPD_COLORED   GxEPD_RED
// values for 7-color EPDs only
#define GxEPD_BLUE      0x001F //   0,   0, 255
#define GxEPD_GREEN     0x07E0 //   0, 255,   0
#define GxEPD_ORANGE    0xFC00 // 255, 128,   0

GxEPD_ORANGE may be the issue, I had to use this value for the Waveshare pictures.

6

Hi Jean-Marc

The diagnostic output shows normal refresh times. Close to the time I measured with my panel.

Ok, that's good to know

I think the issue is with the color discriminator used in GxEPD2. My attempt into this unknown field certainly is suboptimal. But it works with the pictures from Waveshare.

Could you provide the numeric color values used in this palette?

Good point, I actually tinkered with the palette used for dithering for a while back when using the smaller 5'65 color eink in order to get nicer greens and blues. And after I adjusted the color palette to a better representation of the acutal colors displayed on the eink, I was forced to re-write part of the "color7" function in GxEPD2_7C.h (using a conversion to HSV color space) for it to still properly recognize the correct palette colors.

That actually worked pretty well, but I already reverted all those changes now for troubleshooting purposes and am again using the "canonical" palette with the following RGB values:

         0: (  0,  0,  0) #000000 black
         1: (255,  0,  0) #FF0000 red
         2: (  0,255,  0) #00FF00 lime
         3: (255,128,  0) #FF8000 srgb(255,128,0)
         4: (255,255,  0) #FFFF00 yellow
         5: (  0,  0,255) #0000FF blue
         6: (255,255,255) #FFFFFF white

They seem to align nicely with the ones you posted above...

Could you provide the unconverted BMP file, maybe in a zip-file?

Of course - I should have though of that

I was not allowed to upload a zip to the forum because I am a new user, so here is a google drive link instead

When looking at the BMPs you might notice that I decided to switch to a different example image.

Due to it beeing more colorful, it shows the effect mentioned in the first post even better. Also the smaller, padded image is now only 400x240 pixels as I noticed that enhances the effect even further.

Here are some shots I captured with my DSLR (again fixed white balance etc.)

Small image size 400x240 and then padded to 800x480

camera_shot_small_but_padded_image
camera_shot_small_but_padded_image1920×1280 162 KB

Same source image data on full size 800x480

camera_shot_large_image
camera_shot_large_image1920×1280 326 KB

Beside the BMP files, the zip file also contains:

  • the actual source image used for creating the BMPs
  • a ready to run shell script which converts the source BMP using imagemagick (confirmed to run on linux, although the image magick conversion command themself will probably also run on windows)

I first suspected that the exported BMP color palette or image data might somehow be affected by the white padding, but looking at the statistics imagemagick gives me on the converted images, I couldn't see how...

image
image888×354 77.1 KB

Also this whole process worked without any issues for my old 5.65 inch 7 color eink, so I'm really stumped at this point...

Thanks again for taking a look at this and have a nice evening!
Christian

7

FYI: my latest reply was now just hidden by the forum's auto-spam bot - don't really know why, but I hope I'll wont take until after the weekend :roll_eyes:

Update: The post was reviewed and is now visible again

8

Your picture looks good on my panel.

DSC00663a
DSC00663a1288×966 448 KB

Maybe your supply is too weak. Check if VIN is for 3.3V or 5V.
I use the connection module from Good Display.

https://www.waveshare.com/w/upload/0/0c/7.3inch_e-Paper_HAT.pdf

You can connect VCC to 5V. But you need to use a series resistor (10k) or voltage divider then to protect your ESP32, from the output of the level converter, for the BUSY line.

9

Nice! Thats great to hear, that means I can at least rule out any image conversion issue

Maybe your supply is too weak.

That would make alot of sense. I noticed in the the datasheet of the panel it mentions the maximum power consumption being displaying noise of all 7 colors, which is very similar to my full screen dithered images...

(https://www.waveshare.com/w/upload/d/db/7.3inch_e-Paper_(F)_Specification.pdf)

image
image1116×1279 289 KB

Check if VIN is for 3.3V or 5V.

The "jetson nano" section in wiki at waveshare (https://www.waveshare.com/wiki/7.3inch_e-Paper_HAT_(F)_Manual#Working_With_Jetson_Nano) implied it should work with 3.3v as well, but maybe that claim is to taken with a grain of salt....

You can connect VCC to 5V. But you need to use a series resistor (10k) or voltage divider then to protect your ESP32, from the output of the level converter, for the BUSY line.

Thanks for the suggestion. I tried that this afternoon (both level shifter and 10k in series) but unfortunatly this resulted in random garbage in the image (Also I had to add a capacitor to the 5v power rail, to prevent the wifi connection failing on the esp32)

issues_5v
issues_5v1920×1440 305 KB

My guess would guess that the SPI communication is somewhat unstable properly because of the voltage level differences, would you agree? I have some 3v-5v level shifters laying around somewhere and will give that a try asap.

I use the connection module from Good Display.

That would be the DESPI-C73, correct? Are those interchangable, i.e. would it makes sense to try swapping mine with one of those?

10

Yes, that would make sense for use with 3.3V processors. But the DESPI-C73 isn't available separately, to my knowledge. But you could ask; I was successful with asking for the DESPI-C01, which later was succeeded with the DESPI-C02.

I would expect the level converter connected to 5V would work with 3.3V logic signals.
You should avoid to have two level converters in series, as these sense which side is the driving side, and would get confused.

11

I would expect the level converter connected to 5V would work with 3.3V logic signals.

I agree it should. Maybe the 5v power supply was to blame - I'll give it a go with a different 5v power supply as a next step then. I actually just took the 5v from the VIN pin from the esp32 dev board, maybe that caused the issues

You should avoid to have two level converters in series, as these sense which side is the driving side, and would get confused.

Ah, good point

Also, since my main suspect currently seems to be the waveshare 7.3 e paper hat, I'll try to get my hands on a DESPI-C73 and then report back

12

Ok so here is the update. I got my hands on a DESPI-C73 adapter from Good Display (https://buy-lcd.com/products/epaper-hat-connection-adapter-board-for-073-inch-e-ink-display-despi-c73-648) and hooked it up - Same eink panel, same esp32 dev board, same code, same voltage (3v pin of esp32) and same usb power supply - and it justed works flawlessly now

No more green/yellow tint - instead crisp and fully saturated colors.

with-DESPI-C73-adapter
with-DESPI-C73-adapter1920×1280 305 KB

So all things considered, using the Waveshare 7.3 e-Paper HAT seemed to be the one and only issue here.

After replacing it with the DESPI-C73 adapter from GoodDisplay, fullscreen images with dithered colors are now displaying correcly when powered with 3v

Before the DESPI-C73 arrived, I tried various setups powering it with 5v, since all the symptoms really did point to a issue with the power supply, but none of them helped.

There where some issues getting a error free communication going with the 3v mcu and the 5v eink vin supply, but even after solving them, and trying multiple power supplies (from different USB Chargers to Lab Power Supply, powering mcu and eink together or seperatly, even powering the esp32 and eink with the maximum allowed voltage of 3.6v) the color of the displayed image sadly still had that yellow/green tint...

I also measure the output of the RT9193-33 linear voltage regulator built into the Waveshare 7.3 e-Paper HAT while powering the thing with 3v, but did not find any significant voltage drop there.

Might be that it was just a bad batch, or a discarded revision or clone that is sold on AliExpress (my bad then), hard to tell.

I'll consider the issue to be solved for now, and thank you again Jean-Marc (@ZinggJM ) for your invaluable help - I'm pretty sure I wouldn't have been able to narrow it down to the adapter without you!

Cheers and greetings from Basel :wink:
Christian

13

Hi, I only saw this yesterday . I'm also doing stuff on the 7.3 inch color e-paper from Waveshare . And I also experience the dreaded yellow tint . I eventually found a fix / workaround . My code is based on the Waveshare's code.

I figured out that the screen took a bit longer when refresh/render the image if it output the ugly yellow tint, then I do a semi reset and try again and then in most cases it will render good.

I was wondering if the module are the cause, even the 4 color 7.3 inch screen also to some weird lines

with 'yellow tint'

20230626_094127
20230626_0941271920×2560 345 KB

when it re-render fix
20230626_094217
20230626_0942171920×2560 424 KB

Waldo

14

Please do not hijack a solved topic with an issue that is not related to the library mentioned in the title.
-jz-

15

Hi . I was just confirming it is a "hardware" problem not software .

16

I also experienced this issue with the Waveshare 7.3 inch display (using Waveshare libraries). It would intermittently show images with a yellow tint. I resolved the issue by eliminating the long flat flex cable that came with the display. I have also ordered the adapter as suggested by dechrigi118

20230801_200458
20230801_2004581920×2560 413 KB

20230801_200228
20230801_2002281920×2560 637 KB

17

Update: Removing the cable did not work completely. I am still having problems with image quality. Hopefully the new adapter will fix my issues.

18

Could you show me how to fix it with sourcecode?

19

I have a waveshare 7.3 inch photopainter with rp2040. The official firmare works well, while I switch it to arduino with GxEPD2, I find the same problem.

21

GxEPD2_EPD.cpp of GxEPD2 release up to 1.5.2 doesn't work as intended on RP2040 (and maybe other processors, too).

Please download and replace this file, if you encounter this issue, until it is fixed in next release.
-jz-

See also:
https://forum.arduino.cc/t/gxepd2-waveshare-pico-epaper-2-13-v3-raspberry-pico-w/1174008/20