E-inks are fundamentally analog, so theoretically you could have as many shades of gray as your timing resolution allows, but basically all the commercial controllers available abstract the display as a dumb framebuffer so you can't really access their fundamental operation of "make this pixel slightly whiter or darker.
That depends on what you exactly mean by "controller". The hardware controller typicaly has capability of exposing selected pixels to essentially arbitrary voltage level for specified amount of time and the framebuffer abstraction happens on the driver level.
The majority of dev kits and modules available abstract away that level and provide something not unlike a regular LCD where you just send it raster images; the driving waveforms etc. which are needed to do effects like this are abstracted away, and the details are kept secret.
Any examples? I've only played with Waveshare screens/drivers a little, but I'm pretty sure I saw the LUTs defining voltage levels and times on the "user side", e.g. within the examples code. And from a YT video that shown how to drive those screens at 3FPS (didn't try it myself yet), I assume those are the actual LUTs that convert abstractions into voltage control.
So many (all?) do this dumb thing on a page update where they write all black and all white several times then write the image. There can't be a good reason for that - they can also put up a dialog popup and erase it without all that drama! Its like they all took the demo driver and shipped it
The full black/white is to "cleanse" --- since the material itself is stateful, pixels will drift slightly after several writes and cause ghosting/graininess if you don't eventually reset them all to a known state. It doesn't have to happen on every refresh, however.
I got a kobo aura one (cracking bit of kit) for christmas, it doesn't have the prounounced flash to white then load at all, it's near instant.
Also 300ppi is the sweet spot on an 8" display it's basically a near perfect paperback analogue and has a blue to orange backlight shift keyed to time of day.
I've been experimenting with epaper recently, controlled by an ESP8266 device. The following (short) video shows a full-refresh of an image loaded over HTTP:
On a Kindle Paperwhite it is an option called Page Refresh under your Reading Options. It'll occasionally do a wipe, for example when a page has images but not not often enough to be annoying.
I don't have the Paperwhite, but this option was present on earlier models too. I found it more annoying to have inconsistent page turn latency than to have consistently slow page turns.
My partner and I both got a Kobo, we're very happy with it. We use Calibre to manage our collection. Haven't tried DeDRM yet though. I got the Kobo Aura ONE, and she's got the Kobo Aura H2O. I actually prefer the 6.8" yes it is smaller but it lays better in the hand and is easier to take with you (fits better in the pocket). Its also about 50 EUR cheaper.
Some disadvantages: macOS doesn't have always recognise the device, it has 2.4 GHz WiFi only (put if off to save your battery). The Kobo's also have that screen refresh feature btw you can reduce its effectiveness if you're reading a lot.
Immediately after you bought it, check out the coating of the screen very carefully. I send one ONE back because it had a minor damage to the coating which caused bleeding. I found that distracting, YMMV. The 2 devices got it as well, but less severe and it depends on how you hold the device whether you notice it.
I have Onyx Boox Darwin 4 with hi-res display (6" at 1448x1072). I'm happy with it after 3 previous e-books: sharp display, built-in light, touch, stock android with Google Play, 2 cores, 8GB flash. The only misfortune is lack of my native language in UI.
It has 8 GB how is that not enough in between charges?
Kobo and Amazon don't contain *SD options but other e-readers do [1].
As insinuated, I find it is overrated. You can even run Calibre in Docker [2] to serve it over HTTP(S). And as you know, Kobo have a web browser. So you could put the books you're likely to read on your Kobo (8 GB is a lot) and serve the rest via that way. You could also serve the content over your phone via USB OTG.
If you're off the grid for a long time, I actually recommend something else instead: put your smartphone off, e-reader on, and keep a (at your option relatively, to <3 your battery) charged powerbank with you. Not necessarily for your smartphone, but for your e-reader!
I know some publisher's don't use DRM (like Tor). I was wondering if maybe Kobo had licensed Amazon's DRM for the newer DRM that doesn't have a crack yet (as far as I know, but I haven't checked in a few months).
I got a reMarkable as part of the original lot of buyers. Haven't had quite as much time to use it as I'd like but can summarize:
-would like a little better contrast on the screen, though it does seem roughly on par with kindles and the like with lighting off
-epub generally works well
-full size (ie, letter) pdfs do require cropping unless your vision is superior. The on-device crop is fine for text only pdfs but recommend using an external cropper for pdfs that have charts. Going this route has made it possible to read Reviews of Moder Physics on the reMarkable without the need to squint.
-it could use a 20% speed bump. Some of this might be achieved in future software updates.
You can, of course, use it for its other intended purposes - note taking and draw/sketching.
That's pretty neat to see! ePaper displays are now starting to become quite affordable. I recently bought a 400x300 pixel display for about €25.
Unfortunately my device has only "black & white", no shades of gray at all, but I had a lot of fun working out how to drive it from a small MCU, without running out of RAM.
You can get 800x600 6" displays for that price, intended as eBook reader replacement parts; a while ago someone figured out how to drive them without the official controller:
Unfortunately my device has only "black & white", no shades of gray at all
That's because it's a module with its own controller for producing the display driving waveforms from the 1bpp data that you feed it --- but if you disassemble the module and figure out how to drive the display itself (it's probably not unlike the link above), you could get grayscale too. In addition, you could probably stream from network to display with almost no buffering, by clocking the data directly into the display as it's received over the network (although you'd have to clear each line before drawing it; unlikely to be very difficult, in any case.) Also, refresh as fast or slow as you want.
I've recently picked up a e ink display with a simple passive interface board (bc Im not used to working with flex cable yet) and realized that a popular way to build the frame in the mcu memory then dump it to the board. Most hobby mcus like the atemga328p have enough static memory to store whole frames of images and then push the whole image to the display, but don't have enough dynamic memory of you want to dynamicly render whole frames and then dump them. So I think that's what you are referring to when you said your trying to figure out how render the frames without running out of memory. My screen had example code that would draw frames an push small windows of image data to the screen to draw the different parts of a complete image.
The reason I bring this up is because I recently had the idea of using small SPI flash memory chips to render the whoel.inage frame dynamicly. The SPI memory chips look like a neat way to easily do this by hooking one up to a small mcu and drawing the frame using the spi memory chop then dumping the whole frame from the memory chip to the screen. I hope to oder some small DIPs soon to experiment with and I thought it also might interest you as well.
I'm not clear by what you mean; I'm new to the eink hardware scene and I don't know a lot about graphics rendering or how duble buffering works. It seems that from my understanding that you transfer the parts memory frame from the mcu to the memory on the eink display driver then you call the display driver to update the display and run the LUT tables and analog signals to do the stuff with the ink based on the current memory on the eink driver. However I am probably not right in some regards because not all eink displays have drivers and this process might not be case for all eink displays or I'm just misunderstanding how it works.
Is this "transflective" concept and technology dead now (commercially, R&D, etc.)? For a long time, I was waiting for a responsive display that I could read like a piece of paper.
While I have not been following in detail anymore, I have not come across anything significant.
Note though that making it paper-like requires just a reflective display. Transreflective is needed only when it also needs to function as an emmissive display or needs a backlight.
Reflective displays suffer from poor colors as the pixels get divided into RGB areas, which is contrasting with a color print because the printer can put any color ink anywhere. This is the reason E-Ink, and every other reflective display has found it hard to develop good color.
I have longed for a responsive color, paper-like display for long also.
Mirasol was one promising technology for that (latest demos could get excellent colors as it also did not need to subdivide pixel area into different colors, as colors were created using interference). However, there is no activity on mirasol for the last several years.
The Yota phone has an e-ink display on the back. I got the impression OP was talking about stacked displays. I can't see why that wouldn't be possible.
I recently got a Waveshare 4.2" e-paper for my Pi, and I've been playing around with a variety of dithering algorithms to get it to display images.
The Floyd-Steinberg algorithm seems to bring out the most detail if you look at the image from a distance, but ordered dithering (with the 8x8 Bayer matrix from Wikipedia) gave me a better "retro computer" look that I was aiming for.
I thought the market would have made more progress by now.
I believe the reason is that there are a lot of patents/IP around the core technology, and it's owned by very few companies who essentially have a monopoly on the market. This also explains the secrecy surrounding the "low-level" details. As this article shows, you can definitely get more gray levels by driving the display directly.
From past examples, we will likely not see any real innovation in this space until these patents expire. It's especially disheartening to me since I'll probably be too old to get in on the action by then.
I hope societies reevaluate the role of patents in the advancement of human technology. From my perspective, patents do more harm then good. They encourage rent-seeking. They're impractical to use legally unless you have enough money. They hold back technology for a couple of generations each time a new breakthrough is discovered (as has happened with capacitive touch screens, 3D printers, and is happening now with e-ink displays).
To me, patents are achieving the opposite of their intended purpose.
