Color support and next collaboration examples

[martinberlin]

Once #251 is merged I'm planning a new code sprint that I'm already testing but I need to mature both in my mind but also in the code after some research and discussions on what is the best way to implement it.
This is the summary of what I have in my mind, which still needs to be matured and probably explained extensively and documented in the WiKi section.
First I should make a clear explanation of how color works with the filters in Color Filter displays (CFA):
Basically each pixel has on top a small transparent filter with color, so if the pixel below is white (255) in actual grayscale, then the light will pass through and it will reflect on the white. Hence you will see red. The panel that I'm testing that you can see in the WiKi page has an RBG pattern.
Let's say you want to print only Red. Then you have to only set to white those pixels below Red. And the others to gray or some value below 255. So now that is how to show color. But you can also completely ignore the filters and print as always with a grayscale epaper the Dragon example. Then you will just see the dragon in grayscale as always since it completely ignores color.
Note that the background in this CFA epapers is always a bit grayish since they have an additional layer on top. Said that when using color your real resolution will be always a bit lower, since a color pixel is really drawn by combining 3 dots (RBG) and every pixel then represents only one color when using the CFA. There is no way to disable color filter is always there and your display will always look at you saying I’ve a filter, look how gray I am!
But you can of course draw image color parts and still a font rendered only in black completely ignoring color. And that's the difficult part: How to make it easier for the user to do that.

• Add a way to manage color. For more detailed info please check this page in the WiKi

Best idea so far after discussing this with @vroland would be to add a epd_set_color(uint8_t r, uint8_t g, uint8_t b)
Then drawing a pixel or calling any GFX function will move a pixel in the display only for the pixels of that color. There is a function to guess what filter is on the top of each x, y coordinate (check my branch comparison with s3_lcd below)

But the question is: Is it this linear way of "asking what filter is on top" the best way to handle color?
I've no idea. It's the simpler way that for sure. But we also need a way to tell the GFX functions:
epd_mode(MONO] and that will be ignore color completely. Treat this as a normal display and use just grayscales. Using epd_set_color will enable the GFX functions to be color aware again.

• Add a way to handle gamma curve for each pixel printed. Gamma can be described as how smoothly black transitions to white on a digital display.

• New v7 PCB has a RTC chip on board.
  Let's make one full example to make a precise timer with it that wakes up every N minutes, 2 maybe, and shows the correct hour, date, month and year in the display. We can use the PCF8563 interrupt pin, that get's low on defined alarms (It's pulled high), to wake up ESP32S3 and draw only the hour part.

• New v7 board has USB data directly going into S3 (IOs 19,20) so theoretically we can use it as an "USB device" create an example that receives the framebuffer or a JPG image via USB
  DONE: https://github.com/vroland/epdiy/tree/s3_color_implementation/examples/v7-usb-device

So far this is the first draft of color implementation
https://github.com/vroland/epdiy/compare/s3_lcd...s3_color_implementation?expand=1

[martinberlin]

Further color bugs:
Sometimes, not every render I think, a pixel shifts from R to G (or to B don’t really know) making this effect in the display:

FOUND what it is:

It seems for some weird reason the pattern suddenly changes after some rows, so it's half one pattern, half the other. To understand this in code:

uint8_t epd_get_panel_color(int x, int y, uint8_t r, uint8_t g, uint8_t b) {
  // Crazy: Add 1 more to see the line (CFA filter has displaced colors)
  uint16_t y_color_offset = 684;
    /**
     * @brief First 996 Y rows have: RBG pattern but the other rows have one pixel shifted to the right so the next
     *              684 Y rows have: BGR pattern (So I have to make this weird conditionals to get the right color)
     */
    uint8_t c = (x + (epd_height() - y)) % 3;
    switch (c)
    {
      case 0:
        if ((epd_height() - y) < y_color_offset) {
          return gamme_curve[b];
        } else {
          return gamme_curve[r];
        }
        
        break;
      case 1:
        if ((epd_height() - y) < y_color_offset) {
          return gamme_curve[g];
        } else {
          return gamme_curve[b];
        }
        break;
      default:
        if ((epd_height() - y) < y_color_offset) {
          return gamme_curve[r];
        } else {
          return gamme_curve[g];
        }
    }
}

@vroland I checked this with the microscope and it does not seem that the color filter is displaced. Can be this pixel shifting something that occurs with big buffers ?

[vroland]

Hm, maybe this is because on the frame restart hack on the LCD peripheral for displays higher than 1024 pixels? It seems weid, because in that case it should be shifted by a block of 4 pixels (1 cycle), but maybe this is correlated. What's the resolution on this display again? Right now it's set to do this after 1000 lines. Does the color line shift if you change the LINE_BATCH value in output_lcd/lcd_driver.c?

[martinberlin]

Thanks for the hint. Yes this looks exactly because of this.
Resolution is: 2232x1680 (WxH)
Setting the LINE_BATCH to 840 that is exactly half of this epd_height() then this effect of color-shifting appears on the middle of the display. Trying to set it higher than 1000 it just crashes.

It seems weird, because in that case it should be shifted by a block of 4 pixels (1 cycle), but maybe this is correlated. What's the resolution on this display again?

Sure I don't really know how many pixels are, just see that is one color shifted to the right, will do more tests and let you know.
I guess it does not have anything to do with color, right? It should be possible to see a pixel shifting in any other display after certain amount of rows (Example: the 13.3" I will try that also)
We should try also on the 13.3 (The PCB I sent you has this connector) and draw some vertical lines, check if they look all plain vertical all over the display with some magnifier lens.

[mataide]

Hello, I have here the Kaleido display https://www.eink.com/product/detail/SC1452-FOA, let me know how I can help to test this Color filter.

[martinberlin]

Hello @mataide
If you have some information / datasheet please send it to me with a private email to martin [AT] cale.es and get a working epdiy v7 board. Then we can try something together. So far I had only this Wuxi Weifeng (DES) color displays that are sold by Good-Display.

[mataide]

@martinberlin Done. Let me know if you got my email. I am very interested in making it work, and I do have contact with the EINK Engineers, so hope that I can help you with this.

[mickeprag]

Is the kaleido display different from the one you have @martinberlin?
@mataide Where did you get it from?

[martinberlin]

I'm quite sure the colors arrangement is not the same. But we need to try it so first thing I will do is to sell one of my v7 boards to him so he can try it out. And tonight will take a deeper look to the datasheet and check if the Pinout is the same as v7 current 16 bit, 40 pin connector.