The file is 1.9MB. When I compile for epub, the resulting cover file ends up with the same dimensions and ppi, but the file size is 373KB. That is what I find in Sigil. It is clearly getting saved in a more compressed form. However, the other image files in the book are getting passed through to epub unchanged.
I’ve learned a little more about KDP since I wrote this, and it looks like the publishing process requires providing a separate cover file. So this issue shouldn’t affect my plan to publish. I’m still interested to know why the cover file is getting compressed.
It wouldn’t be unusual for the size of a file to change when saved using a different engine, even with PNG. Some engines will do better than others at reducing redundant data, have different compression settings baked in (PNG offers nine levels that trade de-/compression speed vs size), different amounts of metadata (EXIF/XMP/colour profiles/etc.) or embedded thumbnails. And of course if the original is JPG, that can result in even more dramatic changes to the file size as the original can sometimes be saved with very little compression but you would hardly ever want to use that for production output (a 2mb+ ebook on account of the cover alone is an entirely unnecessary amount of bloat for what most people will see as a business card sized graphic or in B&W).
Case in point, if you compile the stock Novel template with its example Cover.png file, you’ll find it actually comes out larger in Sigil, at a file size level. The actual raster itself though is the same size, which is really what matters the most, as well as visual quality. You can’t get too hung up on the file size itself outside of trying to target a reasonable size. That can change a lot depending even on the image itself. A full sized cover image that is 95% solid blue will compress much more efficiently than a photograph of a mountain.
I’ve learned a little more about KDP since I wrote this, and it looks like the publishing process requires providing a separate cover file.
I can’t say for sure, as much of Amazon is mysterious, but it would surprise me if they are disregarding the cover image in the .epub file and replacing it with that one. Reason being, if they were doing that, then they could very easily extract that image for the store listing page and other purposes. The fact that they request a separate file means they do not want to add the complexity of parsing out and extracting the cover image in the first place.
But again, it’s Amazon. The stuff they do frequently makes no sense at all and is clearly the result of multiple committees that haven’t even bothered to send an interdepartmental memo in the past decade or two.
I found a statement about this: “Don’t include your cover image in your manuscript file. When you publish your eBook, we’ll automatically add the cover image you provide during title setup.” (eBook Manuscript Formatting Guide).
I appreciate the explanation, but the thing is, this is not what I am experiencing! The images, except for the cover in the resulting epub file are the same as they were in the editor: dimensions, ppi, file size.
Only the cover file is getting changed. So it stands to reason that the compiler is handling it differently. And I just wonder what the reason is.
I think the key phrase, at the very beginning of that document you linked to, is: “The info below is specific to Microsoft Word 2016, but the steps are similar to other versions of Word.”.
So it would make sense to separate the cover image in the upload, since any way of embedding it in the .docx would be awkward.
Only the cover file is getting changed. So it stands to reason that the compiler is handling it differently. And I just wonder what the reason is.
You are seeing the actual image size changed? I don’t know what might cause that. I haven’t checked, but I don’t think even the option to resample images that are too wide, in the General options tab of compile, would impact the cover graphic.
Okay, I think a minimal example project would help us see what is going on. If I drop a 1600x2500px image into the project and set it be used as the cover image, and then also place that image into the text somewhere, I get two copies of the image that are identical in terms of resolution. They file sizes are different, which does indicate different PNG compression settings (one is bespoke code, the other is I believe all handled by the Mac text engine, so that isn’t terribly surprising), or something along those lines, but again the image itself is the same in all meaningful ways.
You might need to send the sample to tech support in an email, as you could run into forum attachment size limits here. I’d construct it similarly to how I described the test above. Just one text item in the Draft with a little sample text, and then drop the same image you’re using for the cover into it, so it gets exported twice.
With due respect, wouldn’t it be simpler and more effective to ask the compiler team to check the code and try to reconstruct the reason for the compression of the cover image, leaving other images untouched?
In any case, this isn’t a crucial issue for me. If KDP want the image in the epub file, I’ll just put it back in. The dimensions and ppi are still what they recommend, and your’re right in saying that a high-quality jpg file is probably overkill.
Perhaps the compiler has some sort of threshhold over which it compresses the image file, which is why the other, smaller image files go through unchanged, while the bigger cover file gets compressed.
Yeah, like I say, I cannot reproduce it, so it is likely data related rather than procedural. There is no “compiler team”. There is one programmer that writes all of Scrivener, and I am one of two people that investigates and writes up reports on eight different programs.
So if you have the time (it shouldn’t take more than 30 seconds to make a test project like I described, and another 30 to send the .zip), we’d be grateful and will take a look at what is going on—if there is indeed even a problem or a bug to begin with, or if this is just a case of benign optimisation. I don’t even know what file type you are testing with, to emphasise how little I can do with your report at this point.
But if you don’t have the time, and don’t really care too much, that’s okay too! Like I say, compression isn’t always predictable and anyway in this case it seems we’re doing your book a favour by knocking an unnecessary 1.5mb off of its deployment size.
