Areas of the screen not in the rendering area will become lighter in color.

Question

Areas of the screen not in the rendering area will become lighter in color.

lanistor opened this issue 8 months ago · 30 comments

Areas of the screen that are not in the rendering area will become lighter in color.

For example, screen is 1024*758, rendering area {x: 550, y: 30, width: 474, height: 60} for several times, the area {x: 76, y: 90, width: 474, height: 668} black color will fade.
Like this:

No matter how I adjust the voltage, I can't fix this problem.
Is there a way to keep areas' color of the screen that are not in the rendering area unaffected?

Testing environment:

board: v5
screen: 060XD4
waveform: tested epdiy_ED060XC3 and epdiy_ED060SCT, same behavior.
UI library: lvgl
mode: MODE_DU, using epd_hl_update_area
esp idf: release 4.4

Demo code:

epd_poweron();
epd_hl_update_area(&hl, updateMode, temperature, first->area);
epd_poweroff();

Answer 1 · 2024-04-15T07:54:44.000Z

My feedback w/Kindle paper white
https://youtu.be/HrZnDrv0QJ8?si=tgrA1ztUJoJH-S-3

Answer 2 · 2024-04-15T08:18:10.000Z

My feedback w/Kindle paper white

Got it👍

Answer 3 · 2024-04-15T18:03:09.000Z

Areas of the screen that are not in the rendering area will become lighter in color.

For example, screen is 1024*758, rendering area {x: 550, y: 30, width: 474, height: 60} for several times, the area {x: 76, y: 90, width: 474, height: 668} black color will fade. Like this:

No matter how I adjust the voltage, I can't fix this problem. Is there a way to keep areas' color of the screen that are not in the rendering area unaffected?

Testing environment:

board: v5

screen: 060XD4

waveform: tested epdiy_ED060XC3 and epdiy_ED060SCT, same behavior.

UI library: lvgl

mode: MODE_DU, using epd_hl_update_area

esp idf: release 4.4

Demo code:
epd_poweron();
epd_hl_update_area(&hl, updateMode, temperature, first->area);
epd_poweroff();

@martinberlin Is there a way to avoid color changes in non-rendering areas?

I think if no voltage is applied to an area, its color should not change.

Answer 4 · 2024-04-15T18:20:07.000Z

Can you please post some program to replicate this?
I know this happens mostly with SPI epapers. But still never saw it in parallel. It might be that display has some ghosts after partial refreshes, that's why e-readers make a full refresh every 10th or so page turn, but other than that it works good for me.
But it can be that with this particular eink and program does not work for you. At least you should make a repository and post test cases so we can replicate it

Answer 5 · 2024-04-16T16:40:06.000Z

@martinberlin I found the problem, it was a problem with the code I rewrote.

I'm using below code to replace epd_hl_update_area():

epd_clear_area_cycles(area, 1, _clear_cycle_time);
epd_hl_update_area_directly(&hl, updateMode, temperature, area);

enum EpdDrawError epd_hl_update_area_directly(EpdiyHighlevelState* state,
                                              enum EpdDrawMode     mode,
                                              int                  temperature,
                                              EpdRect              area) {
  assert(state != NULL);
  // Not right to rotate here since this copies part of buffer directly

  bool previously_white = true;
  bool previously_black = false;

  memset(state->dirty_lines + area.y, 1, area.height);

  enum EpdDrawError err;
  if (previously_white) {
    err = epd_draw_base(epd_full_screen(), state->front_fb, area,
                        MODE_PACKING_2PPB | PREVIOUSLY_WHITE | mode,
                        temperature, state->dirty_lines, state->waveform);
  }

  for (int l = area.y; l < area.y + area.height; l++) {
    if (state->dirty_lines[l] > 0) {
      uint8_t* lfb = state->front_fb + EPD_WIDTH / 2 * l;  // to
      uint8_t* lbb = state->back_fb + EPD_WIDTH / 2 * l;  // from

      for (int x = area.x; x < area.x + area.width; x++) {
        if (x % 2) {
          *(lbb + x / 2) = (*(lfb + x / 2) & 0xF0) | (*(lbb + x / 2) & 0x0F);
        } else {
          *(lbb + x / 2) = (*(lfb + x / 2) & 0x0F) | (*(lbb + x / 2) & 0xF0);
        }
      }
    }
  }
  return err;
}

This method will clear afterimages and ensure faster rendering speed, but the problem is: the area rendered by this function, will become lighter in color, when other area rendering.

I wan't to rewrite epd_hl_update_area_directly, but not works, such as set state->difference_fb[l * EPD_WIDTH + x] = ((*(lfb + x / 2) & 0x0F) << 4) | (*(lbb + x / 2) & 0x0F); will not work.

Could you tell me the wrong of this function epd_hl_update_area_directly, and how to repair it?

Answer 6 · 2024-04-17T19:40:06.000Z

Could you tell me the wrong of this function epd_hl_update_area_directly, and how to repair it?

I don’t really know since I never try to use this myself. I either use the high level library or I push the raw framebuffer and do a hl_update

Answer 7 · 2024-04-18T02:54:40.000Z

Could you tell me the wrong of this function epd_hl_update_area_directly, and how to repair it?

I don’t really know since I never try to use this myself. I either use the high level library or I push the raw framebuffer and do a hl_update

It should be because of i don't known the rendering logic of epdiy clearly, i havn't got the side effect of this way.

Answer 8 · 2024-04-18T03:01:35.000Z

@martinberlin I found the problem, it was a problem with the code I rewrote.

I'm using below code to replace epd_hl_update_area():

epd_clear_area_cycles(area, 1, _clear_cycle_time);
epd_hl_update_area_directly(&hl, updateMode, temperature, area);

enum EpdDrawError epd_hl_update_area_directly(EpdiyHighlevelState* state,
                                              enum EpdDrawMode     mode,
                                              int                  temperature,
                                              EpdRect              area) {
  assert(state != NULL);
  // Not right to rotate here since this copies part of buffer directly

  bool previously_white = true;
  bool previously_black = false;

  memset(state->dirty_lines + area.y, 1, area.height);

  enum EpdDrawError err;
  if (previously_white) {
    err = epd_draw_base(epd_full_screen(), state->front_fb, area,
                        MODE_PACKING_2PPB | PREVIOUSLY_WHITE | mode,
                        temperature, state->dirty_lines, state->waveform);
  }

  for (int l = area.y; l < area.y + area.height; l++) {
    if (state->dirty_lines[l] > 0) {
      uint8_t* lfb = state->front_fb + EPD_WIDTH / 2 * l;  // to
      uint8_t* lbb = state->back_fb + EPD_WIDTH / 2 * l;  // from

      for (int x = area.x; x < area.x + area.width; x++) {
        if (x % 2) {
          *(lbb + x / 2) = (*(lfb + x / 2) & 0xF0) | (*(lbb + x / 2) & 0x0F);
        } else {
          *(lbb + x / 2) = (*(lfb + x / 2) & 0x0F) | (*(lbb + x / 2) & 0xF0);
        }
      }
    }
  }
  return err;
}

This method will clear afterimages and ensure faster rendering speed, but the problem is: the area rendered by this function, will become lighter in color, when other area rendering.

I wan't to rewrite epd_hl_update_area_directly, but not works, such as set state->difference_fb[l * EPD_WIDTH + x] = ((*(lfb + x / 2) & 0x0F) << 4) | (*(lbb + x / 2) & 0x0F); will not work.

Could you tell me the wrong of this function epd_hl_update_area_directly, and how to repair it?

@vroland May you help me? I want to get the side effect of this rendering logic, and repair it.

Answer 9 · 2024-04-18T17:35:08.000Z

@martinberlin I found the problem, it was a problem with the code I rewrote.
I'm using below code to replace epd_hl_update_area():

epd_clear_area_cycles(area, 1, _clear_cycle_time);
epd_hl_update_area_directly(&hl, updateMode, temperature, area);

enum EpdDrawError epd_hl_update_area_directly(EpdiyHighlevelState* state,
                                              enum EpdDrawMode     mode,
                                              int                  temperature,
                                              EpdRect              area) {
  assert(state != NULL);
  // Not right to rotate here since this copies part of buffer directly

  bool previously_white = true;
  bool previously_black = false;

  memset(state->dirty_lines + area.y, 1, area.height);

  enum EpdDrawError err;
  if (previously_white) {
    err = epd_draw_base(epd_full_screen(), state->front_fb, area,
                        MODE_PACKING_2PPB | PREVIOUSLY_WHITE | mode,
                        temperature, state->dirty_lines, state->waveform);
  }

  for (int l = area.y; l < area.y + area.height; l++) {
    if (state->dirty_lines[l] > 0) {
      uint8_t* lfb = state->front_fb + EPD_WIDTH / 2 * l;  // to
      uint8_t* lbb = state->back_fb + EPD_WIDTH / 2 * l;  // from

      for (int x = area.x; x < area.x + area.width; x++) {
        if (x % 2) {
          *(lbb + x / 2) = (*(lfb + x / 2) & 0xF0) | (*(lbb + x / 2) & 0x0F);
        } else {
          *(lbb + x / 2) = (*(lfb + x / 2) & 0x0F) | (*(lbb + x / 2) & 0xF0);
        }
      }
    }
  }
  return err;
}

This method will clear afterimages and ensure faster rendering speed, but the problem is: the area rendered by this function, will become lighter in color, when other area rendering.
I wan't to rewrite epd_hl_update_area_directly, but not works, such as set state->difference_fb[l * EPD_WIDTH + x] = ((*(lfb + x / 2) & 0x0F) << 4) | (*(lbb + x / 2) & 0x0F); will not work.
Could you tell me the wrong of this function epd_hl_update_area_directly, and how to repair it?

@vroland May you help me? I want to get the side effect of this rendering logic, and repair it.

It seems the problem of epd_clear_area_cycles.

Answer 10 · 2024-04-18T20:44:29.000Z

Do you have an image / video of the area that gets lighter? Because to me that sounds a lot like improperly calibrated VCOM. Additionally, you could try if using the ED047TC2 waveform changes anything.

Also, why are you using your own epd_hl_update_area_directly instead of epd_hl_update_area?

Answer 11 · 2024-04-19T03:46:14.000Z

Do you have an image / video of the area that gets lighter? Because to me that sounds a lot like improperly calibrated VCOM. Additionally, you could try if using the ED047TC2 waveform changes anything.

Also, why are you using your own epd_hl_update_area_directly instead of epd_hl_update_area?

I tried ED047TC2, has same behavior.
I adjusted vcom to a suitable value, so it shouldn't be a problem with vcom.
I use epd_clear_area_cycles + epd_hl_update_area_directly to eliminate afterimages, it will rendering black -> white -> content image, this will clear the afterimage,epd_hl_update_area cannot do this.

And, i tried not using epd_clear_area_cycles + epd_hl_update_area_directly, instead using rendering black -> white -> content image, with epd_hl_update_area , this problem disappears, so i think it may be epd_clear_area_cycles

Answer 12 · 2024-04-19T05:11:18.000Z

Please answer this one:

Also, why are you using your own epd_hl_update_area_directly instead of epd_hl_update_area?

I also would like to understand what is the reason to use your own high level update area instead of the one that is already built in

Answer 13 · 2024-04-19T06:13:47.000Z

Please answer this one:

Also, why are you using your own epd_hl_update_area_directly instead of epd_hl_update_area?

I also would like to understand what is the reason to use your own high level update area instead of the one that is already built in

This way can eliminate afterimages (epd_clear_area_cycles + epd_hl_update_area_directly), while epd_hl_update_area cannot.

Answer 14 · 2024-04-22T20:16:03.000Z

Can you show a video of both methods? I don't really see why they would behave different, so seeing the outcome would help.

Answer 15 · 2024-04-25T18:39:58.000Z

Can you show a video of both methods? I don't really see why they would behave different, so seeing the outcome would help.

Before

After

Video

https://github.com/lanistor/assets/blob/master/epaper/060XD4_out_paint_area.mp4

Answer 16 · 2024-04-28T17:04:34.000Z

Can you show a video of both methods? I don't really see why they would behave different, so seeing the outcome would help.

Before

After

Video

https://github.com/lanistor/assets/blob/master/epaper/060XD4_out_paint_area.mp4

@vroland Is this helpful for resolving the problem?

Answer 17 · 2024-04-29T20:21:35.000Z

That makes it more clear, thanks. Curious, I don't really know why that is. I'll mark it as a bug for now and try to reproduce it some time. Do you have a minimal example for reproducing the problem handy?

Answer 18 · 2024-04-30T10:44:30.000Z

That makes it more clear, thanks. Curious, I don't really know why that is. I'll mark it as a bug for now and try to reproduce it some time. Do you have a minimal example for reproducing the problem handy?

I made a minimal example : https://github.com/lanistor/epaper-tester

I can reproduct problem with ED060XD4, but cannot reproduct with XC3, XCH, do you have a ED060XD4?

Answer 19 · 2024-04-30T18:34:59.000Z

Argh, I think I only have an XC3... But I can try my luck.

Answer 20 · 2024-04-30T20:30:04.000Z

I will check because Lanistor sent me 2 XD4 and still have one around so if I find it I can send it to you in next package 📦
Just checked so far have a 060XCD

Answer 21 · 2024-05-01T07:29:03.000Z

I will check because Lanistor sent me 2 XD4 and still have one around so if I find it I can send it to you in next package 📦 Just checked so far have a 060XCD

As i remembered, i sent you 2 XCD, not XD4. I could send XD4 to @vroland .

Answer 22 · 2024-05-01T07:30:52.000Z

Argh, I think I only have an XC3... But I can try my luck.

@vroland Could you give me your address? I could send you 2 XD4. Here is my email: lanistor@163.com.

Answer 23 · 2024-05-09T17:10:12.000Z

Hi, @vroland, @martinberlin,

I found another very interesting performance that will help solve this problem: when the circuit board is powered on again, it will slowly display the last rendered content.

Here is a video of my experiment:
https://github.com/lanistor/assets/blob/master/epaper/060XCD_2024-05-10.mp4

The test code for video recording is here https://github.com/lanistor/epaper-tester/tree/test/case-2, the branch is test/case-2.

And here is my experimental using case:

Turn on the power and a black background will appear on the entire screen.
Render the block a few times at the top, then a few times at the bottom
Disconnect the power and then turn it on again. When rendering the top block, the shape of the block will appear at the bottom.
Repeat the above steps, but turn the power off after 3 minutes and then turn it on again. At this time, the shape of the bottom block will fade; if you turn the power on again after 5 minutes, the shape of the bottom block will be almost invisible.
If delay 2000ms between epd_clear_area_cycles and epd_hl_update_area_directly, the problem almost disappeared. The longer the time, the better the effect.

  epd_poweron();
  epd_clear_area_cycles(area, 1, _clear_cycle_time);
  vTaskDelay(pdMS_TO_TICKS(2000));
  epd_hl_update_area_directly(&hl, updateMode, temperature, area);
  epd_poweroff();

I tested the brand new XCD and XCH and both had this problem; on the second-hand XD4, this problem will be more serious.

This is really a very strange behavior. The only explanation I can think of is: the electrode on the back of the screen has a weak capacitance, which stores a small amount of electricity. When the screen is powered on, these weak currents will cause the displacement of the particles. Because the second-hand screen (XD4) has been used for a long time, the capacitance will increase, causing the particle displacement to increase.

I found the problem, but I don't know how to solve it. This problem is really interesting, and it's beyond my knowledge. May you find out the way to resolve this problem?

Another test case

If call epd_push_pixels to push white color instead of calling epd_clear_area_cycles, the old area will became darker than expected. If count of white and count of black are not equal, it will aggravate the problem, but the behavior is opposite (the color becomes darker or lighter).

  // for (int i = 0; i < 10; i++) {
  //   epd_push_pixels(area, _clear_cycle_time, 0);
  // }
  for (int i = 0; i < 10; i++) {
    epd_push_pixels(area, _clear_cycle_time, 1);
  }

Test behavior: (this case branch: test/case-3 ).

Answer 24 · 2024-05-10T19:16:42.000Z

Interesting, looks like this particular display model is very sensitive to residual charge / charge buildup. Maybe if we could dump the on-chip waveform we can fix this? Or we have to experiment with the waveforms we have. But this would be my guess that with the waveforms we have there is some imbalanced charge buildup.

Answer 25 · 2024-05-11T08:03:48.000Z

Interesting, looks like this particular display model is very sensitive to residual charge / charge buildup. Maybe if we could dump the on-chip waveform we can fix this? Or we have to experiment with the waveforms we have. But this would be my guess that with the waveforms we have there is some imbalanced charge buildup.

I got the knowledge here: #226 (comment) .

Answer 26 · 2024-05-16T20:26:26.000Z

@lanistor I got your displays today, now I'm going to try replicating it when I have the time :) I already tried the display with a V7 board, there it didn't behave so different, but I'll try to reproduce it with a V5 board when I have the opportunity.

Answer 27 · 2024-05-16T20:34:22.000Z

I tried to compile your example repo and I get an error with idf 4.4.5:

/home/vroland/dev/misc/epaper-tester/components/lvgl_epaper_drivers/lvgl_helpers.c: In function 'lvgl_driver_init':
/home/vroland/dev/misc/epaper-tester/components/lvgl_epaper_drivers/lvgl_helpers.h:48:25: error: 'LV_HOR_RES_MAX' undeclared (first use in this function); did you mean 'LV_HOR_RES'?

Any particular version of the dependencies I need?

Answer 28 · 2024-05-17T05:53:40.000Z

Probably a different version of LVGL but here I packed a way to get all in a single git clone call:

https://github.com/martinberlin/lv_port_esp32-epaper/wiki/LVGL-9.0

LV_HOR_RES_MAX & LV_HOR_VER_MAX correspond if I remember well to display Width and Height.

Answer 29 · 2024-05-19T04:44:13.000Z

I tried to compile your example repo and I get an error with idf 4.4.5:

/home/vroland/dev/misc/epaper-tester/components/lvgl_epaper_drivers/lvgl_helpers.c: In function 'lvgl_driver_init':
/home/vroland/dev/misc/epaper-tester/components/lvgl_epaper_drivers/lvgl_helpers.h:48:25: error: 'LV_HOR_RES_MAX' undeclared (first use in this function); did you mean 'LV_HOR_RES'?

Any particular version of the dependencies I need?

@vroland Have you changed the version of lvgl? The default version is v8.3, and it doesn't need the LV_HOR_RES_MAX .

If using the following code to start project, it won't need LV_HOR_RES_MAX, and i can start it correctly on a new folder:

git clone git@github.com:lanistor/epaper-tester.git
cd epaper-tester
git submodule update --init --recursive

idf.py build

And idf 4.4 is OK.

Answer 30 · 2024-05-25T12:15:22.000Z

Ok, now it compiles but the screen doesn't update. Maybe I'll have to try with a different board when I have the chance.