17 Grey Levels on Kindle Touch?

[EternalCyclist]

eips -l

shows a pattern with 16 levels of grey.
After overwriting the framebuffer with a value 255 for the first 100 lines I have the impression that the bar is brighter than the brightes square drawn by eips.
To overwrite the first, e.g. brightes square, with this ultra-white (255), one first has to overwrite it with a different value. Otherwise it won't update.

Crosschecking:
Filling the screen with bars of value alternating from 240 and 255 shows difference shades. (I assumed, that the upper 4 bit determine the grey level).

So, I have actually 17 levels of grey and I have to set background to 255 to get maximum contrast?

The background the home screen is actually as bright as the 255-bar.

Strange: Filling the screen with 0x10 and 0x00 bars, shows no difference. So using 0x10 to 0xf0 plus 0xff gives me again only 16 levels. But I see 17 different levels when overwriting the eips pattern.

[twobob]

possibly one of them is artificially "ghosted" to a slightly offset value as a result of the washing process. perhaps it's perceptual I guess is the point being badly made here.

[geekmaster]

I have a demo that can write "blacker than black" and "whiter than white". After multiple "full flash clear" commands, you just draw an object rapidly many times alternating black and white, ending in the final color. Black is clearly darker than a black background that was only drawn once (or even a few times). White is clearly visible on a white background. But a screen capture will show that the clearly visible "ghost text" is NOT in the framebuffer.

[knc1]

Originally Posted by EternalCyclist

eips -l

shows a pattern with 16 levels of grey.
After overwriting the framebuffer with a value 255 for the first 100 lines I have the impression that the bar is brighter than the brightes square drawn by eips.
To overwrite the first, e.g. brightes square, with this ultra-white (255), one first has to overwrite it with a different value. Otherwise it won't update.

Crosschecking:
Filling the screen with bars of value alternating from 240 and 255 shows difference shades. (I assumed, that the upper 4 bit determine the grey level).

So, I have actually 17 levels of grey and I have to set background to 255 to get maximum contrast?

The background the home screen is actually as bright as the 255-bar.

Strange: Filling the screen with 0x10 and 0x00 bars, shows no difference. So using 0x10 to 0xf0 plus 0xff gives me again only 16 levels. But I see 17 different levels when overwriting the eips pattern.

That is just a visual artifact of two properties of the screen:

*) The e-ink particles are much smaller than the resolution. I.E: There are many particles per pixel.

*) The e-ink particles are not independent. They interact with each other (within the area of a single pixel).

Switch the group of particles within a single pixel from one maximum value to the other maximum value, and. . .
The ones that are already at the target value do not have to move,
The ones that are not at the target value have to move,
Since they interact, not all of those move the same amount.

But if you repeat the max-to-max switch often enough, you can get nearly all of them into the same position.
Giving an overall appearance of a denser color (white or black).

If an analogy is clearer, think of materials behavior to being magnetized.
The first stroke of the magnetic field over the material only aligns a some of the magnetic domains of the material.
Repeated stroking of the magnetic field aligns a larger percentage of the magnetic domains with each stroke.

If you could see the effect of the magnetic domain alignment, you would see the same "ghosting" effect that the e-ink particles have in their electrical field alignment.

Translation:
It is not a 17th gray scale level, it is a better approximation of the 16th gray scale level.

[EternalCyclist]

eips -i c

prints the following colormap:

Spoiler:

Color map
start: 0 len: 256
n red green blue
0 0 0 0
1 0 0 0
2 0 0 0
3 0 0 0
4 0 0 0
5 0 0 0
6 0 0 0
7 0 0 0
8 0 0 0
9 0 0 0
a 0 0 0
b 0 0 0
c 0 0 0
d 0 0 0
e 0 0 0
f 0 0 0
10 0 0 0
11 1111 1111 1111
12 1111 1111 1111
13 1111 1111 1111
14 1111 1111 1111
15 1111 1111 1111
16 1111 1111 1111
17 1111 1111 1111
18 1111 1111 1111
19 1111 1111 1111
1a 1111 1111 1111
1b 1111 1111 1111
1c 1111 1111 1111
1d 1111 1111 1111
1e 1111 1111 1111
1f 1111 1111 1111
20 1111 1111 1111
21 1111 1111 1111
22 2222 2222 2222
[obvious part deleted]
ed dddd dddd dddd
ee eeee eeee eeee
ef eeee eeee eeee
f0 eeee eeee eeee
f1 eeee eeee eeee
f2 eeee eeee eeee
f3 eeee eeee eeee
f4 eeee eeee eeee
f5 eeee eeee eeee
f6 eeee eeee eeee
f7 eeee eeee eeee
f8 eeee eeee eeee
f9 eeee eeee eeee
fa eeee eeee eeee
fb eeee eeee eeee
fc eeee eeee eeee
fd eeee eeee eeee
fe eeee eeee eeee
ff ffff ffff ffff

There is only one mapping to ''superwhite'' value but 17 to each of the other colors. My mistake was to assume, that only the higher nibble counts. Now it is clear why I see no difference between 0x00 and 0x10. Instead of shifting my grey levels by 4 (v<<4), I should use (v<<4)|v. This gives the "superwhite" and all other 15 shade levels.

As described in the postings above, the impression of a 17th value was caused by the memory effect of the display.

[geekmaster]

As you can see in my eink code (GMLIB), you will see that the 8-bit eink framebuffer must have a copy of the 4-bit value in both the top and bottom half-bytes. More than 16 colors are created with dithering. You can copy a framebuffer that contains a screensaver image (or special offers ad) , then load it into an image processing program and do histogram analysis on it. You will see 16 spikes, showing that it is really 4 bits duplicated as described above.

The eink driver GPL source code has comments saying that NOT having duplicate half-bytes in 8-bit framebuffer mode can have unpredictable hardware-dependent results.

EDIT: As you can see in your color map, each color value is just 0x0 through 0xf, repeated into each half-byte of the color map word size. 16-colors, even in 8-bit mode. I have code that dithers 256 color to fit into either 4-bit or 8-bit framebuffers, and works in all modes (main and diags) on all the eink kindles.

Check out the newtrix demo for details and sample code:
https://www.mobileread.com/forums/sho...d.php?t=176802