Register Guidelines E-Books Search Today's Posts Mark Forums Read

Go Back   MobileRead Forums > E-Book General > News

Notices

Reply
 
Thread Tools Search this Thread
Old 04-15-2008, 09:08 PM   #16
DaleDe
Grand Sorcerer
DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.
 
DaleDe's Avatar
 
Posts: 9,538
Karma: 4597554
Join Date: Aug 2007
Location: Grass Valley, CA
Device: EB 1150, EZ Reader, Literati, iPad 2
Quote:
Originally Posted by msundman View Post
The flashing is to prevent ghosting in the display (and I'm sure it's the controller that does it, not the actual display), so it'll stay until eink creates better displays (although it might be optimized so that not the whole screen flashes, just the changing parts).
I would think that a flash to white would be less objectionable than the flash to black. I wonder if a controller could be made that does this.

Dale
DaleDe is offline   Reply With Quote
Old 04-15-2008, 10:05 PM   #17
Dylrob
Murderous Mustela
Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.
 
Dylrob's Avatar
 
Posts: 6,760
Karma: 15708532
Join Date: Oct 2006
Location: Where I do.
Device: iPhone 5c & Kindle Fire HD
Quote:
Originally Posted by DaleDe View Post
I would think that a flash to white would be less objectionable than the flash to black. I wonder if a controller could be made that does this.

Dale
The screens do not appear to flash specifically to black. Rather they "invert". It only seems to go black because there are far more white pixels on your average page.

Last edited by Dylrob; 04-15-2008 at 10:14 PM. Reason: minor rewording
Dylrob is offline   Reply With Quote
Old 04-16-2008, 12:54 AM   #18
DaleDe
Grand Sorcerer
DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.DaleDe ought to be getting tired of karma fortunes by now.
 
DaleDe's Avatar
 
Posts: 9,538
Karma: 4597554
Join Date: Aug 2007
Location: Grass Valley, CA
Device: EB 1150, EZ Reader, Literati, iPad 2
Quote:
Originally Posted by Dylrob View Post
The screens do not appear to flash specifically to black. Rather they "invert". It only seems to go black because there are far more white pixels on your average page.
Thanks, that gives me something to think about.

Dale
DaleDe is offline   Reply With Quote
Old 04-16-2008, 03:54 AM   #19
astra
The Introvert
astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.
 
astra's Avatar
 
Posts: 8,308
Karma: 1000077497
Join Date: Jan 2007
Location: United Kingdom
Device: Sony Reader PRS-650 & 505 & 500
Dunno about black/white but I find flashing of prs-500 a lot more pleasant than of prs-505 (unfortunately).
astra is offline   Reply With Quote
Old 04-16-2008, 06:00 AM   #20
sanders
Connoisseur
sanders has learned how to read e-bookssanders has learned how to read e-bookssanders has learned how to read e-bookssanders has learned how to read e-bookssanders has learned how to read e-bookssanders has learned how to read e-bookssanders has learned how to read e-bookssanders has learned how to read e-books
 
Posts: 66
Karma: 918
Join Date: Dec 2007
Device: iRex Iliad
Quote:
Originally Posted by msundman View Post
The OS is orthogonal to the issue. You probably meant to ask: "Isn't all of that done by software on more general purpose hardware?" That's a good question, and IMO that's what should have been done since the first prototypes. After the software is done and tested and devs have figured out which functions they need, and after profiling everything to see what takes most time when it matters most and what consumes most power in which usage scenarios, only then should you optimize your hardware. But epson probably thinks it's more important to create many revisions of those chips (for lots and lots of money, of course) than to help the devs working on them by making things better sooner.
Perhaps you need to read this press release with a grain of "marketing salt" in mind.
It would be very beneficial if the controller supported arbitrary sub-area refreshes, and a few of those areas in parallel perhaps. For the first uses of e-Ink displays, it probably wasn't a big deal that you update the whole screen at once since you'd probably be displaying a whole new page anyway.
Since it turns out that people want to use the displays for popup menus and even typing or scribbling, having partial screen updates is the next logical thing to implement.

I noticed that in the iLiad displayManager there is an API for partial screen updates which is "not implemented", yet the scribble library offers "fast point updates" by directly talking to the driver. Perhaps some of the functionality is already in the current hardware.
sanders is offline   Reply With Quote
Old 04-16-2008, 06:17 AM   #21
searcher
Connoisseur
searcher has a complete set of Star Wars action figures.searcher has a complete set of Star Wars action figures.searcher has a complete set of Star Wars action figures.searcher has a complete set of Star Wars action figures.
 
searcher's Avatar
 
Posts: 58
Karma: 344
Join Date: Dec 2007
Device: Sony PRS-500, PRS-505
Quote:
A new electronic paper display could allow users to annotate pages in electronic books, make amendments to documents and erase parts of the page with as much ease as using a real pen and paper.

The screen, on show Wednesday at the Display 2008 exhibition in Tokyo, was developed by E-Ink, Taiwan's Prime View International and Japan's Seiko Epson. It combines a conventional electronic paper display with a touch panel and a newly developed control chip.

The chip, from Seiko Epson, can control a screen with up to four times the resolution of current "writable" e-paper devices such as iRex Technologies' iLiad.

Seiko Epson's chip also refreshes the display faster than the iLiad can, eliminating the slight lag between movement of the stylus and its effect on the screen.

The new chip shortens the update time so the screen can be refreshed 50 times per second. That means lines appear on the screen as they are drawn by the user and interpreted by the touch-panel interface, said Akihiro Furuya of Seiko Epson's semiconductor operations division, who demonstrated the system.

The prototype screen and controller board on show at the Display 2008 expo allowed users to drawn on printed pages with a black, grey or white pen. With black text on a white page the white pen had the effect of acting as an eraser.

The chip supports a screen of up to 2,048 pixels by 1,536 pixels and will be available commercially from August.

Electronic paper is often lauded for its high contrast that makes it appear close to that of real paper. Under development for many years the technology is now being used in commercial displays such as those in Amazon.com's Kindle e-book reader, Motorola's F3 cell phone and numerous in-store advertising displays
http://www.pcworld.com/businesscente...eal_paper.html
searcher is offline   Reply With Quote
Old 04-16-2008, 07:15 AM   #22
Dylrob
Murderous Mustela
Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.Dylrob ought to be getting tired of karma fortunes by now.
 
Dylrob's Avatar
 
Posts: 6,760
Karma: 15708532
Join Date: Oct 2006
Location: Where I do.
Device: iPhone 5c & Kindle Fire HD
Quote:
Originally Posted by searcher View Post
Quote:
...
The new chip shortens the update time so the screen can be refreshed 50 times per second. That means lines appear on the screen as they are drawn by the user and interpreted by the touch-panel interface, said Akihiro Furuya of Seiko Epson's semiconductor operations division, who demonstrated the system.
...
Now this part I'm a little confused on. I thought that at least part of the reason for eInk's slow refresh rate was because of the resistance of the "ink" particles to move though the fluid that they're suspended in?

Last edited by Dylrob; 04-16-2008 at 07:16 AM. Reason: typo
Dylrob is offline   Reply With Quote
Old 04-16-2008, 08:00 AM   #23
seamusfp
Enthusiast
seamusfp has a complete set of Star Wars action figures.seamusfp has a complete set of Star Wars action figures.seamusfp has a complete set of Star Wars action figures.seamusfp has a complete set of Star Wars action figures.seamusfp has a complete set of Star Wars action figures.
 
Posts: 43
Karma: 432
Join Date: Nov 2006
Location: Connecticut
Device: Sony PRS-500
Quote:
Originally Posted by Dylrob View Post
Now this part I'm a little confused on. I thought that at least part of the reason for eInk's slow refresh rate was because of the resistance of the "ink" particles to move though the fluid that they're suspended in?
You should be confused because that's marketing speak, or a confused tech journalists. The "electronic" refresh rate of the current panels and controllers is 50Hz, that being said, it takes several passes at 50Hz to get where you need to.
seamusfp is offline   Reply With Quote
Old 04-16-2008, 10:49 AM   #24
msundman
Zealot
msundman has a complete set of Star Wars action figures.msundman has a complete set of Star Wars action figures.msundman has a complete set of Star Wars action figures.
 
Posts: 103
Karma: 269
Join Date: Aug 2006
Device: FBReader on Android
Quote:
Originally Posted by sanders View Post
It would be very beneficial if the controller supported arbitrary sub-area refreshes, and a few of those areas in parallel perhaps. [...] Perhaps some of the functionality is already in the current hardware.
And my point was that of course those features are beneficial, but they should be implemented in software first (and that they should have been implemented in software years ago). Putting stuff in hardware is a form of optimization, and premature optimization is usually suboptimal at best and very counter-progress at worst.
msundman is offline   Reply With Quote
Old 04-16-2008, 11:41 AM   #25
seamusfp
Enthusiast
seamusfp has a complete set of Star Wars action figures.seamusfp has a complete set of Star Wars action figures.seamusfp has a complete set of Star Wars action figures.seamusfp has a complete set of Star Wars action figures.seamusfp has a complete set of Star Wars action figures.
 
Posts: 43
Karma: 432
Join Date: Nov 2006
Location: Connecticut
Device: Sony PRS-500
Quote:
Originally Posted by msundman View Post
And my point was that of course those features are beneficial, but they should be implemented in software first (and that they should have been implemented in software years ago). Putting stuff in hardware is a form of optimization, and premature optimization is usually suboptimal at best and very counter-progress at worst.
Software, particularly software on mobile processors is not going to be able to keep up and provide adequate response. E Ink does not respond like an LCD, a lot more information needs to be known, kept track of, and processed.

As well, this isn't "premature optimization", this is the result of many years of research, engineering, and refinement. As I said before, I've seen what this controller is capable of, and I am certain this could not be achieved in software on a mobile device.
seamusfp is offline   Reply With Quote
Old 04-16-2008, 12:21 PM   #26
msundman
Zealot
msundman has a complete set of Star Wars action figures.msundman has a complete set of Star Wars action figures.msundman has a complete set of Star Wars action figures.
 
Posts: 103
Karma: 269
Join Date: Aug 2006
Device: FBReader on Android
Quote:
Originally Posted by seamusfp View Post
Software, particularly software on mobile processors is not going to be able to keep up and provide adequate response.
That's pure hogwash. Eink is so incredibly slow at the moment that I'm sure even slow microcontrollers could handle it with only small amounts of custom h/w. (Well, at least the smaller displays, not necessarily a 2048*1536 one.)

Quote:
Originally Posted by seamusfp View Post
E Ink does not respond like an LCD, a lot more information needs to be known, kept track of, and processed.
Unless it's several tens of bytes per pixel (and I'd be surprised if it was) then I don't see a problem.

Quote:
Originally Posted by seamusfp View Post
As well, this isn't "premature optimization", this is the result of many years of research, engineering, and refinement.
Really? So eink has given s/w libs to app devs to use when implementing their apps, and then eink has listened to their responses? Or has eink just done internal testing and tried to figure out what app devs might wish for? The latter approach has time and again failed miserably.

Quote:
Originally Posted by seamusfp View Post
I've seen what this controller is capable of, and I am certain this could not be achieved in software on a mobile device.
I'm sorry, but that's maybe the most clueless statement I've ever seen, and is right up there with Gate's "640k should be enough for everybody". The least you could do is add an "[...]using any currently available, GP CPUs/microcontrollers." or somesuch.

Still, that's beside the point. I've myself designed libs that did amazing things, yet it turned out that the devs wanted to do completely different things, for which my lib wasn't at all optimized or even designed for in the first place. The point is, you really don't know what the app devs will want before they actually want it. And even then much of it actually turns out to be wrong, since they often don't even know it themselves before they've implemented their stuff. Some stuff you can predict with a high level of certainty, but surprisingly much you can't. Therefore you want as much flexibility as possible as late in the game as possible. Committing optimizations to hardware before having all app devs try different software versions of it is not being flexible. It works to some degree for "old" fields, such as CPU, or even GPU, designers (but even there we've seen many, many failures), but not so much for new stuff like e-book interfaces on slowly refreshing displays.
msundman is offline   Reply With Quote
Old 04-16-2008, 12:32 PM   #27
astra
The Introvert
astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.astra ought to be getting tired of karma fortunes by now.
 
astra's Avatar
 
Posts: 8,308
Karma: 1000077497
Join Date: Jan 2007
Location: United Kingdom
Device: Sony Reader PRS-650 & 505 & 500
So very complicated...
Anyway, just to dilute the tech discussion, I would like to say that I expected this announce or something similar.
Last year, around the same time viziplex was announced that allowed eInk readers to make a new generation model. I though, that if something like that doesn't happen, how will they justify a new model (which is faster, better, whiter, sweeter, ...etc., you get the general idea?).

Here we go, a new controller, means we get new generation readers soon and will spend more money for a whiter/faster/better brand new eInk screen with a super duper new controller.

They know very well what they are doing
astra is offline   Reply With Quote
Old 04-16-2008, 01:09 PM   #28
pilotbob
Grand Sorcerer
pilotbob ought to be getting tired of karma fortunes by now.pilotbob ought to be getting tired of karma fortunes by now.pilotbob ought to be getting tired of karma fortunes by now.pilotbob ought to be getting tired of karma fortunes by now.pilotbob ought to be getting tired of karma fortunes by now.pilotbob ought to be getting tired of karma fortunes by now.pilotbob ought to be getting tired of karma fortunes by now.pilotbob ought to be getting tired of karma fortunes by now.pilotbob ought to be getting tired of karma fortunes by now.pilotbob ought to be getting tired of karma fortunes by now.pilotbob ought to be getting tired of karma fortunes by now.
 
pilotbob's Avatar
 
Posts: 19,509
Karma: 11248282
Join Date: Jan 2007
Location: Tampa, FL USA
Device: Kindle Touch
Quote:
Originally Posted by seamusfp View Post
You should be confused because that's marketing speak, or a confused tech journalists. The "electronic" refresh rate of the current panels and controllers is 50Hz, that being said, it takes several passes at 50Hz to get where you need to.
I'm sorry... are you talking about eInk? If so, there is no "refresh rate" at all. A refresh rate is how many times per second the image is resent to the device to maintain the image and generaly refers to CRT displays. eInk is a static display. Once the image is drawn it does not need to be refreshed. This is why eInk devices have such great battery life.

BOb
pilotbob is offline   Reply With Quote
Old 04-16-2008, 01:11 PM   #29
seamusfp
Enthusiast
seamusfp has a complete set of Star Wars action figures.seamusfp has a complete set of Star Wars action figures.seamusfp has a complete set of Star Wars action figures.seamusfp has a complete set of Star Wars action figures.seamusfp has a complete set of Star Wars action figures.
 
Posts: 43
Karma: 432
Join Date: Nov 2006
Location: Connecticut
Device: Sony PRS-500
Quote:
Originally Posted by msundman View Post
That's pure hogwash. Eink is so incredibly slow at the moment that I'm sure even slow microcontrollers could handle it with only small amounts of custom h/w. (Well, at least the smaller displays, not necessarily a 2048*1536 one.)


Unless it's several tens of bytes per pixel (and I'd be surprised if it was) then I don't see a problem.
You'd be surprised... prior state information, temperature compensation, waveform, etc. If the device is already going to be sluggish because of the displays rate, I'd rather not have it additionally bogged down keeping track of 0.5 million pixels and clocking out (~800x600) every 20ms.

Not to mention most embedded processors have an LCD controller of some sort, so it's not like this is an unheard of even for simplier display technologies
http://www.intel.com/design/embedded...ors/302302.htm look at that, an LCD controller built right on the die of the processor. This sort of controller is largely abstracted from the developer as just putting data into the frame buffer.

Quote:
Originally Posted by msundman View Post
Really? So eink has given s/w libs to app devs to use when implementing their apps, and then eink has listened to their responses? Or has eink just done internal testing and tried to figure out what app devs might wish for? The latter approach has time and again failed miserably.
This device went through an extensive beta program with many device manufactures, and yes, feedback.

Quote:
Originally Posted by msundman View Post
I'm sorry, but that's maybe the most clueless statement I've ever seen, and is right up there with Gate's "640k should be enough for everybody". The least you could do is add an "[...]using any currently available, GP CPUs/microcontrollers." or somesuch.
Fair enough, but since we are talking devices which would be released in the near future, the current hardware was implied.

Quote:
Originally Posted by msundman View Post
Still, that's beside the point. I've myself designed libs that did amazing things, yet it turned out that the devs wanted to do completely different things, for which my lib wasn't at all optimized or even designed for in the first place. The point is, you really don't know what the app devs will want before they actually want it. And even then much of it actually turns out to be wrong, since they often don't even know it themselves before they've implemented their stuff. Some stuff you can predict with a high level of certainty, but surprisingly much you can't. Therefore you want as much flexibility as possible as late in the game as possible. Committing optimizations to hardware before having all app devs try different software versions of it is not being flexible. It works to some degree for "old" fields, such as CPU, or even GPU, designers (but even there we've seen many, many failures), but not so much for new stuff like e-book interfaces on slowly refreshing displays.
Yes, I agree that there is a chance of omitting things that would be useful, and including things that may not be needed. But I've seen this in action vs current controllers vs (unoptimized) software. I'm just trying to say that you may be overly pessimistic. The development has included feedback from the current gen, as well as feedback from a beta program.
seamusfp is offline   Reply With Quote
Old 04-16-2008, 02:04 PM   #30
msundman
Zealot
msundman has a complete set of Star Wars action figures.msundman has a complete set of Star Wars action figures.msundman has a complete set of Star Wars action figures.
 
Posts: 103
Karma: 269
Join Date: Aug 2006
Device: FBReader on Android
Quote:
Originally Posted by seamusfp View Post
You'd be surprised... prior state information, temperature compensation, waveform, etc. If the device is already going to be sluggish because of the displays rate, I'd rather not have it additionally bogged down keeping track of 0.5 million pixels and clocking out (~800x600) every 20ms.
You're writing some kind of pixel data for all pixels on the screen at 50 fps on an eink display? Seems unlikely.
Also, what you described takes neither memory (1-4 bytes/pixel seems enough) nor time (small LUTs seems enough).

Quote:
Originally Posted by seamusfp View Post
Not to mention most embedded processors have an LCD controller of some sort, so it's not like this is an unheard of even for simplier display technologies
Yes, of course you need some kind of frame buffer or blitter or whatever. My point was that this custom chip should be as generic as possible instead of implementing specific high level concepts such as menus or whatever. At least until it's been shown exactly which things are too slow (or takes too much power) to do in software without specific hardware-acceleration.

Quote:
Originally Posted by seamusfp View Post
This device went through an extensive beta program with many device manufactures, and yes, feedback.
Well, at least it's good to know they didn't just do internal testing.

Quote:
Originally Posted by seamusfp View Post
Yes, I agree that there is a chance of omitting things that would be useful, and including things that may not be needed.
Not only that, but having certain very specific things optimized might steer the way of the future development into a bad direction. The recovery of such a thing often takes lots of time (but might make some company lots of money), during which the endusers will have to endure needlessly bad readers. I'm very pro-enduser, so I tend to criticize things that might be bad for endusers (even when I'm part of the dev team and thus get to suffer the heat of my own criticism).

OTOH, the optimizations might turn out to be very good, and in that fortunate case => happy happy joy joy

Last edited by msundman; 04-16-2008 at 02:12 PM.
msundman is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Epson Controler for Color E Ink wallcraft News 2 08-01-2010 11:02 AM
Epson and E Ink Announce a New EPD Controller Jason News 3 10-11-2009 11:00 PM
Display or controller damaged netseeker Sony Reader 16 01-08-2009 09:10 AM
Seiko Epson produces hi-res E Ink display Alexander Turcic News 38 11-23-2007 12:00 PM
Next E Ink e-reader from Epson? (speculation) TadW News 4 04-14-2007 03:25 PM


All times are GMT -4. The time now is 06:34 AM.


MobileRead.com is a privately owned, operated and funded community.