I'm starting a new book that will have a lot of pictures. I think I'll follow Peter Spenser's advice and have them all centered with text wrapping top and bottom. If this were a web page, I could set the size as a percentage of the horizontal screen space. Can I re-size my photo with a pixel count that will do the same thing? I do a lot of work in Photoshop and would find re-sizing there fairly easy.

I'd like to have photos, for instance, that I know will be three-quarters, or half, or the full width of the screen. Since different Kindle models have different sizes, I'd need an approximate pixel count. The size doesn't have to be PRECISELY a percentage of the screen.

My thought is that this will minimize total file size, compared to shrinking them in Word. And since my page size in Word is not going to be the final page size, I find resizing them there a shot in the dark.

With Word, you can format a picture to a certain size – let's say 2 1/2 inches, this is narrower than the standard Kindle screen width of 3 1/2 inches and if it is centered you will have an image that has a 1/2 inch border on either side.

Incidentally your text layout should be "In line With Text" and no text wrapping should be specified.

When you specify an image size, the Kindle format will display it at the specified size until the maximum screen size is reached and then it becomes a full page image. If you specify an image, of let's say 4 inches in width, on the standard E ink screen this will be wider than the screen, and will be displayed as a full page image.

On the Kindle DX, the screen width is around 5 inches, so your 4 inch wide image will be displayed at 4 inches in width (I am not messing with heights here because most images or wider than they are tall with regard to Kindle displays)

On the same subject, if I display the same 4 inch wide image on my android phone which is about 2 inches wide it will come up as a full page image (as would the 2 1/2 inch image mentioned at the beginning of this discussion)

in HTML, you can also specify pixel size, and the ratio is about 171 or 172 pixels per inch. The same rules apply, if you call for a size that is larger than the screen display it will simply be displayed as a full page image.

I am afraid that I do not know of any way to have a percentage of page size type image display.

Yes indeed. The rule of thumb is to size a vertical image at 600x800 pixels. I use 72 ppi but Amazon recommends 300 ppi for "future proofing." However, it also says the maximum size is 127KB, and 600x800x72 comes out very close to that.

You can have a narrower image, say 500x800. Or you can have a shorter image, say 600x500. But use 600 and 800 as the outside limits.

You can specify in your link (assuming you are writing html) the actual size, but it is rarely necessary to do this.

You can't wrap text around an image in the Kindle format as it now exists.

Note that if you have a caption, it will very often appear on a separate page, especially if you are using a vertical image. One way around this is to work the information into the preceding text.

There are a couple of images in my book, http://www.amazon.com/dp/B007F14XM8/, that might give you some perspective to go by. They originally were 356 pixels wide and were placed into my Word manuscript without any re-sizing. The are listed there as being 4.94 inches wide. On an e-ink Kindle screen they occupy approximately two-thirds of the width of the text block (not of the entire screen width, which includes some margin space).

If you want to look them over for yourself, they can be found in the book right after the phrase “one of three windows” if you do a search.

I'm still not certain about formatting photos for a Kindle. In your "Anyone" book, Peter, you brush by dpi and ppi. In working with websites, I've found that enhancing the photo in Photoshop before I upload it gives better results than letting the various web software programs mess with it. A 1200 x 1800 pixel photo will vary in size considerably if it's 72 pixels per inch (ppi) or 300 ppi.

In olden days, they said to make anything for the web 72 ppi because that's all monitors were capable of seeing. And in fact, a 300 ppi photo looked a little strange on a website. But because of advancements in monitors, the new recommended size (depending on who's recommending) seems to be 96 or 120.

So my original question in this post really needs to begin with ppi, because the same width pixels and height pixels will give you very different results in size depending on how tightly they're squeezed when all the conversion processes are finished..

The cover JPEG file for [i]Shortcuts for Windows PCs[/i] which I uploaded Sunday was 1320 by 2040 pixels at 240 ppi. A total of 2.7 million pixels, which exceeds the total 2 million maximum pixel size your book in Section 7.2 says the Apple IBookstore will accept. Does Kindle have a similar maximum limit for a JPEG photo?

You seem to be saying that it's good to push the limit on the cover because you know that it's going to fill the entire screen. Any size (within limits) can always be squeezed and still look good.

So back to my original question (and this is important because the next book will contain between 100 and 150 photos):

What should the ppi resolution be? I think I can figure screen size based on pixel W&H. But that will always depend on ppi. What is the recommended ppi for Kindle screens?

The dpi/ppi of an image is [i]entirely[/i] irrelevant to the display of your images on Kindle. This is true for digital displays of all kinds, not just Kindle. Unless you are printing an image dpi is pure metadata. It neither adds nor subtracts information from the image.

What does determine the informational content of an image (for this discussion assume image == uncompressed bitmap, to the sake of clarity) is the [b]resolution[/b]. This is the number of pixels, horizontally and vertically, that comprise the image, and is the [i]only[/i] metric you should be concerned with when determining the display size of your images for Kindle.

As to your original question, an eInk Kindle has a native screen resolution of 600x800 pixels. Kindle Fire is 600x1024. Most mobile platforms that have Kindle apps have screen resolutions in that general range.

So if you want to make an image that is "about" 1/3 the width of the screen you'd prepare it at a width of 200px. Be aware that you will need to manually assign both width [i]and[/i] height values to the HTML image tag if you want to prevent the image from being doubled in size on eInk Kindles. Keep in mind that the image will be scaled smaller than that if it happens to be taller than the content display area on the device being used to display the book.

The above only applies to Mobi7. In Kindle Format 8 (KF8) an image can be scaled to a specific percentage of the host display width, regardless of the image's resolution, so long as the height of the image at that scale will still fit on the screen. Obviously you'll have to drop Calibre to take advantage of KF8, but as it's an eBook [b]management[/b] program with limited utility for serious production, that probably isn't a bad idea anyway.

Kindle and Nook each have screens that are 167 ppi. Fire's screen is still only 169 ppi. So even if more pixels made a difference for on-screen viewing, Fire doesn't have enough resolution for it to matter. But as Mr. Lasers says, it shouldn't matter what the dpi/ppi of an image is when displayed on-screen. Those only matter for printed material. I don't know if Fire can print higher rez images or not. I think you still have to do a screen capture with it to print an image. Chances are that the screen cap will be at 96dpi anyway with no way of changing it. At least I know you can't change the screen cap resolution in a Kindle, so I'm assuming the same for Fire. I would ignore the guide on this one.

Bookwrench, remember that my book is aimed at non-technical users, people who should not have to be left out of publishing their relatively simple books merely because they are not programmers. That is why I chose to “brush by” the subject of d.p.i./p.p.i.

I’m not sure how many more ways Mr. Lasers could explain that to you that it doesn’t matter. He’s done a pretty good job and you still seem to not really believe it because of your own past experience and because of Amazon’s Guidelines. (Section 3.5.1 is where the contentious 300 p.p.i. reference appears.)

The past experience which you cite has been with web browsers and paint programs, not with e-books. The short piece of metadata attached to a bitmapped image that sets out its d.p.i./p.p.i. value is interpreted and used by web browsers, and paint programs, and e-book devices (or apps) in different ways. E-book devices ignore it. It’s as simple as that.

The pixel size (which, you are correct, is not the same as the resolution; some people have misunderstood that) of the image is the important part, but just as important is what happens to the image as it’s being sucked up into Amazon’s computers. [b]Exactly[/b] what happens to them is unclear from the Guidelines (which seem to have been cobbled together by different technical writers over the years), but a couple of things are clear:

• there are different specs for cover images and for internal images.
• the new maximum byte size for internal images is 256 kb.
• the new maximum longest dimension for a cover image is 2500 pixels.
• the cover image which is uploaded in Step 4 of the K.D.P. process is [i]probably[/i] the image that will be used for the cover.
• it is now [i]probably[/i] unnecessary to include a cover image within the book file.

As for Amazon and Apple and the two-million-pixel limit: Amazon’s recommended cover maximum is 2500 by 1560. That’s 3,900,000 pixels, but that’s for the “catalog” cover, so it will look nice for Amazon’s customers. I would be surprised if Amazon did not squeeze that down when the cover is placed within the book file. (I have not done tests yet, but some of the other techie guys can easily do so.) Apple’s limit is still two million pixels for all images, and they recommend that images be created at 1.5 times the final intended viewing size, up to that two million limit. That makes a single-page, full-bleed image to be approximately 1200 by 1600 (1,900,000 pixels total), which happens to be what I’ve always used for all of my covers: iPad, Nook, Kindle, Sony, and Kobo, and it works well.

Anybody have much experience uploading epubs to PubIt!? Their guide just says that the Nook's screen size is 600 x 730 and to optimize images (compress them) like you would for the web. It says nothing more.

I've only published one book with them that has images in it (about 30), and the book looks fine in Adobe Digital Editions, but I haven't viewed it on my Nook yet. I'm guessing epub will resize images automatically just like mobi files do.

I can see a 4th one that may be important to some people. Right now you cannot directly print from any Kindle or Fire device. But perhaps someday you will be able to. I know a girl who subscribes to knitting and crochet magazines with her Kindle. She says she would like to be able to print out crochet patterns so she doesn't have to keep turning on her Kindle to look at them. The Kindle guidelines say:

The short piece of metadata attached to a bitmapped image that sets out its d.p.i./p.p.i. value is interpreted and used by web browsers, and paint programs, and e-book devices (or apps) in different ways. E-book devices ignore it. It’s as simple as that. **

No web browser interprets ppi/dpi (from here out "ppi" as "dpi" more accurately describes something else) for the display of webpages. I suppose some might use it for printing, but I'm unaware of any current or past browser that does so. I will obviously not be installing every browser back to Mosaic, on every supported platform, to prove or disprove that irrelevant point.

Paint packages do make use of ppi, but in general this too is irrelevant [i]unless you are printing[/i]. Here's a quick test you can do to confirm this in your favorite paint program.

1. Create an image (img-a) with a print size of 1x1in at 100ppi (100x100px).
2. Create a second image (img-b) with a print size of 1x1in at 300dpi (300x300px).
3. Import img-a into img-b, or drag a layer (whatever your paint package supports).
4. Notice how the imported img-a takes up one third of the width and height (100x100px) of img-b, not the entire print area of img-b (1x1in).

You can of course scale an image in any decent paint package by its print dimensions (inches, mm, etc.). However, in these cases the program is merely extrapolating the new pixel dimensions from the ppi. This at no point makes ppi anything but metadata.

The pixel size (which, you are correct, is not the same as the resolution; some people have misunderstood that) **

Yes, some people [i]have[/i] misunderstood that, yourself among them. The term "resolution" is commonly, and accurately, used to refer to the pixel size of a raster image. It may occasionally be called "pixel resolution" (or similar) to differentiate it from other "resolutions" involved with digital images, such as "color resolution" (bit depth), "print resolution" (ppi), or physical printer "resolution" (dpi).

This is Digital Imaging 101 and it's astounding how many people come through here, claiming to be experts, who can't seem to grasp these basic concepts.