Answering These 2 Questions Could Save Me A Lot of Work

I only recently discovered the Scrivener converts all my JPG files to PNG format. To minimize the double compression this causes, I am going to create PNG versions of all the 42 images in my book, and go back and unlink the old image links, and create new image links to the PNGs.

Before I go through this lengthy process, here are my two questions:

  1. Is there any way to prevent the conversion to PNGs?
  2. Will linking to PNG files, as described above, be the best strategy for dealing with this?

Thanks for the help,


The conversion to PNG happens as part of saving the image in the RTF document. This is being addressed in the update, and should be working by the next beta release. There’s no way to prevent the conversion currently, so your options are to do the linking as you propose, wait for the beta release containing a fix, or to swap the images post-compile by replacing them in the epub file in Sigil. If all your images are meant to be JPGs and use unique names, that should be a relativelys imple matter of running a find and replace on “.png” to “.jpg” and replacing the existing images from the Images folder with your originals from the hard drive. If you have a mix, you’ll need to refine the replacements a bit, but I’d guess it would still be simpler than recreating the images as PNG and redoing all the links in Scrivener.

Thanks, MM. I had thought that this was intentional, and it’s good that you’ll be fixing it. The next beta release may be too late for me.

Note that the option of changing the links in the ePub file isn’t feasible, since the names of the images are changed to thing like, and 8594038475938293.png.

Sorry, I forgot that was the case in 1.6.1. If you use the beta, the names of the images are used, so that should solve that part of the problem for you.

I just compiled to ePub with and the names were not preserved. The project was originally created with 1.6.1.

Any ideas?

Yes, I just confirmed that if I create a new project with the beta, in insert an image, it preserves the name.

Any way to get that same thing without reinserting the images?

Are the images named in the documents, if you right-click and choose Edit Image? It should be pulling the name from that.

Doing that will only tell me the numbered filename (like 847563746384683.png), so that won’t help much. But that’s OK, I’ll just reinsert the highest quality images, and not worry about the others. The image quality is OK even with the JPG to PNG to JPG conversions.

Remember that PNG, just like GIF, is a lossless encoding format, so you won’t lose quality when converting to it. That’s why a PNG file is, in general, quite larger that the originating JPG file. Therefore, the fact that you don’t notice quality loss on that “double compression” is not at all surprising.

The field is editable, so just give it a new name; that name will be used for the file when you compile to .epub (or any format that exports images separately, like MMD).

But it is indeed compressed twice in this situation.

When I save an image to a jpg file, it is compressed. That is the first compression.

Scrivener converts it to PNG – there is no compression here.

Kindlegen then converts the PNG to JPG. It is compressed in this stage. This is the second compression.

When the bug is fixed, Scrivener will just copy the JPG into the ePub and Kindlegen will copy it into the MOBI, so there is only one compression.

I found that the easiest way was to create new PNG images, then redo the Edit/Insert/Image Linked…

That took a few hours and worked, but the new mobi file is significantly larger. I’ve heard that the logic that KindleGen uses for compressing files is inscrutable, so I’m hoping a fix for this bug will be available before I publish.

Here’s a general suggestion: Don’t convert the filenames to meaningless strings of numbers. Add numbers to existing filenames only if you have to resolve non-unique names.

Glad you found something that worked. We’re looking at options for dealing with the case of exporting the images as a different type; it’s not as clear-cut as I’d hoped, as “fixing” the problem heavily increases regular memory usage from needing to store additional data for the format types in addition to displaying the images in the editor. To that end, converting the images to PNG was intentional, but the developers are considering how to handle the specific instances where the images need to be exported in their original format.

As previously noted, the image names are used in the beta.

Perhaps you’re not thinking of what happens when compiling to ePub. This is the result I got today. All of the images had been inserted using the beta:

I’ve been doing some experimentation. Here’s something I’ve found:

Create a new project, insert (linked) images, compile, Image name is preserved (TOP).

Close that project, reopen it, compile: Image name is not preserved (BOTTOM).

Sorry, I hadn’t realised you were using linked images vs. embedded images. The difference is there; the image names are changing only for the linked, and the numbering on export is a result of the way the file name is being saved within the project. I’ve ensured it’s on file. Previously images were always numbered as part of the ebook export, regardless of name, so that affected all inserted images, and I was just thinking of that change. Sorry for the confusion.

Today I switched it back to using JPG images. I decided the advantages of a smaller MOBI file (lower delivery costs) outweighed the small increase in image quality. The MOBI file size went from 24 Meg (PNG version) to 19 Meg (JPG version).