iLiad Introducing the new Sony-Reader-speed ipdf - Page 3

kusmi · 10-27-2006, 07:45 AM

I think so too: Making things configurable should be the *last* resort, not the first one... if iRex can make pdfs rendering fast and nice, there is no need to have an user-configurable option...

just my 2 cents...

arivero · 10-27-2006, 08:42 AM

Quote:

Originally Posted by Matthijs

You should understand that the iLiad does a linear conversion from 256 grey levels to 16 grey levels on a device-driver level (so the first 16 levels of grey become white, etc.).

Ah, that was the improvement letting iRex to use the X server with the framebuffer. Xserver crashs heavily when you attempt to play with (theoretically implemented) less than 8-bits levels. In the librie the only working xserver was the xvfb, the virtual framebuffer, and I was forced to take screenshoots of the virtual one and transfer to the real.

scotty1024 · 10-27-2006, 09:25 AM

The technical term for what is occurring is posterization you can read more about it here: http://www.cambridgeincolour.com/tut...terization.htm .

The various error distribution schemes (Floyd, bi-cubic) work in a manner similar to MP3, except for the eyes instead of the ears. They attempt to hide the loss of data through perceptual tricks. The various methods work better with some documents than with others and their effectiveness various from one person to the next.

One thing though is generally accepted: using any of them on text glyphs is not a "good thing".

As others here had already commented upon elsewhere here, text in PDF's was at times not looking too sharp on the iLiad. When I removed the error distribution I immediately noticed the extra sharpness. After one struggles as hard as I did to get a working unit one tends to try and think more fondly of his sickly device eh what?

Rather than applying error distribution, which for black text there are no errors needing to be distributed (but we find something to distribute anyway

) these methods should be applied where they make the most sense: on images.

Everyone needs to keep in mind what happened yesterday. I took a cold toolchain, got it working, took a cold tar ball and got it to compile. I then walked into that cold source and found a big flashing sign that read "big bottle neck right here". The source didn't say "This code is sub-optimal because we found trying to render to 8 bit grey scale resulted in the following ...."

I fixed the bottle neck, then popped out two more revisions.

Yes I noticed some things were better, in particular some scanned magazines I have looked much better. But other scanned items looked worse. I also noticed that these issues seemed to track with the compression method being employed.

I marked this one down for "further investigation", because as others have already commented: when you go from 16.7 million colors down to 16 (1 million to 1), some things just aren't going to look right.

I've had an iLiad benchmark I've been calling the Jack Rabbit Benchmark. Its a PDF of a menu from a local catering outfit. Performance of this simple two page document on the iLiad can kindly be described as "sub-optimal". In the process of fixing this document's performance issues I believe I will turn up the source of some of the image issues.

I think I'm going to find that poppler has some "growth opportunities" in its code when it comes to rendering images into 8bpp grey.

Can I create a faster error distribution routine for the iLiad? You bet, I'll get out my PXA-255 manual and throw some wireless MMX opcodes into the code to speed it up nicely. But I only want to apply that to images, not glyphs.

In the mean time no one is paying me to work on this stuff: I owe, I owe, its off to work I go...

CommanderROR · 10-27-2006, 09:55 AM

So you do have a job as well...I was wondering...:-)

If you can create an "adaptive" routine that applies the correct "downsampling" for images and leaves text alone then all the better.
I was wondering about the bad text-sharpness ever since I read the Iliad in really bright (sun-)light for the first time wher eis was very visible. I thought it was due to some suboptimal anti-alias thing...

I really hope you and/or iRex will find a way to improve sharpness, page-turn speed and retain image quality (for those who need it) all in one package...and I wish you all the luck you're going to need.

At the moment I really envy you coders out there...but on the other hand...it#s nice to sit back and watch others work...

Matthijs · 10-27-2006, 10:59 AM

I'm sure that with some collaboration, we will be able to fix the rendering of pictures in the poppler library, after which the switch to use 8bit grey internally is a logical one.

I merely wanted to point out to the others that it might be a little longer before this turns up in a release version, we need to fix the issue with images first.

That being said, I will send Scotty some more info via email. Just in case he gets bored this weekend

Mambo · 10-27-2006, 12:45 PM

Quote:

Originally Posted by kusmi

I think so too: Making things configurable should be the *last* resort, not the first one... if iRex can make pdfs rendering fast and nice, there is no need to have an user-configurable option...

just my 2 cents...

Sure,

But consider that I have a lot of scanned pdf files - you could have too - and I don't need a fancy algorythm to do the deposterisation, because those are text only (even if scanned in colour, etc.)So the computer will be able to differentiate between scanned text and real images? No way, that is my two cents...

So please Irex, rather give user-configurable option, and I don't think it should be the last step in development otherwise it will never be ready, because a software is never ready.
And if you can not add economically features to the existing settings application then I suppose a new settings application could be easily added or something
(or what about an icon saying: draft mode?)
I am also developing software and never found difficult to add 1 or 2 more tickboxes or something.

Otherwise there are less user-configurable options on the iLiad than on an average mobile phone, do you think this is right? Everybody truly thinks that the system should be developed for dummies only? (sorry for the word) And what about the rest? shall we suffer just because others are not able to reset their devices and go back to default settings? Is it democratic to give no options to the user at all? Is it politically correct?
I don't understand the philosophy behind it, if you give an option somewhere in the settings it will help some people, while it does not take ANYTHING away from other people so why do they complain?

Why should you optimalize an algorythm to work faster, when in most of the time you don't actually need the deposterizer algorythm, so you could just switch it off. There will be always situations when you can not eliminate the trade off between nice rendering and fast rendering.
Also you could save valuable devlopment time for something else (Power management?) and/or produce an earlier update IMHO.

k2r · 10-27-2006, 02:04 PM

Quote:

Originally Posted by Mambo

And if you can not add economically features to the existing settings application

You don't really want a system wide setting for this but this feature belongs into the PDF-Reader (and the manifest.xml) as do other viewing options (scaling, panning).

And yes - since I depend on books that are images and books that are text, too, I'd be very pleased if we could get this option, soon. It would be much of an improvement.

Now, if besides of compiling the software of my choice I could even use it...

scotty1024 · 10-27-2006, 03:07 PM

I agree, some of these options could go into manifest.xml and the toe tag could be updated to edit those new options.

We could then add several error dispersion routines to choose from for those documents where you need it to look its 16 grey's best.

scotty1024 · 10-27-2006, 03:22 PM

Quote:

Originally Posted by Matthijs

I'm sure that with some collaboration, we will be able to fix the rendering of pictures in the poppler library, after which the switch to use 8bit grey internally is a logical one.

...

That being said, I will send Scotty some more info via email. Just in case he gets bored this weekend

iRex has pointed out several times: its a book reader, not a PDA.

In this case I'm trying to point out: its 16 grey, not 16.7 million color.

The number one priority on a 16 greys eBook reader is glyphs. The text must be impressively sharp and crisp.

If someone comments negatively on a picture you just look at them and say "Hey, 16 greys, they'll have the color one out next year." Heads will nod sagely and go back to admiring the crisp glyphs.

I haven't gotten your email yet, but I found an X drawing speed up to make that I suspect you'll agree is worthy. You can even drop it into the 24bpp ipdf.

Hopefully that'll keep you from being bored this weekend as well.

kusmi · 10-27-2006, 03:30 PM

@Mambo: Look, there are different kind of users (as well as developers :-) ) And I agree, at the moment there is almost *no* configuration on the iLiad, which is also sub-optimal, there should be a balance. Without starting this typical windows/mac/linux comparison thingy, but there you see all the different conclusions about end-user configurability - and of course taste is different - but personally (not generally, this is my personal view on things, as software developer and graphical designer) I don't want a device, with 100 of config-options which pollute the config-screen, if there is a way around this, doing some decent development work.

But of course, there could be some "pro"-settings in the manifest.xml, so advanced users could tune the content, this is fine with me - I would just not bother the standard user with rendering options on the iLiad itself...

DHer · 10-28-2006, 03:20 AM

I finally had a chance to try it. The fonts really look better.

Concerning speed, i can't describe the difference.

Anyway, thank you, scotty. I'm also really looking forward to the djvu viewer.
Maybe i'll fire up the toolchain after breakfast.

deadite66 · 10-28-2006, 03:41 AM

can anyone make a vid of the speed difference?

<- 2.7.1 :<

k2r · 10-28-2006, 05:41 AM

Quote:

Originally Posted by scotty1024

iRex has pointed out several times: its a book reader, not a PDA.

The hardware is clearly capable of being a PDA. And if the SDK comes out finally it's up to us to define "what" our personal iLIad is
Of course it's not up to iRex to develop applications it does not see a market for.
That's the beauty of free software.

Personally I'd really like to have a PIM application on the device.
And an IMAP mailreader.
And better HWR.
One of the interesting parts would be developing a good GUI for all of this.

#!chris

R2D2 · 10-28-2006, 08:30 AM

Excuse me guys and let me give you some out of the box input:

There is a company called Picsel which produces viewers for graphics, HTML, XLS, DOC and PDF for embedded devices. The software, called Picsel Browser, is also available for the Sharp clamshell VGA Zaurus which has hardware very similar to the iLiad:

The software is extremely fast and the display of the files is of a very high quality.
Pan and zoom is no problem at all, regardless of the document format:

click on image to download video...

So why don't you call them and ask them to make a iLiad version of the Picsel Browser (essentialy a simplified, low frame rate version of the existing Zaurus one)? This would have some advantages:

* Rapid and rather inexpensive development, because a Zaurus version does already exist.
* No need for Minimo anymore, because HTML support is already supported by the Picsel Browser. Web-Browsing is also possible.
* No need to create a pan and zoom solution on your own.
* Support for office documents. Not that unimportant in my opinion...
* Extremely high performance rendering.

This approach would be much less dirty than trying to implement all kinds of improvements into the existing open source viewers.

In case that you have never seen the Picsel Browser on Zaurus, you have to see it with your own eyes.
So click onto the above screenshot to download a divx movie I created some time ago.

Sorry for repeating myself. Opinions?

btw.:

Scotty you are either drinking to much coffee or having too much spare time and/or a very understanding wife/girlfriend.
In any way, please continue to do so. ;-) Great, impressive work!!!

CommanderROR · 10-28-2006, 11:14 AM

Is the Picsel Software Open Source or is it it "Payware"?

If it's normal, commerical stuff, then iRex would probably have to get some kind of agreement going with them if they want to include that Software into the Iliad...
Since there is no way for a user to install Software (apart from the hackers way...^^) on the Iliad apart from the IDS, I'm not sure how easy it would be to get something like this growing...and I don't know how much interest the Picsel guys would have in supporting the Iliad either...

10-28-2006, 08:30 AM	#44
R2D2 Mad Scientist Posts: 294 Karma: 242 Join Date: May 2006 Location: Germany Device: Zaurus, HTCMagician, iLiad	Replace xpdf and minimo with something else: Picsel Browser Excuse me guys and let me give you some out of the box input: There is a company called Picsel which produces viewers for graphics, HTML, XLS, DOC and PDF for embedded devices. The software, called Picsel Browser, is also available for the Sharp clamshell VGA Zaurus which has hardware very similar to the iLiad: The software is extremely fast and the display of the files is of a very high quality. Pan and zoom is no problem at all, regardless of the document format: click on image to download video... So why don't you call them and ask them to make a iLiad version of the Picsel Browser (essentialy a simplified, low frame rate version of the existing Zaurus one)? This would have some advantages: * Rapid and rather inexpensive development, because a Zaurus version does already exist. * No need for Minimo anymore, because HTML support is already supported by the Picsel Browser. Web-Browsing is also possible. * No need to create a pan and zoom solution on your own. * Support for office documents. Not that unimportant in my opinion... * Extremely high performance rendering. This approach would be much less dirty than trying to implement all kinds of improvements into the existing open source viewers. In case that you have never seen the Picsel Browser on Zaurus, you have to see it with your own eyes. So click onto the above screenshot to download a divx movie I created some time ago. Sorry for repeating myself. Opinions? btw.: Scotty you are either drinking to much coffee or having too much spare time and/or a very understanding wife/girlfriend. In any way, please continue to do so. ;-) Great, impressive work!!! Last edited by R2D2; 10-28-2006 at 09:02 AM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Sony battery/Speed of Reading	rickstarz	Sony Reader	1	08-28-2010 03:14 PM
iLiad Bionic ipdf: better, faster, stronger than Sony Reader!	scotty1024	iRex Developer's Corner	124	02-01-2009 09:45 AM
store on reader memory or SD for speed/stability	Bierkonig	Sony Reader	1	01-29-2009 08:12 PM
Sony Store: Dial Up: Yes, High Speed: No	MickeyC	Sony Reader	6	12-12-2008 10:00 PM
Sony Reader firmware speed comparison	nathantw	Sony Reader	4	08-06-2008 01:16 PM

10-27-2006, 07:45 AM	#31
kusmi Connoisseur Posts: 73 Karma: 16 Join Date: Jul 2006 Location: Zurich, Switzerland	I think so too: Making things configurable should be the last resort, not the first one... if iRex can make pdfs rendering fast and nice, there is no need to have an user-configurable option... just my 2 cents...

10-27-2006, 09:25 AM	#33
scotty1024 Banned Posts: 1,300 Karma: 1479 Join Date: Jul 2006 Location: Peoples Republic of Washington Device: Reader / iPhone / Librie / Kindle	The technical term for what is occurring is posterization you can read more about it here: http://www.cambridgeincolour.com/tut...terization.htm . The various error distribution schemes (Floyd, bi-cubic) work in a manner similar to MP3, except for the eyes instead of the ears. They attempt to hide the loss of data through perceptual tricks. The various methods work better with some documents than with others and their effectiveness various from one person to the next. One thing though is generally accepted: using any of them on text glyphs is not a "good thing". As others here had already commented upon elsewhere here, text in PDF's was at times not looking too sharp on the iLiad. When I removed the error distribution I immediately noticed the extra sharpness. After one struggles as hard as I did to get a working unit one tends to try and think more fondly of his sickly device eh what? Rather than applying error distribution, which for black text there are no errors needing to be distributed (but we find something to distribute anyway ) these methods should be applied where they make the most sense: on images. Everyone needs to keep in mind what happened yesterday. I took a cold toolchain, got it working, took a cold tar ball and got it to compile. I then walked into that cold source and found a big flashing sign that read "big bottle neck right here". The source didn't say "This code is sub-optimal because we found trying to render to 8 bit grey scale resulted in the following ...." I fixed the bottle neck, then popped out two more revisions. Yes I noticed some things were better, in particular some scanned magazines I have looked much better. But other scanned items looked worse. I also noticed that these issues seemed to track with the compression method being employed. I marked this one down for "further investigation", because as others have already commented: when you go from 16.7 million colors down to 16 (1 million to 1), some things just aren't going to look right. I've had an iLiad benchmark I've been calling the Jack Rabbit Benchmark. Its a PDF of a menu from a local catering outfit. Performance of this simple two page document on the iLiad can kindly be described as "sub-optimal". In the process of fixing this document's performance issues I believe I will turn up the source of some of the image issues. I think I'm going to find that poppler has some "growth opportunities" in its code when it comes to rendering images into 8bpp grey. Can I create a faster error distribution routine for the iLiad? You bet, I'll get out my PXA-255 manual and throw some wireless MMX opcodes into the code to speed it up nicely. But I only want to apply that to images, not glyphs. In the mean time no one is paying me to work on this stuff: I owe, I owe, its off to work I go...

10-27-2006, 09:55 AM	#34
CommanderROR eink fanatic Posts: 2,022 Karma: 4924 Join Date: Mar 2006 Location: Germany Device: STAReBOOK, iRex Iliad, Sony 505, Kindle 2	So you do have a job as well...I was wondering...:-) If you can create an "adaptive" routine that applies the correct "downsampling" for images and leaves text alone then all the better. I was wondering about the bad text-sharpness ever since I read the Iliad in really bright (sun-)light for the first time wher eis was very visible. I thought it was due to some suboptimal anti-alias thing... I really hope you and/or iRex will find a way to improve sharpness, page-turn speed and retain image quality (for those who need it) all in one package...and I wish you all the luck you're going to need. At the moment I really envy you coders out there...but on the other hand...it#s nice to sit back and watch others work...

10-27-2006, 10:59 AM	#35
Matthijs Groupie Posts: 199 Karma: 666 Join Date: Oct 2006 Location: Eindhoven, the Netherlands Device: iLiad, DR1000S, DR800SG	I'm sure that with some collaboration, we will be able to fix the rendering of pictures in the poppler library, after which the switch to use 8bit grey internally is a logical one. I merely wanted to point out to the others that it might be a little longer before this turns up in a release version, we need to fix the issue with images first. That being said, I will send Scotty some more info via email. Just in case he gets bored this weekend

10-27-2006, 03:07 PM	#38
scotty1024 Banned Posts: 1,300 Karma: 1479 Join Date: Jul 2006 Location: Peoples Republic of Washington Device: Reader / iPhone / Librie / Kindle	I agree, some of these options could go into manifest.xml and the toe tag could be updated to edit those new options. We could then add several error dispersion routines to choose from for those documents where you need it to look its 16 grey's best.

10-27-2006, 03:30 PM	#40
kusmi Connoisseur Posts: 73 Karma: 16 Join Date: Jul 2006 Location: Zurich, Switzerland	@Mambo: Look, there are different kind of users (as well as developers :-) ) And I agree, at the moment there is almost no configuration on the iLiad, which is also sub-optimal, there should be a balance. Without starting this typical windows/mac/linux comparison thingy, but there you see all the different conclusions about end-user configurability - and of course taste is different - but personally (not generally, this is my personal view on things, as software developer and graphical designer) I don't want a device, with 100 of config-options which pollute the config-screen, if there is a way around this, doing some decent development work. But of course, there could be some "pro"-settings in the manifest.xml, so advanced users could tune the content, this is fine with me - I would just not bother the standard user with rendering options on the iLiad itself...

10-28-2006, 03:20 AM	#41
DHer Addict Posts: 261 Karma: 156 Join Date: Jul 2006 Device: iliad	I finally had a chance to try it. The fonts really look better. Concerning speed, i can't describe the difference. Anyway, thank you, scotty. I'm also really looking forward to the djvu viewer. Maybe i'll fire up the toolchain after breakfast.

10-28-2006, 03:41 AM	#42
deadite66 Groupie Posts: 197 Karma: 16 Join Date: Apr 2006 Device: irex iliad, uk Kindle gen3	can anyone make a vid of the speed difference? <- 2.7.1 :<

10-28-2006, 11:14 AM	#45
CommanderROR eink fanatic Posts: 2,022 Karma: 4924 Join Date: Mar 2006 Location: Germany Device: STAReBOOK, iRex Iliad, Sony 505, Kindle 2	Is the Picsel Software Open Source or is it it "Payware"? If it's normal, commerical stuff, then iRex would probably have to get some kind of agreement going with them if they want to include that Software into the Iliad... Since there is no way for a user to install Software (apart from the hackers way...^^) on the Iliad apart from the IDS, I'm not sure how easy it would be to get something like this growing...and I don't know how much interest the Picsel guys would have in supporting the Iliad either...

Advert

Advert