MobileRead Forums - View Single Post - How does Plucker (free) compare to iSilo (commercial)?

Alexander Turcic · 03-31-2003, 03:56 PM

Test 3: Big Channel, Medium Graphics

Slate: http://slate.msn.com/Apps/MySlate/ac...n=read&ids=toc

Plucker:

Link-Depth: 1
Image Settings: Include Image (1000s of colors), thumbnail for images > 240x240
Other Settings: ZLIB
Target: PALM\PROGRAMS\Plucker
Conversion Time: 1:41 mins
File Size: 985,994 Bytes (get file <a href="http://www.turcic.com/forums/supplements/isilo-plucker/Slate Pluck.pdb">here</a>)

iSiloX:

Link-Depth: 3
Image Settings: Include Image (16-bit 64K colors), Resize 240x240, Compress
Other Settings: Process table formatting
Target: PALM\PROGRAMS\iSilo
Conversion Time: 1:03 mins
File Size: 1,522,466 Bytes (get file <a href="http://www.turcic.com/forums/supplements/isilo-plucker/Slate iSilo.pdb">here</a>)

Observation:
Misleading compression results.
At the first look it appears that in Test 3, Plucker’s compression is superior to iSiloX. But this is not the case. What happens underneath the surface is that Plucker reduces the quality of the images, which makes them look dithered after the conversion.

See <a href="http://www.turcic.com/forums/supplements/isilo-plucker/screen00.png" target="_blank">here</a> and compare <a href="http://www.turcic.com/forums/supplements/isilo-plucker/screen01.png" target="_blank">here</a> to iSiloX. If I reduce the image quality in iSiloX accordingly (256 colors), the converted iSiloX file size is actually reduced to 721,078 Bytes; ~26% smaller than Plucker!

Note that there is unfortunately no apparent switch available in Plucker Desktop to disable it from reducing image quality. See next paragraph why that is so.

60Kb Image Limit.
Plucker limits the size of an uncompressed image to less than 60Kb (to be more precise: 60,000Bytes). The major problem in Plucker therefore is that the resolution is severely limited for 8bpp (256 colors) and 16bpp (65536 colors) images.

You can calculate the max image resolution for a given color depth with the following formula:

imageWidth * imageHeight = 60000 / pixelDepth

According to this formula,

for 2bpp (4 shades of gray), the size is limited to 489x489 pixels
for 4bpp (16 shades of gray), the size is limited to 346x346 pixels
for 8bpp (256 colors), the size is limited to 244x244 pixels
for 16bpp (65536 colors), the size is limited to 173x173 pixels

Click <a href="http://www.turcic.com/forums/supplements/isilo-plucker/screen04.png" target="_blank">here</a> for a visual representation.

In other words, with the current implementation (Plucker developers are still trying to find a new way to display images), Plucker is not able to display a single colored (be it 256 or 65536 colors) image that fills the entire screen on a regular hi-res Sony Clie (like when you want to read comics/cartoons). What Plucker does instead is try to reduce the image size (either by reducing resolution or by reducing color depth).

Document Fragmentation:
Plucker automatically breaks a document into 32Kb parts.

This is due to Palm OS’s memory handling and how Plucker deals with it. In the current Palm OS (4.x) implementation, a record or resource can be no larger than the largest memory chunk, which is 64Kb (or slightly less). Furthermore, there can be no more than 64Kb records in a record database. And as if this limit is not enough, Plucker uses API calls that reference records and resources by index, a method that further reduces the number of accessible records or resources to 32,768.

Implication: Documents larger than 32Kb are broken into 32Kb chunks. What you get is a not-so-nice "click here for the next part" link at the bottom of each document chunk.

Some people may disagree with me and argue that the jump from the bottom of one 32Kb page to the top of the next 32Kb page is not a big deal. However, there is another drawback arising from this limitation: it makes the percentage figure meaningless. Of what interest is it to me that I am at 70% percent of the *current* 32Kb segment, if I don’t know how much that is in terms of the *total* document!

Like magic, iSilo “seems” to break these limits, and I have no clue how (maybe by rewriting some Palm OS structures?). Neither does iSilo split a document into segments, nor does it have any apparent limitation on the document size (e.g., I have a 17Mb tutorial and iSilo reads it just like any other document).

Slow Search:
Plucker’s search algorithm doesn't win a prize for speed. Probably part of the reason for its slowness is the document segmentation mentioned earlier.

I ran the following test: From the top (home) of the Slate document, I searched for the keyword “salmonella” (wonderful, isn’t it?) which appears only once at the very end of the document. And here are my findings:

Plucker:

(setting: unchecked case-sensitive, find in all pages) 82 secs + 13 secs (for refreshing the page and marking the found keyword)
(setting: checked case-sensitive, find in all pages) 51 secs + 13 secs (for refreshing the page and marking the found keyword)

iSilo:

(setting: unchecked case-sensitive, entire document) 21 secs
(setting: checked case-sensitive, entire document) 12 secs

iSilo’s search algorithm is about 4x faster than the one used by Plucker.

Scrolling
"Drag" scrolling is not anywhere near as smooth as that found on iSilo.

Ever since using iSilo, I’ve found the following the most convenient region options:

[1] 15% Screen Up
[2] 35% Drag
[3] 35% Drag
[4] 15% Screen Down

Plucker also allows for a 4-part region setting. However, neither is it possible to define the size of each region, nor is it possible to use the 4-part region setting together with the dragging mode.

Scrolling is slow in Plucker. You can “see” how Plucker refreshes the screen each time you scroll to a new page, whereas iSilo seems smooth and instantaneous.

Related to scrolling is the auto-scrolling feature that both programs offer. With Plucker, auto-scrolling cannot keep up with normal reading speed unless scroll speed is set to more pixels. But at that point, the text becomes too jumpy to be read without getting a headache. iSilo’s auto-scrolling is pleasantly smooth, and scroll speed can easily be configured with the jog dial (adjustable in 20 increments).

Refresh Time
The Plucker version of Slate is 985,994 Bytes. That means the Plucker View splits it up into 31 pages or sections (32Kb each). Every time you "click here for the next part", there is a load time of 10-15 seconds until you can actually begin to read and scroll down on that one 32Kb part of Slate. If you take this x 31, you get a total waiting time of 5-8 minutes for the entire Slate document.

Compare this to iSilo, where the Slate document is presented in one single part without any refresh times.

Note: Slate uses Unicode, specifically UTF-8 encoding. Neither iSilo nor Plucker support it.

Screenshots:
Slate Home iSilo:

Slate Home Plucker:

Slate "click here for the next part" Plucker:

Slate Image iSilo:

Slate Image Plucker:

03-31-2003, 03:56 PM	#5
Alexander Turcic Fully Converged Posts: 18,175 Karma: 14021202 Join Date: Oct 2002 Location: Switzerland Device: Too many to count here.	Test 3: Big Channel, Medium Graphics Slate: http://slate.msn.com/Apps/MySlate/ac...n=read&ids=toc Plucker: Link-Depth: 1 Image Settings: Include Image (1000s of colors), thumbnail for images > 240x240 Other Settings: ZLIB Target: PALM\PROGRAMS\Plucker Conversion Time: 1:41 mins File Size: 985,994 Bytes (get file <a href="http://www.turcic.com/forums/supplements/isilo-plucker/Slate Pluck.pdb">here</a>) iSiloX: Link-Depth: 3 Image Settings: Include Image (16-bit 64K colors), Resize 240x240, Compress Other Settings: Process table formatting Target: PALM\PROGRAMS\iSilo Conversion Time: 1:03 mins File Size: 1,522,466 Bytes (get file <a href="http://www.turcic.com/forums/supplements/isilo-plucker/Slate iSilo.pdb">here</a>) Observation: Misleading compression results. At the first look it appears that in Test 3, Plucker’s compression is superior to iSiloX. But this is not the case. What happens underneath the surface is that Plucker reduces the quality of the images, which makes them look dithered after the conversion. See <a href="http://www.turcic.com/forums/supplements/isilo-plucker/screen00.png" target="_blank">here</a> and compare <a href="http://www.turcic.com/forums/supplements/isilo-plucker/screen01.png" target="_blank">here</a> to iSiloX. If I reduce the image quality in iSiloX accordingly (256 colors), the converted iSiloX file size is actually reduced to 721,078 Bytes; ~26% smaller than Plucker! Note that there is unfortunately no apparent switch available in Plucker Desktop to disable it from reducing image quality. See next paragraph why that is so. 60Kb Image Limit. Plucker limits the size of an uncompressed image to less than 60Kb (to be more precise: 60,000Bytes). The major problem in Plucker therefore is that the resolution is severely limited for 8bpp (256 colors) and 16bpp (65536 colors) images. You can calculate the max image resolution for a given color depth with the following formula: imageWidth * imageHeight = 60000 / pixelDepth According to this formula, for 2bpp (4 shades of gray), the size is limited to 489x489 pixels for 4bpp (16 shades of gray), the size is limited to 346x346 pixels for 8bpp (256 colors), the size is limited to 244x244 pixels for 16bpp (65536 colors), the size is limited to 173x173 pixels Click <a href="http://www.turcic.com/forums/supplements/isilo-plucker/screen04.png" target="_blank">here</a> for a visual representation. In other words, with the current implementation (Plucker developers are still trying to find a new way to display images), Plucker is not able to display a single colored (be it 256 or 65536 colors) image that fills the entire screen on a regular hi-res Sony Clie (like when you want to read comics/cartoons). What Plucker does instead is try to reduce the image size (either by reducing resolution or by reducing color depth). Document Fragmentation: Plucker automatically breaks a document into 32Kb parts. This is due to Palm OS’s memory handling and how Plucker deals with it. In the current Palm OS (4.x) implementation, a record or resource can be no larger than the largest memory chunk, which is 64Kb (or slightly less). Furthermore, there can be no more than 64Kb records in a record database. And as if this limit is not enough, Plucker uses API calls that reference records and resources by index, a method that further reduces the number of accessible records or resources to 32,768. Implication: Documents larger than 32Kb are broken into 32Kb chunks. What you get is a not-so-nice "click here for the next part" link at the bottom of each document chunk. Some people may disagree with me and argue that the jump from the bottom of one 32Kb page to the top of the next 32Kb page is not a big deal. However, there is another drawback arising from this limitation: it makes the percentage figure meaningless. Of what interest is it to me that I am at 70% percent of the current 32Kb segment, if I don’t know how much that is in terms of the total document! Like magic, iSilo “seems” to break these limits, and I have no clue how (maybe by rewriting some Palm OS structures?). Neither does iSilo split a document into segments, nor does it have any apparent limitation on the document size (e.g., I have a 17Mb tutorial and iSilo reads it just like any other document). Slow Search: Plucker’s search algorithm doesn't win a prize for speed. Probably part of the reason for its slowness is the document segmentation mentioned earlier. I ran the following test: From the top (home) of the Slate document, I searched for the keyword “salmonella” (wonderful, isn’t it?) which appears only once at the very end of the document. And here are my findings: Plucker: (setting: unchecked case-sensitive, find in all pages) 82 secs + 13 secs (for refreshing the page and marking the found keyword) (setting: checked case-sensitive, find in all pages) 51 secs + 13 secs (for refreshing the page and marking the found keyword) iSilo: (setting: unchecked case-sensitive, entire document) 21 secs (setting: checked case-sensitive, entire document) 12 secs iSilo’s search algorithm is about 4x faster than the one used by Plucker. Scrolling "Drag" scrolling is not anywhere near as smooth as that found on iSilo. Ever since using iSilo, I’ve found the following the most convenient region options: [1] 15% Screen Up [2] 35% Drag [3] 35% Drag [4] 15% Screen Down Plucker also allows for a 4-part region setting. However, neither is it possible to define the size of each region, nor is it possible to use the 4-part region setting together with the dragging mode. Scrolling is slow in Plucker. You can “see” how Plucker refreshes the screen each time you scroll to a new page, whereas iSilo seems smooth and instantaneous. Related to scrolling is the auto-scrolling feature that both programs offer. With Plucker, auto-scrolling cannot keep up with normal reading speed unless scroll speed is set to more pixels. But at that point, the text becomes too jumpy to be read without getting a headache. iSilo’s auto-scrolling is pleasantly smooth, and scroll speed can easily be configured with the jog dial (adjustable in 20 increments). Refresh Time The Plucker version of Slate is 985,994 Bytes. That means the Plucker View splits it up into 31 pages or sections (32Kb each). Every time you "click here for the next part", there is a load time of 10-15 seconds until you can actually begin to read and scroll down on that one 32Kb part of Slate. If you take this x 31, you get a total waiting time of 5-8 minutes for the entire Slate document. Compare this to iSilo, where the Slate document is presented in one single part without any refresh times. Note: Slate uses Unicode, specifically UTF-8 encoding. Neither iSilo nor Plucker support it. Screenshots: Slate Home iSilo: Slate Home Plucker: Slate "click here for the next part" Plucker: Slate Image iSilo: Slate Image Plucker: