Slashdot Mirror
DIY Electronic Paper Display
An anonymous reader writes "LinuxDevices.com has an article about a development kit for prototyping device displays based on electronic paper technology. The kit includes a 170dpi, 6-inch (diagonal) SVGA (800 x 600) EPD (electronic paper display) module supporting four shades of gray, and a small computer module that runs the display. EPDs provide bright, high-contrast, thin, lightweight displays that remain legible under 'any lighting condition' -- much like newsprint. Once an image has been 'printed,' no power is needed to hold it."
I don't know about anyone else, but I've been looking for a dev kit like this forever. Even just as an E-Reader (what the dev kit is preconfigured for) the possibilities are tremendous!
I'm a bit annoyed that it's taken 30 years since Xerox first developed the idea, but at least it's here now. Just imagine if this technology catches on. No more need for paperback books (you can keep all the latest on your pocket reader), technical books can finally be portable now that page graphics can be shown in detail, and eye strain will reduce considerably as your eyes can lock onto something that's actually there rather than simulated by a beam of light.
Javascript + Nintendo DSi = DSiCade
1. Resolution
2. No need for backlight
3. Needs power only to _change_ image, not to hold it
$3000.00
To expand:
1. Hi-Res Palm Pilots are 300x300 whereas this first-gen dev kit is 800x600.
2. In theory, eInk has all the contrast of paper. In practice it often has a slightly grey background, but still plenty of contrast in comparison to computer screens.
3. This effectively means that the processor can be put in a wait state or possibly turned off when the screen isn't being updated. For ebook readers, watches, and personal organizers, there's even the possibility of using something REALLY low power like a PIC since you're only updating the screen on very rare occasions.
Javascript + Nintendo DSi = DSiCade
I have used the LibriE electronic book mentioned in the article, which is available in Japan. I felt that it was an adequate replacement for a book, with an easily readable screen. Changing the page had some delay, but on the other hand so does changing the page of a real book. I imagine that the target audience of this are people wishing to read books on crowded Tokyo trains. Since less space is required this could be a good book replacement, after the cost comes down a bit. Biggest problem for their target group surely must be reading newspapers on the train, since they require a lot of space to open. It would be nice to see them provide newspapers for easy download to these devices.
...but even so, to answer one of your criticisms, a colour version is indeed available (yes, linked to near the bottom of the original article!). Like OLEDs, it's going to be several years before these get cheap enough to consider using as an e-book (or whatever). I'm interested, also, whether this e-paper technology would scale up really large - e.g. could it eventually be used as a TV screen like they're eventually proposing for OLEDs?
I've been following e-ink for at least 4 years now. This kit is not new, it has been around for at least 2 years. How is this news?
/.
--
Then again. It's not news until it's on
twice.
You can't handle the truth.
1000 ms (grayscale mode) 500 ms (1-bit mode)
I've seen figures of around 0.5-1.0 seconds per pixel full addressing for these type of displays. :)
o ws_electronic_paper_potential_052301.html
Whilst not quick enough for movies (as you point out), would be perfectly acceptable for virtual paper
heres a link to an article mentioning the 1second refresh
http://www.trnmag.com/Stories/052301/Prototype_sh
"In addition, although the transistors allow a switching speed of about 2.5 milliseconds, the total time for an image to change smoothly is about one second; typical LCD's pixels are refreshed 70 times a second. "Currently the electronic ink, and not the transistors, limit the speed,"
liqbase
Wait...are you saying we don't have to FAX our comments in to /. any more?
What gives? Does the E-ink display really look so bad? Or is it just a bad photo for the dev kit?
There are a few advantages of E-ink displays over other displays, and unfortunately they're not going to really be visible in a picture. The first is contrast: the contrast can be made very, very good since the ink can be very dark, and the background very light. Much, much higher than LCDs.
The second is no backlighting. Now, this might not sound all that useful, because the first-generation GBA wasn't backlit, and that wasn't all that good, but E-ink's contrast is high enough that you don't need a backlight. Even just a small reading lamp is going to be easily enough to read by. This is the "easier on the eyes" part, and it's the one thing that current displays can't really compete with.
The third is battery life: since you don't need power to maintain the display, only to change it, the battery life is going to be measured in pages, not in time. For an e-book reader, this is perfect, because you can take as long as you want to read it. I wouldn't be surprised if a production e-book reader based on e-ink only turned on whenever you pushed a button.
There are other benefits (resolution's a biggie, but it doesn't look that great with this model, plus it's an image that's actually there, which means that it'll look good in all lighting and all angles) but I think those three are probably the biggest for the current generation.
The biggest limitation to E-ink right now is its refresh time (~ of order a second per page, or 1 fps) and its cost. But still, it's the only product which really has specifications which seriously compete with paper.
Sigh.
Quoted "constrast ratio" for active screens is not the same as the actual viewed contrast ratio of the LCD. That's the contrast ratio of the emitted white sections over the emitted black sections. But that's not what the eye sees, because it sees "emitted+reflected". The true contrast ratio of an active LCD varies with lighting conditions. It can be very very high in dark rooms (100:1, 500:1, etc.), but will be very very low in any sort of lit room. Outside, it'll probably be near 1:1 - i.e., unviewable. Much lower than that 100:1, 500:1. More like 4:1, or lower, in normal viewing conditions.
The contrast ratio of an E-ink display is about 10:1. Moreover, the E-ink display has about a 40% reflectance (as opposed to a 4% reflectance for LCDs), which means it's much brighter too.
CRTs have the same problem. They quote a 3000:1 contrast ratio, but the black and white sections have virtually the same reflectivity, which means that that contrast ratio only applies when the light in the room is much less than the light emitted from the CRT.
If you want to compare passive and active displays, you have to do it equally. In the same viewing conditions. Most people I know don't work inside pitch black offices.
and simple lambertian demands limit the reflectivity of the white areas (its no mirror, you know?)
E-ink displays are slightly less white state reflective than newsprint, but not much (40% compared to 60%). They have a much, much higher reflectivity than LCD displays - about 10 times higher (LCDs are 4%). With that high reflectivity, it doesn't take a lot of light for an E-ink display to have a much higher contrast ratio than an active LCD.
Absolutely right.
From my experience, I would say that the main problem of getting people to contribute is that a whole lot of developers seem to think that if someone asks for a feature or complains about a bug, they're whiners. If your response to such contacts is to ignore it, or tell the person to RTFM, or "yes, yes, yes, I know that's a problem, we've had 50 other reports of that, why can't you look over the other bug reports before you report something (you idiot)", then you're the problem.
It takes a LOT of effort for someone to even get to the point of being able to try to submit a bug report or feature request, or even to tell you about a spelling mistake in the documentation. Most people who have even tried have found a cold reception, and have come to the reasonable conclusion that it just isn't worth it. If you really want support from people, make it easy, and be welcoming.
If you don't have an easily searchable bug database, a searchable user forum, a developer's forum that's open for reading, a good FAQ with an active maintainer, don't complain that people aren't helping.
Something that turns off developers from helping out are your choice of language, insistence on a particular platform or development environment or model, coding style, abrasive personalities, and lack of skill. I've looked at a few projects I've been interested in, looked at the code, picked my jaw up off the floor and realized there was no way I could fix any of that code without insulting them, and there was no way I could work on that code base without fixing it up. In one case, it was just easier to take what they had, use it for what I needed it for after fixing it (without worrying about if I could merge my changes back to them) and just ignore the original project after that. I didn't even bother tracking it.