Quote:
Originally Posted by willus
I hadn't intended this as a test of the grayscale conversion algorithm in the devices, but it certainly is interesting. The checkerboard pattern I put in the PDF is full (100%), either red, green, or blue. The Kobos convert the red, green, and blue to 52%, 86%, and 26% of full white, respectively. The Kindle 2 converts to 50%, 33%, and 17%, respectively, and the PW2/Voyage convert to 9%, 35%, and 12%, respectively. Interestingly, none of these match the commonly used grayscale conversion ITU-R BT.709 or BT.601, which are 21%,72%,7% and 30%,59%,11%, respectively, but the Kobos are definitely closest, proportionally, which explains why they look more natural. It is particularly strange to me that all of the Kindles weight the RGB components significantly differently than the ITU-R weightings (K2 has red weighted the highest, and PW2/Voyage have blue weighted more heavily than red). That seems clearly flawed, and would be trivial to correct. How odd. |
Well I've been grappling with something similar and stumbled across this thread.
After doing a lot of reading, I think the problem might be one of different gamma being applied to sRGB output compared with that used by eInk displays.
From WCAG2.0, and it's calculation of relative luminance, the sRGB values are linearized using an (effective) gamma of 2.2 which is the theoretical value for the sRGB colour space.
It seems that eInk is much more like ink on paper - I could not yet find any data for the gamma of an eInk screen, but most printers use a gamma of 1.8 .
I wonder then if instead of trying to find a set of coefficients to use for the weighted average step, it makes more sense to use a lower gamma to linearise the sRGB values in the first place.
If this doesn't make any sense, don't worry - I only barely understand it myself
