Sunday, June 14, 2009
Kindle DX Image Test
In my book, Kindle Formatting: The Complete Guide, I cover a broad range of formatting information and tips, with examples of HTML code that can be effectively used in Kindle books to create the best display possible on the Kindle 1 and Kindle 2. I bought the new Kindle DX last week, and after some extensive testing I would like to share with you some information on the formatting differences between it and the other Kindle devices.
There are actually not too many formatting differences between the Kindle 2 and the Kindle DX. The basic paragraph formatting is the same, the text indents are the same, and the specialized formatting I discuss in my book for creating outlines and poetry all works the same. It does not appear that Amazon has made any changes to the default text formatting on the Kindle DX like they did on the Kindle 2.
The only change that will make a large impact on anyone developing books for the Kindle DX is the screen size and how images are displayed on the device. I discuss image dimensions on the K1 and K2 in Chapter 5 of my book:
There has been a lot of talk on the Kindle DTP forums about what dimensions an image should be to take full advantage of the available screen real estate. The consensus opinion, and the response stated by the DTP admin, has been that 450 pixels wide by 550 pixels high (a ratio of 9:11) is the proper scale. In the course of my formatting work and testing I have found that there is a little bit more to the story than that.
The actual size of the viewable book area on the Kindle 1 screen is 524px × 640px, and the viewable book area on the Kindle 2 screen is 520px × 622px. Any images larger or smaller than that (including those sized 450px × 550px) will be automatically re-sized until the width or height fits the viewable book area. At 261px × 319px on Kindle 1 and 260px × 311px on Kindle 2 (half the size of the viewable book area) the image is no longer resized to fit the book area’s width or height. This is important when you are creating logos or other small images for your book. Logos usually look great when sized around 75–100px wide. However, images will still lose some quality when reduced in size, especially photos. I suggest that you keep your images at the Kindle 2 dimensions (520px × 622px) if you can, so that your image quality does not suffer.
Since the Kindle devices all allow image zooming, you could also create images for the K1 and K2 that are 600px × 800px with the instruction that users click on them to zoom in and see the images full-screen. That is not practical in books that have a large number of images, but it would be useful for books with detailed maps or graphics that make a big difference to the content of the book.
Like the K1 and K2, the Kindle DX has specific image dimension restrictions of which every eBook creator should be aware. The DX screen is 824 pixels wide by 1200 pixels high, and the viewable book area on the DX is 744px wide by 1022px high. The DX also has the same automatic up-scaling feature present in the K1 and K2, so all images larger than 372px × 511px will be automatically re-sized to fill the width or length of the viewable area. That applies equally to images made for K1 and K2 books, which are displayed on the DX with a noticeable decrease in image quality.
That leads me to my current frustration and to a very large problem with the current publication process at Amazon. The default format for books on all three Kindles is the Mobipocket eBook format. When you upload a Word document, PDF, or HTML file to the Digital Text Platform (DTP), the system runs Mobigen (the command-line version of Mobipocket Creator) on the file and generates a PRC/MOBI/AZW file that can be read on the Kindle. The same process is activated when you send a file to your Kindle using its e-mail address. Because the DTP will automatically create a Mobipocket file based on the file you upload, it is always best to create and upload a Mobipocket file yourself. In addition to giving you better control over and knowledge of the book's formatting, uploading a Mobi file gives you the ability to add a cover image that automatically zooms on the K2 and DX, and it gives you the ability to create waypoints in the Location Bar on those devices, making navigation between chapters as easy as a right- or left-click on the joystick. I cover the details of creating a Mobipocket file with these additional features in Chapter 7 of my book.
However, Mobipocket Creator and Mobigen both reduce the size (and, by necessity, the quality) of images when embedding them in a Mobipocket file. That function was apparently included in the days when Mobipocket books were being read on small Palm-like devices that could not handle large, high-quality images or large file sizes. Images that are the proper dimensions for the Kindle DX screen are automatically re-sized whenever you generate a Mobipocket file. This function cannot be overridden, and is not related to the compression option you can set in the two programs.
The only way I have found around this automatic re-sizing is to generate the Mobipocket file using the any2mobi command line tool provided with calibre. This tool does not re-size the images when it creates the Mobi file, so the quality of the images does not suffer. If you have calibre installed, calling the any2mobi command is very easy. You can run it on an HTML, OPF, or ePub file, or on a file in any of the other supported formats. You could even create your OPF file using Mobipocket Creator, then create the mobi file using any2mobi.
The re-sizing error in Mobipocket Creator and Mobigen brings an important additional side effect into the picture. Because Amazon uses Mobigen behind-the-scenes to create practically all of the books that are for sale on the Kindle store, there are currently no books on the Kindle store that are actually developed specifically for the Kindle DX. In effect, the "Optimized for Kindle DX" icon we have seen cropping up lately is useless. I downloaded samples of many of these books to my DX and found that their images all suffer from the re-sizing/compression issue.
This issue also highlights the problem with selling one book file for use on every eBook device. While the goal of a universal eBook file is great, reality has not yet caught up with desire, even in the ePub ecosystem. Because every device is different, there is still a lot of value in giving users a file that is formatted specifically for their device. This is especially true of devices that have extraordinarily large or small screens, or devices that have display limitations. Amazon has a unique opportunity here to allow publishers and authors the ability to target book files at specific devices. What works well on the K2 may not work as well on the DX, and vice versa. Since Amazon knows what device a file is being sent to, they could set up the system to deliver an optimized book file for the device chosen. That would allow content providers to upload optimized books to the Amazon server with the intent of giving users the best possible reading experience. Whether Amazon adjusts the system to do that or not is up in the air, but I think it would go a long way toward increasing the real and perceived value of eBooks.
Another problem with the way the Kindle devices currently handle images is the automatic up-scaling of images larger than half the viewable screen width. This function creates a lot of confusion about the actual screen real estate available, and, by necessity, it makes small images grainy and pixelated. If you have to make a 200 pixel wide logo 100 pixels wide just to make sure it does not take up the whole screen on the Kindle 2, the logo is going to lose a lot of quality. The resolution of Kindle E Ink screen is 167 pixels per inch, much better than just about any computer monitor available. Images in Kindle books should be allowed to take advantage of that amazing resolution and to take up consistent space on the screen, giving content creators more flexibility in designing eBooks that look great and provide the best reader experience possible.
In conclusion, I sincerely hope that Amazon releases updated versions of Mobipocket Creator and Mobigen, and that they remedy the issues with optimized eBook files and image up-scaling. As always, I will be closely watching the Kindle format, and I will keep you up-to-date if anything changes.
Hat tip to John at Reader Plates for the calibre solution.
Labels: Formatting, Tech Info
posted by Joshua Tallent at 9:44 PM
Links:
Helpful Links
Introduction to the Kindle
Kindle Boards
Amazon Digital Text Platform (DTP)
DTP Forums
My posts on DTP
Independent Author Publishing Guides
Blogs
TeleRead
Kindle Reader
EduKindle
Blog Kindle
Kindleville - Joe Wikert
Windwalker
Amazon's Official Kindle Blog
Kindle Review
The Bookish Dilettante
Indie Author Guide
Read a sample of Kindle Formatting: The Complete Guide right now.
Recent Projects:
Fiction
| Entranscing |
The Pro-Am Murders (Dion Quince) |
| Jumble Pie: A Novel |
Thaddeus T. and Barnaby |
Non-Fiction
| Washington State Road Atlas |
OH BOY! The Life and Music of Rock 'n' Roll Pioneer Buddy Holly |
| Sodium Bicarbonate - Rich Man's Poor Man's Cancer Treatment |
Power Path to Love |
see all
Recent Posts
- eBooks are ugly, but it is not the fonts
- eBook Reader Screens
- Kindle Formatting: The Complete Guide is now avail...
- Free eBooks for Read an eBook Week
- Kindle on the iPhone
- Kindle 2 Review, the Formatting Perspective
- Interview on Teleread
- Now Accepting Credit Cards
- Greek text on the Kindle
- Kindle Firmware version 1.2
Blogger makes this page break the XHTML strict standards.
10 Comments:
The hisrc (hirsrc?) option can be used to prevent the Kindle from doubling the size of images.
Alan,
Thanks for pointing out the hisrc option in Mobipocket (www.mobipocket.com/dev/article.asp?BaseFolder=prcgen&File=images.htm). Unfortunately, that doesn't work on the Kindle. My 744px x 1022px image set up as the hisrc option is being displayed at about 2/3 its real size, which means the Kindle is still re-sizing the image from its true size, only now it is reducing it.
Also, the K2 does not display a smaller image set up as src or as losrc, so the goal of making a single book file for multiple devices breaks down. Maybe the Kindle 2 screen resolution is too good for that change-over to work based on the current Mobipocket source coding.
- Joshua
I have seen reports that hisrc works for images smaller than the screen size on the Kindle 1 and 2. It prevents these from being rescaled.
I think your 744px x 1022px experience must have been mobigen downscaling the image in the MOBI file (or it is a bug with the KDX rescaling to the K2 size). The best way to confirm this is to use Calibre to explode the MOBI (mobi2oeb or any2epub).
Yeah, Mobipocket is scaling the image to 515px x 708px. There does not seem to be a way around that.
I guess using hisrc as a hack would work for the smaller images, but I would be concerned because:
1) it would not be using the command for its intended purpose, and
2) on the off chance that Amazon actually puts some programming into the format again, any books using the hisrc in this way could be broken.
I just wish the standards were more clear, more useful, and more followed.
I've been playing with your book trying to insert waypoints for a file that I'm building for Kindle, I've gone over the file many times, but it just isn't working right, I don't see anything that gives me extra navigation on the bottom of the Kindle.
I would like to have the my book behave very much like the WashingtonPost does, with Sections and Articles (Actually I'm producing a large newsletter).
Is there anything I'm missing? It's kind of frustrating that Amazon doesn't give more assistance.
Philip,
I cover the addition of waypoints in the location bar using the NCX file in Chapter 7 of my book. However, that does not cover the creation of the same navigation bar you see in newspapers and magazines on the Kindle. I have not been able to replicate that formatting so far.
If you figure something out, please let me know!
Just a thanks for a very interesting column. Am enjoying Alan's info too.
Here's how I'm approaching the image size issue.
The main issue is the 64k image limit of the file format. To get around that you need to arrange to give mobigen or mobipocket creator only images which are already less than 64k in size.
Also you need to make sure you give it only jpg and gif formats. PNG is a valid input format but will get converted to JPG. This is a good choice for pictures but line drawings, text, charts, etc. often can be done with less loss in GIF than in JPG.
A good (free) way to do size-targeted image conversion is using RIOT, either as a plugin to IrfanView ("file/save for web") or using the standalone program. It has a "compress to size" button where you give it a size (i.e. 64k) and it will tweak the quality settings to meet that target.
If you have a picture or complex drawing, you are probably best off with saving to JPG. In this case it the "compress to size" button will adjust the "quality" slider to what is needed to achieve that size. In general if it goes below 55 or so on the slider you should probably reduce the image size and try again because the artifacts become very noticeable below that. You are probably also wasting space if the slider adjusts to over 75, or 85 at most. You aren't going to notice much if any improvement, especially on an ebook reader.
If you are starting with a line drawing, text, chart, or other low-complexity image then GIF is probably a better bet. GIF is limited to 256 colors, but this materiel seldom uses more than that. The main tweak here is how many colors are used. The fewer colors the less space. Usually a 16-color image is adequate, not because that is the Kindle display capability but because this is where GIF has an advantage over JPG. If you can't achieve acceptable results, try to see what results you get with JPG before reducing size. But it is possible to get 16-color line drawings in under-64k GIF files at full DX resolution.
Thanks for the input, jlick. It is still frustrating that you have to adjust image quality to get decent images on the DX. It would be fairly trivial for Amazon to make Mobigen/Creator allow images larger than 64KB.
The problem with working around the limit in the standard tools is that the format spec for the file has a 64k limit per record, so you would have to violate the format to do so. I've found others complaining that some ebook readers will accept it while others will not, so at minimum they would need to add some kind of setting on whether or not to allow exceeding the limit. You would also want to verify that all of the Kindle options (1, 2, DX, iPhone/iPod Touch) can all support that, and then if you want to release on other platforms you would again need to be careful... etc. etc.
The more relevant point is that, given the limit, while the standard tools do an adequate job of automatically forcing things to under 64k, those choices are not always the best. By generating the best possible 64k files to begin with you can ensure that the tools won't have the opportunity to do any further damage.
PS- Forgot to mention that there's a bit of fudge factor where 64k or 63k files might still get re-encoded. To be absolutely sure, use a target size of 62k.
Post a Comment
Links to this post:
Create a Link