manga2cbz for iRex DR800 - Page 2

The Straven · 03-19-2010, 06:46 PM

Quote:

Originally Posted by Kolenka

I've not really noticed the perf gains from the plugin end that you mention. UDS does do some weird things at times, but the plugin is happily pre-loading pages /almost/ as fast as someone can trigger a page flip with these larger files. And with the pre-loaded pages, the loading times of the larger files are pretty much hidden entirely if you are actually reading the comic.

I went back and checked, and once a file is loaded into memory there's no lag between flipping the bar and page turning for the bigger files, but I opened four other files and then went back to the first one and had a little lag again. Hmm.

Kolenka · 03-22-2010, 03:06 PM

The key word here is "almost".

There are two caches at work: the document viewer's cache, and the plugin's cache. The plugin loads and pre-renders pages ahead and behind the page you are on in the current document. The document viewer will cache pages it has requested from the plugin as well, for /all/ documents. The most recently viewed pages remain in memory, while the older ones get purged as more memory is needed.

So whenever you load a document after not viewing it in awhile, the pages will need to be re-rendered and given to the viewer by the plugin... since neither the plugin or the viewer has a copy.

Say it takes about 1.2 seconds to render each page in a specific document. When you load it, part of the 2-3 seconds to load is rendering that first page. Now, you spend 2 seconds skimming the page and hit next. It should be pretty much instant to start the refresh, since page 2 is pre-rendered. But if you start spamming the next button as fast as the screen can refresh, you aren't letting the 1.2 seconds required to load the next page pass by. In that case, you will get a little lag. So the lag will be hit more if you skim comics, than if you spend a few seconds reading each page. You can test this by loading a document, waiting 30 seconds or so, and then spamming next. The first couple pages will be instant, and then you will start hitting lag.

Now, this 1.2 seconds is an arbitrary number, and can be affected by the file format you use to store the image, size of the file outside of a ZIP, and even in some cases, some /variation/ of the file format you use to store the image. A couple rules of thumb to avoid slow performance is to use JPEG over PNG, and avoid using Progressive JPEG. Large PNGs and Progressive JPEGs are both slow to load. PNGs can get in the 2-4 second range when they get large, and even 1MB PNGs load slower than a JPEG of the same file at half the size, despite the simpler compression. Progressive JPEGs start in the 5 second range, and easily pass 10 seconds /per page/. And unfortunately, there isn't anything I can do to address it in the plugin.

gioachin · 05-31-2010, 10:39 PM

Hello all.

I tried this converter and found it very good (later I used calibre on the resulting cbz to make an epub out of it so the DR800 is happy). A couple of things that didn't work for me:

1) The default is set to 981 pixels high, but as I tested, it appears that max 949 pixels are displayed (and 75 appear to be used by the bottom menubar)

2) The generated zip file has the images in random order

3) If an painted image is very small compared to the whole canvas size, the image is mistreated (as shown in a previous post). This happens frequently in manga where a small icon may appear in a corner of the page.

Since the source file is part of the jar file, I fixed items 2 and 3 (though I didn't test number 3 extensively). (Item 1 is just a matter of default settings and can be anyway changed in the config file.) Let me know if you want a patch file or if you have a set of pictures that should be used to test correctness.

Filippo

AgentBEATS · 06-06-2010, 03:04 AM

I was recently recommended this program to use for making my manga chapters into presentable volumes on my ebook reader. While that is not an irex and is actually a sony prs-505, I must say this program works really well. Of the 8 or so volumes I've converted and read so far this has made them look better than if I were to have just changed the zip/rars to cbz/cbrs myself and especially like the fact that it takes the larger images and flips them sideways so I can view them without splitting them.

However, I've run into some difficulties. That is the program seems to freeze a lot when running my archives through them. They are usually rars or cbrs and are all made up of either jpgs or pngs, but the program seems to react differently to each for a reason that I can't seem to deduce. Any ideas?

In the end though, great program.

The Straven · 06-09-2010, 12:07 AM

Quote:

Originally Posted by AgentBEATS

... the program seems to freeze a lot when running my archives through them. They are usually rars or cbrs and are all made up of either jpgs or pngs ...

Best bet is to unRAR those files; that usually does it for me. I've only found one file out of, well, let's just call it quite a few volumes that still confounds me.

jiuzhege · 06-15-2010, 06:23 PM

usable on RC1 June 9 th ? ?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
DR800 iRex DR800 PDF Testing	GT4NE1	iRex	6	07-05-2010 11:04 AM
What is size of IREX DR800 and DR1000	PocketGoods	iRex	12	06-05-2010 04:58 AM
My Take on iPhone, iRex DR800, and the iPad	nikkie	Which one should I buy?	4	05-10-2010 06:04 AM
IREX DR800 or DR1000?	sordie	Which one should I buy?	8	03-21-2010 08:10 PM

03-22-2010, 03:06 PM	#17
Kolenka <Insert Wit Here> Posts: 1,017 Karma: 1275899 Join Date: Jan 2008 Location: Puget Sound Device: Kindle Oasis, Kobo Forma	The key word here is "almost". There are two caches at work: the document viewer's cache, and the plugin's cache. The plugin loads and pre-renders pages ahead and behind the page you are on in the current document. The document viewer will cache pages it has requested from the plugin as well, for /all/ documents. The most recently viewed pages remain in memory, while the older ones get purged as more memory is needed. So whenever you load a document after not viewing it in awhile, the pages will need to be re-rendered and given to the viewer by the plugin... since neither the plugin or the viewer has a copy. Say it takes about 1.2 seconds to render each page in a specific document. When you load it, part of the 2-3 seconds to load is rendering that first page. Now, you spend 2 seconds skimming the page and hit next. It should be pretty much instant to start the refresh, since page 2 is pre-rendered. But if you start spamming the next button as fast as the screen can refresh, you aren't letting the 1.2 seconds required to load the next page pass by. In that case, you will get a little lag. So the lag will be hit more if you skim comics, than if you spend a few seconds reading each page. You can test this by loading a document, waiting 30 seconds or so, and then spamming next. The first couple pages will be instant, and then you will start hitting lag. Now, this 1.2 seconds is an arbitrary number, and can be affected by the file format you use to store the image, size of the file outside of a ZIP, and even in some cases, some /variation/ of the file format you use to store the image. A couple rules of thumb to avoid slow performance is to use JPEG over PNG, and avoid using Progressive JPEG. Large PNGs and Progressive JPEGs are both slow to load. PNGs can get in the 2-4 second range when they get large, and even 1MB PNGs load slower than a JPEG of the same file at half the size, despite the simpler compression. Progressive JPEGs start in the 5 second range, and easily pass 10 seconds /per page/. And unfortunately, there isn't anything I can do to address it in the plugin.

05-31-2010, 10:39 PM	#18
gioachin Junior Member Posts: 3 Karma: 10 Join Date: May 2010 Device: DR800SG	Hello all. I tried this converter and found it very good (later I used calibre on the resulting cbz to make an epub out of it so the DR800 is happy). A couple of things that didn't work for me: 1) The default is set to 981 pixels high, but as I tested, it appears that max 949 pixels are displayed (and 75 appear to be used by the bottom menubar) 2) The generated zip file has the images in random order 3) If an painted image is very small compared to the whole canvas size, the image is mistreated (as shown in a previous post). This happens frequently in manga where a small icon may appear in a corner of the page. Since the source file is part of the jar file, I fixed items 2 and 3 (though I didn't test number 3 extensively). (Item 1 is just a matter of default settings and can be anyway changed in the config file.) Let me know if you want a patch file or if you have a set of pictures that should be used to test correctness. Filippo

06-06-2010, 03:04 AM	#19
AgentBEATS Connoisseur Posts: 72 Karma: 10 Join Date: Oct 2009 Location: Canada Device: Sony PRS-505, Nintendo DS, HTC Desire	I was recently recommended this program to use for making my manga chapters into presentable volumes on my ebook reader. While that is not an irex and is actually a sony prs-505, I must say this program works really well. Of the 8 or so volumes I've converted and read so far this has made them look better than if I were to have just changed the zip/rars to cbz/cbrs myself and especially like the fact that it takes the larger images and flips them sideways so I can view them without splitting them. However, I've run into some difficulties. That is the program seems to freeze a lot when running my archives through them. They are usually rars or cbrs and are all made up of either jpgs or pngs, but the program seems to react differently to each for a reason that I can't seem to deduce. Any ideas? In the end though, great program.

06-15-2010, 06:23 PM	#21
jiuzhege Member Posts: 14 Karma: 10 Join Date: Nov 2008 Device: none	usable on RC1 June 9 th ? ?

Advert

Advert