-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MODE_PACKING_2PPB renders "stripes" #284
Comments
This has to be checked by Valentin when he is back but for the moment use another method. 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. |
@j4k32 How does the buffer you're rendering look then? Did you also change the buffer layout accordingly? |
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. |
What do you mean here exactly? |
Dear @j4k32 please give feedback about this issue. |
@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 |
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. |
I am using ED133UT2 display together with epdiy v7 esp32s3 driver board. |
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 :) |
Sounds promising! Thank you very much |
Hello @j4k32 |
Works perfectly, thank you! |
Refactors waveform lookup calculations to be more maintainable and adds tests to avoid regressions. In the process, line masking is simplified and ordering problems in 2ppB mode are fixed (this should fix #284). 8ppB now supports both PREVIOUSLY_BLACK and PREVIOUSLY_WHITE.
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
The text was updated successfully, but these errors were encountered: