Graphics in SCrivener

Hi everyone,

I have two questions in relation with graphics in Scrivener, which I use as a master for my ebook:

  1. When I drag and drop a JPEG file into Scrivener, it automatically resizes the graphics to a much smaller size, for example from 900x900 to 200x200. As the files are made specifically for e-books, so I then have to resize the illustration back to the original size, but apart from the inconvenience I’m not sure there is no loss in quality. Is there a way to prevent Scrivener from automatically resizing a graphic that way?

  2. I want all my illustrations to be in the right size for e-books, so that when I compile in .mobi or other they are in the right size. When I export to PDF, Scrivener nicely resizes the graphics so they fit on the page. However, when I export to MS Word (.docx), the graphics are much bigger so I have to resize them in the Word document so they can fit on the page for my proof-reader. Is there a way to ask Scrivener to resize the graphics so they fit on the page when exporting to MS Word, the way ti does it when printing to PDF?

Many thanks in advance for your help!

Firstly there is no way to use embedded JPEG without losing some quality (it should be very minor), when the JPEG is dropped directly into the editor. I would recommend using the Edit/Insert/Image Linked to File… command, which simply uses the disk copy whenever requested.

Now as for resizing images automatically on drop, that shouldn’t be happening, unless you change the size of the image yourself in Scrivener. I suppose there is one exception, the same one that is used to fit a large image into the PDF. If you’re using Page View in the main editor then images will be visually shrunk (but not actually changed). This is purely a convenience.

By the way this form of resizing will not touch the original pixels in and of itself. It is tweaking the display settings of the image, a subtle distinction, but still probably not a desirable outcome if everything is set up precisely the way you need it to be in the output.

There isn’t, it assumes you’ve used correctly sized graphics (PDF is really more for proofing, we don’t intend for it to replace actual post-production). This is incidentally another point for using linked images. You can keep one set of images for e-books in one folder, and another set of images sized for PDF in another folder. Before loading the project you would set the folder name of the image set you wish to compile with to a name where the linked images will expect to be looking. For example you could have an “images” folder alongside “images-ebook”, and when you’re ready to compile for e-book, change the former to “images-pdf” and the latter to “images”.

Hi Amber,

I thought I had replied but it doesn’t seem to show up…

Thanks for the quick reply, I have played with your instructions and I still have the same problem.

For example, I’m not in page view, I use the edit / insert / image linked to file to import a 900x1071 JPEG, and when it’s displayed in Scrivener if I double click on the graphics it says the current size is 432x514 (it also tells me the original size correctly). If I compile the document to .mobi, the graphics displays really small on the kindle previewer.

If I change the size back to the original size in Scrivener before compiling, then the graphics show at the correct size in Kindle Previewer.

Any idea why this is the case?

Oh, you might be referring to how the system displays and works with graphics in points not pixels. Points are in part based upon the resolution or density of the image. At 72 PPI then points = pixels, but anything above that and the equation changes. From the sounds of it, you’re running graphics at around double that density?

As for Kindle Previewer, and well Kindles in general, it can be a little tricky getting the display size the way you want it, and then when you do it may not look right in older readers that are lower resolution. It’s a bit awkward unfortunately, but my advice is to work on one image, get it displaying the way you want and then make note of that image’s settings and replicate to the rest.

So what it sounds like you are doing is decreasing the density of the image by moving the slider up, reducing the DPI and thus making the pixel to point ratio close to 1:1, resulting in something more expected on the Kindle. Does that make more sense?

Hi Amber,

No, it doesn’t really make sense that I have to adjust a graphics DPI on Scrivener to get it to display at its intended size on the Kindle (yes I have to specify the original size in Scrivener to get a 1:1 ratio) simply because it shrinks it for whatever reason.

I would like to import or link to JPEGs so that they are left untouched, as they are designed to display at the right size on the Kindle.

I have a selection of illustrations made specifically for my e-book, one set is 150 DPI (900 pixels wide), the other 300DPI (1800 pixels wide). I did these test with the 150 DPI set.

I don’t understand why I have to adjust the DPI setting in Scrivener after linking to the graphics so that I bring them back to their original, intended size. Sure this cannot be the way the software is designed, or there must be an option around it to deal with the linked illustrations natively?

Your initial answer made sense as I was simply dropping the files, but now that I’m linking them I don’t understand why when compiling the original, untouched file isn’t used. I don’t mind if the illustration is resized to display it, I just don’t want it to be resized when I compile unless I specifically ask for it. Why would Scrivener shrink all files, including those which are already sized to display properly on older devices?

I should add that the compile option “downsize and resample inline images to visible size” isn’t checked in my ebook formatting template.

Have you checked the files themselves post-compile? If you are just linking them in and not touching the resize slider, they should be the same. You can check by enabling the source file export option in the KindleGen compile pane. When I test with a 900px @150 DPI image the original and the one used to make the Mobi are not identical (they do need to pass through RTF at one point, Scrivener isn’t a native HTML editor), but the dimensions are untouched.

Thanks Amber,

I’ve tried this. The files in the source folder are not only different but much smaller in size. The graphics size and DPI seem to be the same though, which suggests that they are more compressed.

Why can’t Scrivener simply use the files we linked to? Can’t we turn this forced conversion off, so we keep the same quality and size for the files?

This still doesn’t explain why I have to restore the original size in Scrivener to get the software to generate the files in the correct size in the E-book, as it seems the illustration size and DPI is the same as the original files in the source files folder, even if the file size is smaller.

I’ve done another test.

I’ve linked to the same picture to the manuscript. It’s a 900 pixels wide illustration reporting 150DPI in the OS.

I left the first picture untouched, and I’ve adjusted the second one back to its original size.

The untouched picture is reported by Scrivener as 150 DPI with a size of 432x514.

The adjusted one, with a size adjusted back to the original width of 900pixels is reported at 75 DPI.

When I look at the source file for each picture, the sizes (resolution-wise) are the same as the original one (900 pixels wide), but the DPI is reported as 150 for the untouched one (which appears too small on the Kindle) and 92 DPI for the second one (which appears at the right size on the Kindle). The files size for the two source files are the same (both are smaller than the original file size).

When I display the three files (original, untouched source and resized source) on the OS, they all appear at the same (correct) size.

It’s only the untouched one that doesn’t display in the right size on the Kindle.

Both look worse than the original due to the additional and unnecessary compression.

Looks like there is something wrong with the DPI in Scrivener.

Yeah, that’s how I described it would work. :slight_smile: Right above I said the images will not be identical because they must be processed, but that the display settings should be exactly as you left it in the editor. If you resize an image from 150 DPI to 75 DPI then yes, that is how it will compile. If you leave the image alone, yes it will compile as it was dropped in. But it won’t be the same file, that’s impossible. What you are doing by linking is minimising any recompression necessary to maintain an embedded graphic in an RTF file.

Earlier, when you said that Scrivener was shrinking your images, I took that to mean the actual dimensions were changing, maybe you meant the file size was shrinking. I did neglect to mention that JPEG compression is controlled by a slider in the Import/Export preference pane. That’s the answer to your question about the smaller disk size on output, you could probably crank it up so that the output images are in fact larger and barely recompressed at all.

As noted, it is necessary because Scrivener is an RTF editor, not an HTML editor. To get an image into a document it must be embedded into the file, and to get it back out again a file must be created from that embedded image. Linked images are not actually something RTF supports—that’s a Scrivener feature operating on top of the RTF format—and during compile we don’t have the luxury of custom features. The underlying conversion engine on the Mac is not going to take fake RTF codes and do anything with them, naturally.

Wouldn’t the answer then be to use the method that looks best on Kindle? And I mean that not in the sense of changing each image in Scrivener with the slider, but generating a copy of the source images at 75 DPI and using those for production? Then nothing needs to be fiddled with in Scrivener and you get a roughly 1:1 input:output result across the board?

Thanks a lot Amber, all this is very helpful, especially the compression slider in the export settings, that will definitely help to get better results.

I guess my question is how do I get the editor to NOT resize my pictures when I link them. Why does it resize them from 900wide to 442 wide? I’m not ASKING for this. I’m not DROPPING the pictures. I’m LINKING them as you suggested, so I don’t understand why Scrivener makes this executive decision to resize the picture which leads to getting the wrong size and DPI in the output file.

I do understand that Scrivener works with RTF files and has to deal with these limitations, but I don’t understand why it doesn’t keep the pictures at their original size and DPI settings when I link them, forcing me to resize them all manually back to their original size in the editor in order to get them to display at their original size on the Kindle. Surely you will agree that this is not logical, or that Scrivener should have an option to prevent this? If these were huge files, I could understand, but 900 pixels wide at 150DPI fit on my A4 page fine, so there is no reason to resize them.

I have an idea to try to avoid that and also solve my second problem more elegantly, I’ll report here if it works :slight_smile:

Where are you seeing them being cut in half? I mean at what point does this happen—immediately after you link to it, you double-click and it’s not the right size? Or at some other point?

With my test, I link to a 900px @ 150 DPI image, double-click on it, and here are the dimensions as printed (pixel and density info highlighted):

The only number resembling 442 what you see, here, is the dimensions printed in points, not pixels. 900 px @ 150 DPI = 432pts (900 / (150 / 72)), which is 6" (432 / 72) across printed, which is as you say enough to just about span the average text block on a sheet of A4.

So coming back to my earlier question, it sounds as though you’re using an image format that doesn’t display well on the Kindle, and correcting for that problem in Scrivener, then wondering why Scrivener changed the files to the correct scale (I’m sure you don’t mean it that way, I’m just explaining why I’m a bit confused here) when what I’m wondering is if changing the images to X in Scrivener makes it look good in Kindle, and you don’t want to have to change all of the images to X in Scrivener, then why not create a batch of images for Kindle that are already X? Then you don’t have to drag the slider and have Scrivener resize them?

Well, maybe that’s what you’re up to. Let me know how it goes!

You are correct that the size of the picture in pixels doesn’t change, but the size in points is WRONG for ebooks, which leads to minuscule pictures in the ebook.

For some reason - I guess because Scrivener adjusts things for a page or the display - the illustrations are compiled at the wrong size for ebook, even if you simply link to them and don’t even touch them. It adjusts the DPI and uses this new value during compilation.

Anyway, I’ve found a solution that solves my two problems. :slight_smile:

What I do is I use the command <$Img:/full_path/image.jpg;w=450> in the manuscript.

That way, when I compile for Word or PDF, the correct width of 450 is used irrespective of the pixel size of the image (Scrivener calculates the DPI allowing the image to be displayed at the specified size). Any change in the w= parameter produces the same file size based on the JPEG compression setting, it doesn’t change the size of the picture in pixels, it only changes the DPI of the resulting source file.

I then use a replacement for the e-book format compiling options (in the replacement tab) to replace the ;w=450> with ;w=1800> which is the best size for e-books.

If course if I need smaller pictures I’ll use a smaller value than 450, and will adjust the 1800 value for the ebook accordingly, and I’ll add another replacement for these set of pictures.

I can then 1) use any picture and it will be converted to the right size and 2) Scrivener will automatically compile with the correct DPI setting for e-book and for Word/PDF.

This is more elegant that renaming the folders everytime, and allows to try different sizes to see which results are best.

I can also adjust the JPEG compression to adjust the final file size of the picture. I wish it would be possible to specify the JPEG compression in the compiling options, that way it could be saved in the presets (Word or Ebook), but it’s not a big deal to change it before compiling.

I tried 2400 wide, 1800 wide and 900 wide native files and settled for 1800 wide for ebooks and a JPEG compression setting that gives me a good balance between file size and picture quality.

The illustrations are now in the right size and in much better quality than initially (much less compression artifacts), so I’m a happy camper. I can also use the same set of illustrations for all my output options and simply adjust the JPEG compression setting to save space on the ebook final size, while leaving a minimal compression when I output for word or PDF for max quality as I don’t mind about the file size in that case.

The only downside is that I don’t see the illustrations in Scrivener anymore (even in page view), but I’m happy with this compromise if it means the end result is good and compiling is easy.

Thanks again for all your help! :slight_smile: