manga2cbz for iRex DR800

[brookman]

New version 1.1

'manga2cbz for iRex DR800S(G)' is a free & simple tool for converting manga and comics to view on the iRex DR800S(G).

Features in v1.1:

- Unpack folders or zip / cbz / rar / cbr files (or any mix of nested combinations)
- Images: png, jpg, gif
- Crop white borders
- Rotate landscape images
- Re-size images to match the screen resolution
- Reduce colors to 4 - 256 levels of gray (additional library needed for < 256)
- Save pics as png / jpg and pack them into a cbz file

New:
- XML configuration (see automatically generated 'config.xml')
- Split landscape images. (enable in XML)
- Combining split and rotate is possible too. (split then rotate)
- Mulit-threading according to the number of CPUs available (or setting in XML)
- Bugfixes

Limitations & Bugs:
- Still no split archives supported
- Small bug with cropping

Use it together with the AMAZING 'CBZ Document Plugin' written by Kolenka.
see: Thread

>>> You can enable much better compression (color depth reduction with Floyd-Steinberg dithering) by downloading the file 'gif4j_pro_trial_2.3.jar' from http://www.gif4j.com/download.htm and putting it into the same directory. <<<

Usage: Just double click the jar to see the "GUI"
Or by console: java -jar manga2cbz.jar sourceFileOrDir destinationDir Title


XML configuration tags:
---
cropThreshold: 1 - 255 (255 means completely white)

threads: 1 - 16 (0 = automatic)

splitLandscape: Works only if picture width is at least 2x screen width. LEFT = reading from left to right, RIGHT = reading from right to left, OFF = disabled

rotateLandscape: Works only if picture width is bigger than picture height. CW = clockwise, CCW = counterclockwise, OFF = disabled

type: JPG or PNG

grayLevels: 4, 8, 16, 32, 64, 128 or 256 (smaller than 256 only works with the gif4j library)

Entering wrong values causes the whole config file to be reset to default.
---

This is still an early version. It may contain bugs and I won't take responsibility for damage of your hard- and software or any data loss.
I tested it with a folder containing several rar files, which them-selfs contained further directories and a mix of png and jpgs, totally about 1000 pages (220mb). It took ~10min to unpack, convert and repack them on my Athlon 4400 (cbz size 138mb).

Please share your suggestions for improvement here.

Enjoy!

[The Straven]

Wow. You just saved me who knows how many hours of conversion work and halved the memory footprint of my comics folder, with better looking comics to boot (I've been using JE-comics).

I tested it on a set of zips containing 155 jpgs, 31.8MB total. Conversion took a couple of minutes and spit out a 22MB file. The generated cbz won't open in in CDisplay for me, but repacking it works.

Thank you very much.

[brookman]

Originally Posted by The Straven

The generated cbz won't open in in CDisplay for me, but repacking it works.

This problem should be fixed now.

[superhero]

I wanted to thank you for taking the time to put this together. Comic and Manga fans everywhere send their appreciation. I am going to try it out.

[superhero]

Originally Posted by brookman

>>> You can enable much better compression (color depth reduction with Floyd-Steinberg dithering) by downloading the file 'gif4j_pro_trial_2.3.jar' from http://www.gif4j.com/download.htm and putting it into the same directory. <<<

Sorry, can you explain this a little more. In what directory should I put this file?

[badbob001]

This works nicely with manga, though some color comics may be way too dark for a monochrome device. Thanks!

Suggestions:

• If the landscape page is at least twice the horizontal resolution of the screen, then have an option to split the page into two portrait pages. If the results sometimes favor rotation and other times favor splitting, then perhaps have it generate three pages for each wide page: rotated, split left, split right.
  
• For converting very large collections, perhaps have an option to instead of the output being one .cbz file, output multiple .cbz files matching the names of the originals.

[Kolenka]

Nice tool, a couple of comments though:

- You don't need to target the usable size of the screen due to the scaling algorithm. I'd actually target the screen's actual size. This way you are guaranteed the image always scales down or is used as-is. Scaling up is what you'd want to avoid, and in landscape, it will scale up in many cases with the resolution you selected.
- Don't need to auto-rotate either. There's pretty much no real performance savings doing this ahead of time, and it makes the resulting CBZ harder to read on other platforms (say, iPhone, a netbook, or what have you).
- I'd offer the option to save as a baseline JPEG as well. These seem to load a bit faster than a PNG due to the larger file size of the PNG (on average). If the PNG file size is comparable to a baseline JPEG of the same output, then I probably wouldn't worry about it.

Other than that, looks like a useful tool. I like to keep a single 'archival' copy of my CBZs, so I optimized the plugin to try to handle these full-size CBZs as well as possible... but anyone looking to save a few MB will like this tool, I think.

[brookman]

Originally Posted by superhero

Sorry, can you explain this a little more. In what directory should I put this file?

The file gif4j_pro_trial_2.3.jar has to be in the same folder (on the same level) as manga2cbz.jar.

Originally Posted by badbob001

• If the landscape page is at least twice the horizontal resolution of the screen, then have an option to split the page into two portrait pages. If the results sometimes favor rotation and other times favor splitting, then perhaps have it generate three pages for each wide page: rotated, split left, split right.

Now you can choose between nothing, rotate or split (or both ^^). It splits the images to the greatest possible multiple of 768. For example images with a width between 1536 (2*768) and 2303 (3*768-1) will be split in two, from 2304 and above in three and so on. I'm not sure if this makes sense though.

Originally Posted by badbob001

• For converting very large collections, perhaps have an option to instead of the output being one .cbz file, output multiple .cbz files matching the names of the originals.

I will maybe try to implement that. It might be a little bit difficult depending on the given file/directory structure...

Originally Posted by Kolenka

You don't need to target the usable size of the screen due to the scaling algorithm. I'd actually target the screen's actual size. This way you are guaranteed the image always scales down or is used as-is. Scaling up is what you'd want to avoid, and in landscape, it will scale up in many cases with the resolution you selected.

You mean 1024x768? Now you could choose that in the configuration.
I know, the selection criterion for rotation is somewhat stupid (rotate if width>height).

Originally Posted by Kolenka

Don't need to auto-rotate either. There's pretty much no real performance savings doing this ahead of time, and it makes the resulting CBZ harder to read on other platforms (say, iPhone, a netbook, or what have you).

Ok, rotation is optinal now.

Originally Posted by Kolenka

I'd offer the option to save as a baseline JPEG as well. These seem to load a bit faster than a PNG due to the larger file size of the PNG (on average). If the PNG file size is comparable to a baseline JPEG of the same output, then I probably wouldn't worry about it.

What do you mean with "baseline"? JPG can now be chosen in the config.

[Kolenka]

Originally Posted by brookman

You mean 1024x768? Now you could choose that in the configuration.
I know, the selection criterion for rotation is somewhat stupid (rotate if width>height).

The plugin uses the same criteria, so it probably isn't stupid, it is making the best use of the screen space available.

Originally Posted by brookman

What do you mean with "baseline"? JPG can now be chosen in the config.

There are two types of JPEG. Baseline and Progressive. Progressive is the style used for images aimed at the web, so a rough version of the image can be displayed before the whole file is downloaded. The problem is that it has a huge perf hit on the iRex using GDK (on the order of 5x longer to load a progressive JPEG versus baseline). There should be some options to control it in the API you are using to get the image output, I think. And for CBZ files, there is no real reason to allow progressive JPEGs in the first place (since you already have the whole file on disk).

[brookman]

I see! Thank you for the explanation. I'm using the the built-in javax.imageio.ImageIO.write() method. Progressive mode should be disabled by default. But the compression quality seems to be set only to 75%...

[Kolenka]

75% is pretty high.... I can usually get away with 40-50% on mine.

[The Straven]

brookman, is it possible to turn off crop altogether? See the attached images; I haven't tried v1.1 but I don't think it would catch this.

Kolenka, I like the idea of keeping a single version, but good scans have big file sizes (1+ MB for covers, 200-300KB for pages). Page turns for these are ~1 second as opposed to ~1/2 second for manga2cbz processed images. Plus, I go in and delete scanlation group credit pages, because these days I'm embarrassed to show a comic only to come across a pages that says: "TFT. We Love Beavers." That shoots the single version idea in the foot right there.

[Kolenka]

Originally Posted by The Straven

Kolenka, I like the idea of keeping a single version, but good scans have big file sizes (1+ MB for covers, 200-300KB for pages). Page turns for these are ~1 second as opposed to ~1/2 second for manga2cbz processed images.

Oh, I never said we should ignore this tool because /I/ don't keep around multiple CBZs, don't get me wrong, I just optimized the plugin so that perf of keeping around these archival quality CBZs was acceptable to me.

I keep around some high-quality scans myself, 500KB covers (in JPEG), and 200-500KB pages (in JPEG). 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.

Pixel size could also be coming into play, but all my stuff is in the 1200 to 1600px range for the longest side.

PNGs are actually slower to load than JPEGs when they get big (over 1MB). That is where I notice most of the lag.

[badbob001]

Originally Posted by The Straven

brookman, is it possible to turn off crop altogether? See the attached images; I haven't tried v1.1 but I don't think it would catch this.

This one is tricky. Perhaps:

• Decide on the orientation based on the pre-cropped dimensions.
• If the original is at or smaller than the screen dimensions, don't crop.
• The amount of vertical and horizontal cropping should be proportional to the aspect ratio of the screen. This may prevent what happened in the example. I hate math so I'll defer the calculations to someone else hopefully...

[Dellaster]

This is pretty nice, brookman. Thanks.

Request, if it's feasible: configurable dpi setting. It currently outputs at 120 dpi and I prefer 160, which is what the DR800's screen is at. Also, the OFF setting for dpi as well (that is, leave it unchanged from the original) in the cases where I want to use this as a pre-processor then fine tune the images in an IrfanView batch operation.