Kindlegen 1.1 (released June 30, 2010) doubled the Kindle image file-size limit from 64KB to 128KB (which became 63KB to 127KB in later documentation). The change was a big leap forward for Kindle authors and readers. Nevertheless, cover image files under 127KB often looked worse for wear after Kindlegen built the .mobi file, even with the March, 2012 release of Kindlegen 2.4.
Kindlegen is available as a command-line program, but it’s also included in Kindle Previewer. When you open (or drag-and-drop!) a supported file-type (HTML, ePub, OPF) in Kindle Previewer, Kindlegen converts and saves it as a .mobi file first. Handy!
According to a forum post by the Kindle Publishing Team (January 18, 2012):
- KindleGen supports GIF, BMP, JPEG, non-transparent PNG and Scalable Vector Graphics (SVG) images in your content.
[Italics added. Note that “in your content” does not mean “for your cover image.” Use a .jpg or .gif for an interior cover image. Amazon will replace it with one derived from the product cover image, so add your generic 600×800 or 600×900 image if you use Kindlegen, and don’t worry. If you are submitting a zipped HTML file to Amazon KDP instead of using Kindlegen, an interior cover image is not required.]
- Kindle Format 8 internally supports JPEG and GIF images of up to 127KB in size. KindleGen will convert images in other formats or of larger sizes to the supported format and size.
- If you find the automatic conversion of KindleGen unsatisfactory, you can optimize your images to meet the above criteria (JPEG or GIF, <127KB). KindleGen won’t alter images that meet this criteria.
In practice, Kindlegen 2.4 still compresses cover images, even when under 127KB, but not every time, not every image. Illustrations under 127KB used inside the book are routinely and aggressively compressed even if they are within the file-size limit when the JPEG quality is high. In the small charts below, notice that images at 40 or 45 JPEG quality were unscathed, but those at 60+ quality were compressed further. Apparently Kindlegen triggers compression if image quality is “too high” (an unknown threshold, guessing 50), regardless of file-size. That really sucks!
I’ve confirmed what I’d been observing about cover image behavior by experimenting with multiple copies of the same cover image at various file sizes. Each cover image was added to a short test book, which was compiled in Kindlegen and inspected in Kindle Previewer as it would appear in various devices and apps. Each compiled .mobi file was then “exploded” with mobiunpack.py (a free Python program) to check after-conversion file-size and appearance.
Results were in line with what Amazon claims for one book, but not the other, and better than what they have been in interim versions Kindlegen since 1.1:
- Some images optimized at 124KB to 127KB appeared to be untouched and have fewer artifacts than larger or smaller images after the test book was compiled by Kindlegen. Some images under 127KB ended up as smaller files with mushy text. Higher quality images, say 300KB to 600KB, were compressed to 127KB or less, but the visual quality varied from good to unacceptable.
- Two large images (100-quality JPEG and PNG-24) for one test book looked relatively sharp after Kindlegen compressed them to 127KB. Nevertheless, an optimized 124KB version of the same image looked better and was the exactly the same file-size after Mobi compilation. Two equally large images for a second book were compressed to about 98KB and looked much worse than images under 127KB.
So, if your Kindlegen conversion doesn’t go well the first time, I think it’s worth trying several versions of your cover to compare the output. See what happens to each image using mobiunpack. I would recommend using 124KB, 127KB, and 128KB, and if desperate, a 100-quality JPEG and a PNG-24. It takes very little time to try all of them in quick succession and pick the one with best results.
Kindlegen converts PNG-24 images to JPEG and PNG-8 images to GIF. The GIF images do not retain their original 600×800 dimensions, but are reduced by about one-third and look too small on the Kindle Fire simulator. They expand on eInk Kindles and look quite good, especially covers with mostly text or line drawings.
The rest of this post is about two bogus book cover images I ran through Kindlegen. Your mileage will vary.
Test Cover Image One
This test cover uses a grayscale drawing from oldbookillustrations.com, shown at left. Click to see the full image. A sepia filter was overlaid on the drawing and big text added above and below it.
I saved copies in Photoshop and used them as cover images in copies of a one-page ePub “book” built with Sigil. Click the cover thumbnail at right to see the original 124KB version of the cover for House Rules by Wolfram Hart. Results are similar to those from a current project, a book that includes part of a large complex pencil drawing (20+MB) supplied by the author.
Results are as follows:
|Filetype||Quality||File Size||Origin||Mobi Size||Notes|
|JPEG||43||123KB||Photoshop||123KB||The best images were derived from the 124 and 127KB JPEGs. Images derived from the 100-quality JPEG and PNG-24 files were noticeably worse than the others. The 126KB image from Fireworks became 123KB in Kindlegen, and looked quite sharp, but the 172.3KB image was a blurred 107KB after conversion.|
The three smaller JPEGs at 43, 44, and 45 quality were approximately the same size before and after conversion by Kindlegen. The fourth image is from a 100-quality JPEG at 512KB, which was converted to a 108KB JPEG by Kindlegen. It’s noticeably fuzzier than any of the other images.
Below is a zoomed-in view of the first two letters in Wolfram from the 127KB cover (left) and the 108KB cover (right). Starting with a 100-quality JPEG or 24-bit PNG obviously does not guarantee a sharp cover after conversion. Compression of the 512KB image down to 108KB greatly increased the number of artifacts and bleeding of the text color into the background.
Test Cover Image 2
The second test cover uses an image from Microsoft Office Gallery, entitled Cherry Blossom Branch, 788×1050 pixels, 857KB, from iStockPhoto. The image is derived from a painting and contains many dots and splats of paint. I pasted it into a new Photoshop image at 600×800 pixels and positioned it without resizing. Click thumbnail at left to view the image.
Using this image as the background, I made a simple test cover for a non-existent book, entitled “Blossom Moon.” As a book cover, the pink and blue was a bit bilious, so I made a grayscale copy and let some pink blossoms poke through from a lower layer. Text was added over a masked area of the background.
Again, I saved copies of the image in Photoshop and Fireworks and used each one as the cover image in a one-page ePub “book” made with Sigil. Kindlegen transformed each ePub into a .mobi file, which was then inspected and exploded with mobiunpack.py to check image file-sizes. Since red tends to result in more artifacts and red text bleeds into the background more readily than other colors, I made a blue version that looks rather cold, but is sharper.
Results are as follows:
|Filetype||Quality||File Size||Origin||Mobi Size||Notes|
|JPEG||62||125.6KB||Photoshop||105KB||Text had many JPEG artifacts in every file-size. The PNG-8 became a 426x568px GIF, sharp but too small on Kindle Fire and rubble on iPhone. Adobe Fireworks can selectively preserve text quality, but its images didn’t fare better than Photoshop’s.|
All of the Photoshop and Fireworks images were sharp, with no visible text artifacts. The Kindlegen images from small JPEGs were better than those from big files. Blue text is sharper, with less color leaking into the background.
Here are closeups of two letters from the cover:
In the end…
While a couple of sample covers does not make a scientific study, results are typical of what I’ve found over time. Text and drawings suffer the most from compression. Quality photographs hold up a lot better than the images used in these tests. However, authors sometimes want to use their drawings, paintings, or damaged photos instead of images that will not be so problematic.
Red text and images with red tend to produce more artifacts than any other color and bleed profusely into other colors. I did a cover last year that had a beautiful raspberry red area and text without any visible artifacts before conversion. Kindle results were disappointing, but the same cover on B&N had a lot more clarity.
These results are significantly different than a similar test with a real (not test) book where two large-file versions of the cover weighed in at 127K after Kindlegen and looked quite good. However, optimized 124KB and 127KB images look sharpest with least bleeding of text color into the background.
Remind yourself that Kindle books don’t open with the cover as ePubs do, so few people will bother to look at them. The product catalog cover is what potential readers will see. It needs to be as sharp as possible and is allowed to be larger in both dimensions and file-size. Amazon does a decent job of transforming a high quality catalog cover into thumbnail and larger zoomed views. However, if Look Inside the Book is offered, the fabulous zoomable image is replaced by a thumbnail with a “Look Inside” link draped over it. C’est la vie.