Very dark red color in 0.0.5+

[pimoroni]

Very dark red color in 0.0.5+

[codeincontext]

Red has always looked darker than I expected on my WHAT, so I'm interested in trying some similar tweaking if it's possible

[Gadgetoid]

Looks like you've got an Inky pHAT that says it has a high-temp variation of the display part, but it either might not, or your ambient temperature is high enough (or low enough? These things confuse the heck out of me) that the LUT adjustment to compensate for most high-temp displays not looking quite right is... not looking quite right!

The offending change is probably this one: 0b29e83

A quick-fix might be to force it back to "red" like so:

inky_display = InkyPHAT("red")
inky_display.lut = "red"

[cluening]

Forcing the "red" value helped some, but with my board I wasn't able to get the same vibrancy as seen on 0.0.4 without reverting the changes in the duration section. However, I also found that writing the same screen multiple times made the text more vibrant too, which probably implies that burn-in helps. You can especially see that in the photo below, which I accidentally created by running a copy of my test script several times that only wrote the top two lines, followed by a run that also wrote the bottom line. The initial version didn't have the "force red" fix in it, while the one that ran the last time did.

Temperature-wise, I'm a little on the cool side, but not dramatically so - I've been playing with this in my garage, which has been around 65-70F (18-21C) lately.

If the updated voltages/timings look normal on your test hardware, then maybe I just got a board with a display that is on the edge of the expected values.

[Gadgetoid]

The other thing that changed between 0.0.4 and 0.0.5 that could be related are these lines in inky/__init__.py:

        self._send_command(0x03, 0x17)  # Gate Driving Voltage
        self._send_command(0x04, [0x41, 0xAC, 0x32])  # Source Driving Voltage

There's no easy way to override these changes, however, since they happen as the update method is called. Grabbing the source of this library and tweaking to see what works best for you might help.

I suspect - while there are no doubt manufacturing tolerances in these displays - you're probably seeing the same thing as everyone else, but might have some basis for comparison of red vibrance that nobody else has encountered. Though given that these are little particles of ink being pulled around a fluid suspension, anything can happen!

In your case changing the source driving voltages for the ones used on Red WHATs might work:

self._send_command(0x04, [0x30, 0xAC, 0x22])

I might have to look into an optional parameter for tuning these numbers- though right now you might be the only user!

P.S. Thanks for the extremely clear pictures/code examples and details of the issue!

[cluening]

Thanks for the extra things to play with! I've got a busy week, so it might be a while before I get to try them out, but I'll report back when I have a chance.

[dsample]

Thanks @cluening, for pointing out that 0.0.4 worked. I just tried it and it's rescued my old Inky wHAT (which I've hardly used).

I'm going to try and use 0.0.4 for my needs (advent calendar with a santa image on it). I tried doing the same thing last year but gave up when I couldn't get the red to be vibrant (it's nearly black using the latest version).

My Inky wHAT is 2 years old, and doesn't appear to be auto-detectable by new versions using eeprom

[cluening]

I've been working on other projects over the last couple of weeks instead of this one, but occasionally I've gone back and played with the lookup table values a few times to see what I could change. I've been experimenting based on the comments in inky.py that describe the lookup tables. My current favorite color is created using these values:

master...cluening:cluening/bettercolor

Playing with the driving voltages mentioned in the comment by @Gadgetoid on October 26 didn't really do much, but making the timing changes in that diff helped a lot. They add a little over one second to the redraw time for the screen, which I'm fine with for the improved color.

[michael-quinlan]

Any official update on this I just notied the same thing on my brand new wHAT. The red on 1.2.0 is almost black while on 0.0.4 it's crisp.

I can patch the bettercolor branch from above but I it would nice if that was just merged.

[siddhantvirus]

@michael-quinlan Check this thread here? #106 (comment)

[Gadgetoid]

This should, in theory, be fixed on v1.2.1 - https://pypi.org/project/inky/