MODE_PACKING_2PPB renders "stripes"

[j4k32]

When using MODE_PACKING_2PPB

epd_draw_base(epd_full_screen(), state->front_fb, epd_full_screen(), MODE_PACKING_2PPB | PREVIOUSLY_WHITE | MODE_GC16, temperature, NULL, state->waveform);

instead of MODE_PACKING_1PPB_DIFFERENCE where diff_area = epd_difference_image_cropped(...)

epd_draw_base(epd_full_screen(), state->difference_fb, diff_area, MODE_PACKING_1PPB_DIFFERENCE | MODE_GC16, temperature, state->dirty_lines, state->waveform);

the front_fb is printed in "stripes" on the eink, see attached image.

ED133UT2 epdiy v7 esp32s3

[martinberlin]

This has to be checked by Valentin when he is back but for the moment use another method. It can be that this combination:

MODE_PACKING_2PPB | PREVIOUSLY_WHITE | MODE_GC16

is not really supported. I must say that I never tried to concatenate so many settings like this. It would be great if you also analyze in the code what is doing to understand better how the library works.

[vroland]

@j4k32 How does the buffer you're rendering look then? Did you also change the buffer layout accordingly?

[j4k32]

Hi again, sorry for my late response.

@martinberlin MODE_PACKING_2PPB | PREVIOUSLY_WHITE | MODE_GC16 is taken from the highlevel rendering function epd_hl_update_screen so I thought it would be a legit combination (However, the bool previously_white and bool previously_black is always false, so the function never updates the eink with that combination.).

@vroland I use the script imgconvert.py to create the buffer which is copied to the highlevel front_fb, but I have modified the script to json format instead of .h format. The json is then sent to the epdiy over a tcp connection. I first thought it was some kind of mismatch between the sent data and how the data is saved to the buffer, but I get the same result with the dragon-example you provide in the repository. Note: The same buffer (recreated with the epd_difference_image_cropped function) and MODE_PACKING_1PPB_DIFFERENCE works well.

Update: not sure if this is helpful as the waveforms are a black boxes to me, but I've tried with different waveforms and get the same result.

[vroland]

Note: The same buffer (recreated with the epd_difference_image_cropped function) and MODE_PACKING_1PPB_DIFFERENCE works well.

What do you mean here exactly?

[martinberlin]

Dear @j4k32 please give feedback about this issue. We really do not want to have issues forever open without feedback so those issues marked as "waiting for feedback" have a 2 months limit to get an answer. If you don't answer in this timeframe then the Issue will be closed

[j4k32]

@vroland The dragon buffer provided in the example directory of your repo works fine when rendered using the epd_hl_update_area function, which uses the epd_difference_image_cropped together with MODE_PACKING_1PPB_DIFFERENCE. The stripes occurs when I try to render the dragon buffer using the epd_draw_base function together with the MODE_PACKING_2PPB, but without the epd_difference_image_cropped

[vroland]

Ok, I see. Which display are you using and can you provide a working example program? It could be either your buffer settings not matching the buffer or an actual bug, that that is easier to test with a reproducible example.

[j4k32]

I am using ED133UT2 display together with epdiy v7 esp32s3 driver board. As mentioned before, the issue also occurs when loading the dragon example provided in the repo, so you can use that to reproduce. The only thing that needs to be changed is from (in the examples/dragon/main.c) // enum EpdDrawError _err = epd_hl_update_screen(&hl, MODE_GC16, temperature); to enum EpdDrawError _err = epd_draw_base(epd_full_screen(), state->front_fb, epd_full_screen(), MODE_PACKING_2PPB | PREVIOUSLY_WHITE | MODE_GC16, temperature, NULL, state->waveform);

[vroland]

Working on refactoring the LUT code, I actually found a bug in the 2bpp lookup calculation code. I'll tag this issue in the PR, hopefully that resolves it :)