Mobigen formatting cover for mobi: current thoughts

[JaneFancher]

Weird, this "prefix" thing. I'm not sure mobigen is appropriate. Is that what they're calling kindlegen these days?

OK...regarding Amazon publishing: I'm probably showing my age, but a whole two years ago, we were advised to create a cover that was 800 px max and 130kb max for publishing on Amazon. As I understood it, no matter the size cover you uploaded, their kindlegen-in-disguise resized it to under those dimensions.

Since I create my mobi file before uploading, I would resize the cover, adjust compression to just under 130, then generate my file using a combination of MPC and kindlegen.

I never worried about it. Seemed my covers were looking pretty snazzy at that size...perfectly adequate for electronic viewing...tho not so good for printing. Seemed a good compromise since I didn't really want people printing my covers anyway.

I see now, however, that Amazon is recommending 2500px max! They make this big thing about making your covers look as good as possible and obviously, bigger is better, right? Not sure about that, but being curious, I tried changing a cover in an existing epub file to a large png and converting with Kindlegen. This gave me a nice sharp cover and a HUGE mobi file. (8M)

(Lest the above sounds strange to some...I've changed my process. I now do all my cleanup in epub/sigil, then convert using kindlegen. This has given me great results, but it does require a pretty sound knowledge of epub to insert all the necessary thumbnails and TOC/beginning pointers kindle requires!)

Anyway, the last time I added a cover to a file using Calibre, it was still resizing the cover to under 800 px. I sort of trust Calibre to stay up on all this stuff, but now...I'm wondering.

What I'm asking of all you lovely folk who stay up to speed on all this is: What's the current thinking? What's the optimal size for a cover image for ebooks in general? I can evidently slip whatever I want into a file on my computer, but does anyone know what's going to happen if I publish with that large cover image on Amazon or B&N?

And as a side note on this entire topic: is Amazon still charging an extra download fee for files over a certain size? It that why they're suggesting these huge cover images (not to mention packing a million formats into a single mobi file?) (I looked on the publishing site but couldn't find that particular topic addressed anywhere)

As always,

Calibre is good for a lot of things, but I wouldn't use it for creating an original book. I use an HTML design app called Dreamweaver to create my HTML files. Then like you do I use Sigil to manage these files and to compile them into an ePub. I don't feed the ePub directly into KindleGen though, instead I unzip the ePub, tweak the OPF file a bit, then feed the OPF file into KindleGen.

For covers I typically use a 600 x 800 px image saved at 300 dpi. I realize that is smaller than some device screens like the new Kindle Fire, but it seems to work fine.

EDIT: The Amazon Kindle Publishing Guidelines recommends covers be 600 x 800 px (p. 10) and that images be saved at 300 dpi resolution (p. 14).

[AThirstyMind]

As I understood the Amazon cover update (as well as Smashwords), the large file was to be used as your display cover (displayed on your Amazon/Kindle product page) and uploaded through your dashboard at KDP. For the actual cover of your book, I believe the specs have not changed (and I add that cover through the metadata file). I use now 800x 1280 (a ratio of 1.6 as Amazon specifies) and try to keep the file size down below 1mg. For internal images I think the max image size is 250kb but I could be in error here.

[Hitch]

Originally Posted by JaneFancher

And as a side note on this entire topic: is Amazon still charging an extra download fee for files over a certain size? It that why they're suggesting these huge cover images (not to mention packing a million formats into a single mobi file?) (I looked on the publishing site but couldn't find that particular topic addressed anywhere)

As always,

Amazon's charged those delivery fees forever; it's not files over a certain size, as far as I recall back. It's $0.15/mb. And the real reason that they switched to having "publishers" use the product image which they now turn around and embed in the file, is because so many books were getting so screwed up, particularly those being uploaded in Word. I think that they decided the the customer support burden was so high (I can empathize) that it was simpler to just go with "one cover to rule them all" and elected the product image as the one-size-fits-all option.

We still embed 600x800's in our books. I had a client that tried to upload a cover that was, I kid thee not, over 13,000 pixels on one side (and complained that our book "isn't any good because the upload won't go.") We get upload questions...hell, I don't know, 2 out of every 5 customers? Despite Amazon's step-by-step uploading Help section? I can't imagine what Amazon's support load is like, so I can't quite blame them for going to ONE upload, ONE set of dimensions. I have at least 2 competitors who've left the business because of the customer service burden--so I suspect that Amazon has just determined to do whatever costs them less in supporting people who aren't equipped to be publishing their own books--but do, anyway.

FWIW.

Hitch

[JaneFancher]

Thanks everyone! Good info as always.

Sounds like I can keep doing as I was. I always upload a ready-to-go mobi file on Amazon and they seem to work fine.

[sundog]

As I read the new guidelines on the upload pages while trying to upload my first book, it's pretty clear they are indeed now using this one file upload procedure. It stopped me in my tracks. What I don't understand is whether I need to now go back and remove the cover image file I embedded in my .mobi (so as to avoid duplicate cover pages)? Hitch, you say you still leave your 600x800 files in there, so, do you see 2 cover pages now? Also, what's your experience with Amazon's ability to produce a quality embedded cover image from your larger cover file upload that is also reasonably well compressed (to avoid excessive delivery charges)?

[Hitch]

Originally Posted by sundog

As I read the new guidelines on the upload pages while trying to upload my first book, it's pretty clear they are indeed now using this one file upload procedure. It stopped me in my tracks. What I don't understand is whether I need to now go back and remove the cover image file I embedded in my .mobi (so as to avoid duplicate cover pages)? Hitch, you say you still leave your 600x800 files in there, so, do you see 2 cover pages now? Also, what's your experience with Amazon's ability to produce a quality embedded cover image from your larger cover file upload that is also reasonably well compressed (to avoid excessive delivery charges)?

Hi, Sundog:

Well, I just tested a mobi that was made with a 600x800 original cover size (n.b.: we make our mobi's from ePUBs, via Previewer and/or Kindlegen, depending upon which Crew here you query. The NoteTab Pro crowd explode the ePUB and feed the OPF to KG; the PERL gang feed the ePUB to Previewer--six of one, half-dozen, etc.) I uploaded the mobi (1.839KB) with the embedded 600x800, and then I uploaded our "standard" 960x1280px jpeg as the product image. The final file was fine, no dual-covers (and I've had no reports of same in somewhere between 3-500 books we've done since the changeover--I can't remember what date they took the "option" out), and the final file is 1.7MB...so it seems to work fine.

I'm pretty sure if we were accidentally creating dual covers, I'd have heard by now from one of our clients; I mean, they pour over the samples and Look Insides relentlessly, so certainly out of that many hundreds done in this timeframe, I'd know.

Does that help? Covers look great, or as great as can be realistically expected with that compression ratio. It's hard to walk the fence between the "product image" needs and the embedded cover needs, and so you get some lossiness, no two ways about it--but remember: the bottom line, no matter how painful it is, is that most purchasers don't really look at the embedded cover anyway--it's a pre-sale item. If you have to choose, choose what will look good on the Amazon/B&N website, not INSIDE the book, because the "grabber" is the product image version. Now--that's just my opinion, and worth what you just paid for it. ;-)

HTH,
Hitch

[sundog]

Originally Posted by Hitch

Hi, Sundog:

Well, I just tested a mobi that was made with a 600x800 original cover size (n.b.: we make our mobi's from ePUBs, via Previewer and/or Kindlegen, depending upon which Crew here you query. The NoteTab Pro crowd explode the ePUB and feed the OPF to KG; the PERL gang feed the ePUB to Previewer--six of one, half-dozen, etc.) I uploaded the mobi (1.839KB) with the embedded 600x800, and then I uploaded our "standard" 960x1280px jpeg as the product image. The final file was fine, no dual-covers (and I've had no reports of same in somewhere between 3-500 books we've done since the changeover--I can't remember what date they took the "option" out), and the final file is 1.7MB...so it seems to work fine.

I'm pretty sure if we were accidentally creating dual covers, I'd have heard by now from one of our clients; I mean, they pour over the samples and Look Insides relentlessly, so certainly out of that many hundreds done in this timeframe, I'd know.

Does that help? Covers look great, or as great as can be realistically expected with that compression ratio. It's hard to walk the fence between the "product image" needs and the embedded cover needs, and so you get some lossiness, no two ways about it--but remember: the bottom line, no matter how painful it is, is that most purchasers don't really look at the embedded cover anyway--it's a pre-sale item. If you have to choose, choose what will look good on the Amazon/B&N website, not INSIDE the book, because the "grabber" is the product image version. Now--that's just my opinion, and worth what you just paid for it. ;-)

HTH,
Hitch

Thanks Hitch, very helpful. Great to know there are no dual cover issues, and since your file size actually decreased I can only assume Amazon removed your 600x800 cover from the file, and fed in the new one (compressed), without adding to the files size. Bodes well for delivery cost

In my test last night on the Amazon upload site, I had a 600x800 image embedded, then uploaded a larger cover image file (1612x2474) with different aspect ratio (closer to the recommended 1.6 ratio). Upon conversion on uploading my book file, the embedded cover was replaced with a compressed version of the larger, different aspect ratio file, which didn't fill the screen properly in the Previewer on the Amazon site. So while I'm fine with their new single upload process in terms of having the embedded cover replaced, I don't understand why they recommend the 1.6 ratio of that doesn't fill the screen when they convert. I will go back and upload a larger file having the same 1.33 ratio as the 600x800, which is what I understand you did.

[JSWolf]

Are your 600x800 covers aspect ratio correct or are they stretched to fill 600x800?

I have to agree with Amazon that a cover of 800 lines is not large enough given that these eBook could be read on devices with much higher resolution.

Originally Posted by JSWolf

Are your 600x800 covers aspect ratio correct or are they stretched to fill 600x800?

I have to agree with Amazon that a cover of 800 lines is not large enough given that these eBook could be read on devices with much higher resolution.

As I stated in post #2 of this thread, Amazon recommends 600x800 px covers saved at 300 dpi resolution. Let us be honest though, does the cover image have to look super great in full view? After all how many times does the average reader even see that full size (full screen cover). The reader usually has to back page to even see it while reading, and regardless of device most of the times the cover is displayed for a book it will be the thumbnail version. Users are going to see the thumbnail version perhaps a hundred times more often than they will see the full screen version. If Amazon ever allows us to display the full size cover on the sleep screen rather than their stupid screensavers and worthless special crap offers then the full size image will be worth fussing over. Otherwise, the most use the full size cover will get is when it is displayed on the Amazon.com web site in the book store. So I think just make a nice looking 600x800 px cover and not worry if it looks good on larger devices.

[sundog]

@ JSwolf-My various file sizes are all source generated as needed, not stretched.

@ jswinden-I originally intended to follow your rationale exactly and had prepared my file accordingly, but when I went to upload, the instructions said I had to provide a single upload file that will replace what is embedded (which it now does) AND that the uploaded file has to be minimum 1000px on the long dimension, 2500px recommended. That's why I came asking for advice.

As I said, my current plan is create and upload a file that meets the minimum 1000px requirement, but the question remains about the ratio. Amazon recommends a ratio of 1.6, which I'm assuming is to make a good looking website image, but that will not result in a full screen embedded image. Given the apparent new need to choose, is your advice to not worry about the embedded image filling the screen and go with the 1.6 ratio, or do you plan to continue to submit covers at the 1.33 ratio (whether 600x800 or larger)?

Originally Posted by sundog

@ JSwolf-My various file sizes are all source generated as needed, not stretched.

@ jswinden-I originally intended to follow your rationale exactly and had prepared my file accordingly, but when I went to upload, the instructions said I had to provide a single upload file that will replace what is embedded (which it now does) AND that the uploaded file has to be minimum 1000px on the long dimension, 2500px recommended. That's why I came asking for advice.

As I said, my current plan is create and upload a file that meets the minimum 1000px requirement, but the question remains about the ratio. Amazon recommends a ratio of 1.6, which I'm assuming is to make a good looking website image, but that will not result in a full screen embedded image. Given the apparent new need to choose, is your advice to not worry about the embedded image filling the screen and go with the 1.6 ratio, or do you plan to continue to submit covers at the 1.33 ratio (whether 600x800 or larger)?

I submitted a book in May and followed the instructions in the Amazon Kindle Publishing Guidelines about using the 600x800 px cover. It went through their process without issue. But knowing Amazon they may have changed the process 2 or 3 times since then!

[Hitch]

Originally Posted by jswinden

I submitted a book in May and followed the instructions in the Amazon Kindle Publishing Guidelines about using the 600x800 px cover. It went through their process without issue. But knowing Amazon they may have changed the process 2 or 3 times since then!

Hey, Jack:

Indeed--their latest attempts to be super-helpful are to ensure that an author CANNOT upload an image (via the separate product image upload feature) that does not meet the 1,000px criterion. I've had clients call mid-upload for a book in a swivet, because they didn't keep the larger copies that their designer gave them and have had to send them the original images we used for the book for this very reason.

@sundog:

I can only assume Amazon removed your 600x800 cover from the file, and fed in the new one (compressed), without adding to the files size.

Yes, looking at the embedded image that has "replaced" the original 600x800, that certainly seems to be the case. Not really happy-making, as the original was right for its purpose, and the compressed larger version is not as crisp, but as I and others have said, I'd choose the crisper web image over the embedded image in any scenario.

HTH,
Hitch

[JSWolf]

Originally Posted by sundog

As I said, my current plan is create and upload a file that meets the minimum 1000px requirement, but the question remains about the ratio. Amazon recommends a ratio of 1.6, which I'm assuming is to make a good looking website image, but that will not result in a full screen embedded image. Given the apparent new need to choose, is your advice to not worry about the embedded image filling the screen and go with the 1.6 ratio, or do you plan to continue to submit covers at the 1.33 ratio (whether 600x800 or larger)?

I would do 1024 lines as your minimum. That's a more useful resolution then 1000.

[DreamWriter]

I'm formatting an ebook for publication right now.

Since Amazon now uses the product page cover for the Kindle file, do we not declare a cover in the OPF? I will be uploading a .mobi file that has KF8/.mobi CSS, created using KindleGen.