Problem with displaying C Headers/Images

[kthiesen]

Hi,

newbie here, so excuse me if this is a stupid question but I´m having the following problem: After finally getting my v7 board to work with a ED060KC1 Display, i converted a test image (with 1072x1448) with the imgconvert.py script to a C Header File using the displays resolution, setting the same resolution in the args. The Header File seems to be correctly converted but when I replace my header file with the dragon.h file in the dragon demo, the new image is updated on the display but is only using about half of the epaper displays size. I already adjusted the resolution in displays.c so that it matches my resolution and it worked correctly for the dragon.h image, so I really don't understand what makes my image render smaller on the screen. printing out epd_width and epd_height and also the image_width and image_height are giving me the correct resolution as well.

Would be great if somebody knows what's going on here.

Thanks in advance!
Best, Konstantin

[martinberlin]

Can you please show how is your displays.c configuration for this display?
I think it might be also that for some reason the image array is cropped. You should check that the bytes length match the size:

(1072*1448)/2 = 776128

So if you dump the size of the img_data array it should match that number. Just try:

printf("sizeof img: %d\n", sizeof(img_data));

That could help discovering what is going on. But also might be that the img is there completely and simply the update is not being done in the full display size, check that also.

[kthiesen]

Thanks for your reply. I checked the size of the image data array and its 776128.

This is the configuration for my display (its actually a ED060KC1, but on the GitHub page it says it should work as ED060XC3, so I only adjusted the .width and .height values for the ED060XC3 and added this one to the main.c idf_setup):

const EpdDisplay_t ED060XC3 = { .width = 1448, .height = 1072, .bus_width = 8, .bus_speed = 20, .default_waveform = &epdiy_ED060XC3, .display_type = DISPLAY_TYPE_GENERIC, };

Regarding the update not being done in the full display size, how can I check that? I actually just used the dragon example as a blueprint and didn't change anything besides exchanging the image source.

What I also noticed is that even though I set 0 for x and y in epdrect, the image is centered in the middle of the screen.

What really bugs me is the fact that the dragon demo (with the dragon.h image) and the other "demo" demo are working well, so maybe this problem is related to the way I converted the image with the script. Will try with other images tomorrow if you don't have any other solution for me at the moment.

[martinberlin]

What I also noticed is that even though I set 0 for x and y in epdrect, the image is centered in the middle of the screen.

I'm now thinking this could be also a Waveform issue. Can you just try modifying the waveform in displays.c? For example:

.default_waveform = &epdiy_ED097TC2

Regarding the update not being done in the full display size, how can I check that?

Actually dragon demo is doing a full update: enum EpdDrawError _err = epd_hl_update_screen(&hl, MODE_GC16, temperature);
That hl_update_screen is doing a display.width / height refresh so it should refresh whole display.

[kthiesen]

ok, I got it to work with another image, so I need to investigate what went wrong with the first one.

But I noticed something else now: I have an image which has a white border around a drawing. When displaying the image the white border is somehow replaced by a bit more greyish color tone. Also you can see that when updating the screen, only the inner part of the screen is refreshed and not the white border.

To illustrate my point I took a photo and heavily turned up the contrast so the border is more visible:

And this is a screenshot from the refresh sequence:

I assume there is some compression happening either during the imgconvert or directly in the firmware which strips away the white border to safe space or to speed up the refresh?

[martinberlin]

Can you try the grayscale example and show a photo of how it looks?

I assume there is some compression happening either during the imgconvert or directly in the firmware which strips away the white border to safe space or to speed up the refresh?

no, it can’t be. There is no compression but of course an image might have many tones of gray and the Eink can show only 16 so that might affect how it looks. Specially if the waveform timing is not perfect and not all the 16 shades of gray can be displayed

[kthiesen]

here a screenshot of the grayscale_test. shouldn't the grayscale values be more evenly distributed or is this a normal pattern for an ink display?

what's interesting is that the last bar is a bit more greyish than the bar before that. I would expect the last bar to the purest white (compared to the bars before that)?

Don't know if this is important but in the grayscale_test it main.c it says:
hl = epd_hl_init(WAVEFORM);
while in the dragon test main.c it says:
hl = epd_hl_init(EPD_BUILTIN_WAVEFORM);

Also, I have set a vcom value of 2410 in main.c since -2.41 is written on the display.
epd_set_vcom(2410);
You told me before that the vcom value is usually much smaller, but I guess it was correct to set it this way, if its written on the display, right?

I also did the following test, since I thought maybe processing (the image was procedurally created) is exporting the image incorrectly: Created a comp with the displays pixel size, set the whole background to pure white 255, added a cross in the middle. then converted to a header file. same problem, I get a greyish border. I guess it can't be the source image then, since there shouldn't be any change in color values between the inner area and the outer area if I set it up this way in PS.

[martinberlin]

Yes that seems to be the issue. The waveform timing is not the correct one for this display since the last bar should be full white and you are getting a gray. That is the reason your image renders a gray on the white.

Don't know if this is important but in the grayscale_test it main.c it says: hl = epd_hl_init(WAVEFORM);

That really does not matter. Just try selecting different waveforms for the display in displays.c. You can try even any other size is actually just a name, size does not matter, they are just different timings. And if any of them works you don't have any other choice but to modify it by hand. Something that is described in this issue:
#226

[kthiesen]

it worked! thanks for your help! After trying most of the waveforms without luck, finally &epdiy_ED047TC2 was giving me a good result. Maybe this should be added to the display overview on the github page that for the ED060KD1 you need to use the ED047TC2 waveform. could safe other people some time :)

[martinberlin]

Awesome! Glad that it worked.
That is one of the slowest timings but if you don’t need speed is all fine