Content Kindle Comic Converter - Convert comics/manga to MOBI/EPUB

[AcidWeb]

@RadicalxEdward - Version 4.4.1 should fix OS X GUI. I'm planning to add ComicRack metadata editor to KCC soon(TM).

[badbob001]

Would this app be appropriate to convert newspaper-style three-horizontal panel comics (600x179 gifs) to be viewed on my Voyage? The default settings would split the comic over two pages. I tried the webtoon mode and I liked how it efficiently stacked multiple comics onto the same page, but:

• The comics were shrunk smaller than its native size (maybe 250 pixels wide)
• The comic on the bottom of the stack is cut in half

Enabling [x] Stretch/Upscale didn't solve the shrunken size.

I'm guessing Webtoon is only for a specific use case, but is there a mode or setting to show comic strips full width and multiple-per-page?

[badbob001]

And I'm unsure when I need to use the Upscale option since the kindle (voyage in my case) seems to show an image full screen even when it's less than the screen's native resolution.

For example, chapter 2 of a manga has pages that are 711-ish x 1100. The voyage is about 1080x1430, but these pages are still nicely expanded edge to edge.

But chapter 3 has pages of the same size but they appear to be shown at native resolution and thus there is a large border around the images. The only anomaly is that one of the pages is 1920x2971. Could that be throwing the converter/viewer off? I'm have the app set for Voyage and Mobi output.

ch2: http://ul.to/ndkdscgi
ch3: http://ul.to/oita0i61

I wish there is a page that explains the purpose of each option in the application. The faq/wiki doesn't do this.

Thanks.

[AcidWeb]

Voyage have 1072x1448 screen.

KCC was created to convert full page manga/comics and webtoons. You can experiment with other type of input but as you can see - output might (and probably will) be bad.

By default KCC is trying to remove all whitespace around page and then check if image is bigger than target resolution. If it is - downscale kick in. It it is not and upscale/stretch is disabled then KCC will center image on screen.

Every page is considered separately.

Your chapter 3 is converted correctly. Images are much smaller than Voyage resolution - so they are displayed in original size. Enabling upscaling will increase size of images and remove most of margin at the expense of their quality. Stretch would remove margins completely but it will decrease quality even more due to breaking image ratio.

TL;DR
Enable upscaling when images are much smaller than Voyage resolution. Stretch will force usage of entire screen but it might decrease quality too much.

[badbob001]

Originally Posted by AcidWeb

Your chapter 3 is converted correctly. Images are much smaller than Voyage resolution - so they are displayed in original size. Enabling upscaling will increase size of images and remove most of margin at the expense of their quality. Stretch would remove margins completely but it will decrease quality even more due to breaking image ratio.

Shouldn't chapter 2 have the same result since the pages are the same resolution as pages from chapter 3? I can't verify the resolution of the content within the converted mobi, but on the Kindle itself, chapter 2 pages are shown with no borders. And the ONLY option checked is [x] Manga mode.

As an experiment, I removed singe 1920x2971 odd page from chapter 3 and now all pages are shown with no borders on the kindle. So is this a converter issue or a viewer issue?

[AcidWeb]

I can't replicate this issue. Chapter 3 is converted correctly and all images inside have proper size. They SHOULD be too small when only manga mode is enabled.

You are sure that you not describing pages with Panel View enabled?

[badbob001]

Originally Posted by AcidWeb

I can't replicate this issue.

I've only tested this on the voyager because I've read that calibre can't handle the mobi files created by KCC. In any case, I've opened the mobi files in calibre and it shows each page being 1072x1448 and the 700x1100 image is indeed in the center. So it looks like the kindle viewer automatically crops out the white margins but probably does it in a per book basis and not per page. So with chapter 2, the odd oversized page had no margins, which made the viewer not crop the surrounding pages. I did notice in other chapters that some pages had some margin appear at top or bottom, which can be explained by the auto-cropping feature limiting it's cropping due to another page having a large content area. This margin cropping thing on the kindle... is that something new?

Proof! I made the calibre reading background green so you can see the actual edges of the image.


Is there an option to not add margins to undersized pages? That is, I want a 700x1100 to stay that size in mobi and not have margins added to make it a 1072x1448 page? Maybe this will allow the viewer to treat each page separately?

Panel View is when you double-tap the page, it zooms in to one of the corners, and there is a overview map in the lower-right? Nope, definitely not in the mode. But when I do enter panel view, the original margins are shown.

[badbob001]

I do notice something different with the mobi of chapter 3 with the oversized page and the one without when viewed on the voyage:

In the mobi without the oversize page (pages have margins autocropped):
The menu option has this:
* Animation On/Off
* Fit to Screen On/Off

I'm not sure what Fit to Screen On/Off does but it doesn't cancel out the margin-cropping feature. The animation option enables a scrolling animation when in zoomed-in panel view.

Panel view, when activated, zooms in to each corner as expected.

In mobi with the oversized page (pages do not have margins autocropped):
In the menu, there are no options for Animation or Fit to Screen. Why is this mobi treated differently?

On pages showing the whole image along with the margins, when double-tapping the page to go into panel view (a rectangle appears in lower-right), the view doesn't automatically zoom it and tapping the page only goes to the next page. But when you get to the oversized page, it does zoom in for only that page. Shouldn't KCC have made all pages the same physical size? So it weird that the viewer would treat that one page differently.

Calibre doesn't give me the option to save the image for that one particular oversized page (unlike most other pages) so I can't confirm if the image size is the same as the others.

[badbob001]

According to page on the old 3.0 update link:

New menu options for Animation and Fit To Screen are available on the Paperwhite when Virtual Panels are active and the "comic" book-type is chosen.

So could one mobi be not considered comic-book-type? Would it help if I upload the two mobi files?

[AcidWeb]

OK. I got it. It look like undocumented Kindle "feature" as I replicated this on Paperwhite too.

Problem is on both sides: Kindle doing something unpredictable and KCC don't take into account this scenario.

Animation and Fit to Screen options should not be available at all.

Enable upscaling. That will produce proper output. I will add some workaround for this issue in next release after I research it more thoroughly.

EDIT:
Found the cause. When ALL images are smaller than screen resolution then no page have any Panel View data. In this case Kindle force virtual Panel View even if MOBI header is set to use real Panel View. And that cause this entire anomaly. I will fix it in next release.

Additionally in this scenario big margins are expected output. As I said before KCC don't upscale images by default. So chapter 3 is converted correctly. I know that might be a little counterintuitive but chapter 2 fail to display properly not third.

KCC is designed to create MOBI files that don't require any image manipulations on Kindle level. It is faster and does not decrease the quality of images.

EDIT2:
And it is fixed in dev branch. Thank you for reporting it.

[badbob001]

I've tried another tool to trim margins and ONLY downscale when needed. The resulting chapter looks fine on the voyage, albeit it depends on the kindle viewer to upscale the images. My preference is to not have the images externally upscaled, so to greatly reduce storage requirements, and have the device perform the scaling since it seems fast enough to do so.

Will you be allowing for that choice by adding the option to not add margins to non-upscaled images? I wonder if this option would be even less work for the kindle since it would just need to upscale the image instead of first finding/cropping-out the margins and then perform the upscaling.

Found the cause. When ALL images are smaller than screen resolution then no page have any Panel View data. In this case Kindle force virtual Panel View even if MOBI header is set to use real Panel View. And that cause this entire anomaly. I will fix it in next release.

Please note that the cover page is usually larger than the screen resolution, but I guess that doesn't matter since your app splits the landscape image to two smaller images.

Thanks for looking into this!

[AcidWeb]

Originally Posted by badbob001

Will you be allowing for that choice by adding the option to not add margins to non-upscaled images?

I can understand your approach but: No. It is completely incompatible with my approach to conversion process. Kindle image reprocessing is unreliable and in many scenarios (mostly on older Kindle models) it simply kill quality - so I will not support it.

Originally Posted by badbob001

Please note that the cover page is usually larger than the screen resolution, but I guess that doesn't matter since your app splits the landscape image to two smaller images.

Covers are completely different matter. They are parsed differently by Kindle.

[AcidWeb]

@badbob001 - I made some additional experiments and I sustain my opinion. Kindle build-in upscaling cause more image blurring than upscaling during conversion. Additionally I did not notice any speed difference between upscaling images with and without margins embedded to image file.

Not tested that on Voyage - It might be not so visible due better DPI. But both Paperwhite and Keyboard models are affected. Quality drop is just unacceptable for me.

I checked numbers and I admit that replacing white/black margins directly in image file with white/black background on HTML level will decrease output file size. It would require major changes in conversion process. I need conduct more test and make sure that file size drop is worth this refactoring.

If you have any other ideas how to improve KCC - I'm all ears.

[badbob001]

I just learned that I can take screenshots from the Voyage by just simultaneously tapping opposite corners. For those that are curious, I have attached some screenshots of sample pages from a kcc converted manga.

• kcc normal: no options checked, so image is not resized and borders added. Upscaling is performed by the kindle itself.
• kcc upscale: upscaled option checked so upscaling performed by kcc.
• original: the original images

As you can see in the 'kcc normal' images, the kindle viewer automatically crops out the margins added by kcc, thought it doesn't do as good of a job as kcc with the upscale option. I don't see an option to disable the kindle's automatic margin cropping so images can be seen at their native resolution, but I suppose I can change the margin color to black to trick it.

Just curious, but what jpeg quality setting does KCC use? When I use an image editor, my output is usually larger unless I bring the jpeg quality level to 80. I do notice that the output is heavily higher contrast than the original (gamma is at auto) so that may be one reason for the smaller file sizes (at the expense of some fine details).

[AcidWeb]

Thank you for testing it - I still waiting for international version of Voyage to get one.

That automatic cropping is disabled if book contain at last one Panel View panel - I already forced that in dev branch of KCC.

Output JPG files have quality = 80. Plus encoder making a extra pass over the image in order to select optimal encoder settings.

For B/W images KCC use 1.8 gamma correction. It make images too dark on normal screens but most of images look better on e-ink screen when correction is so high. If you think that your output is too dark - set gamma slider to 1.0.