How to find large files in project? (Reduce image sizes)

I second the advice to make sure your graphics are of an appropriate size in an image editor. As you noted, Scrivener only changes the display size, and it does so by adjusting the print dimensions in the image metadata itself, or what we could think of as the DPI setting. For most things you will never need more than 300 DPI, and that is considered a “more than enough” maximum, in that you’d generally only see images actually using all of that in a high quality coffee table book. From your second screenshot, where the image is scaled to display at a point that would fit on an average page, you’ve got almost 700 DPI, well more than twice of anything you’d ever need. And that means wasted pixels, which translates directly to an image being way larger (in terms of disk space) than it needs to be.

By all means keep the high resolution stuff available, because once you downsize an image you never want to make it larger again, but for what goes into a document, or Scrivener in this case, you want something that fits the output.

This thread may also be helpful: 477 page document is 52MB, can I get this size down?. In this post I describe how one can go about fixing their images, and by doing so, convert to a more flexible and easy to maintain workflow.

In short I can’t offer any advice to make what you have currently any easier to manage, than that. It sounds like you’ve already figured out what it takes to do this when you’re working with embedded images. It’s a pain, and Scrivener offers no tools to make it any less painless. You do have to use the file system and third-party tools, and that does mean a lot of awkward back-referencing and differentiating between RTF files with lots of small images vs RTF files with one or two massive ones.

So more in the interest of going forward: there are mainly four different ways to include images in compiled output, each with their own particulars:

  1. Embedded: it’s simple, you just drag stuff into the editor and it is there. It has significant downsides though, many of which you’ve encountered:
    • You are trusting the “host” to manage your graphics correctly from input to output, and you shouldn’t. Graphics formats may change, compression may happen, resampling might happen, colour profiles may get damaged or lost, etc. Need CMYK? Forget about it. You are limited by what the host supports, which often means no SVG, no EPS, maybe no TIFF and other standard design formats.
    • Editing the image is a bother. You have to right-click and save it to the disk somewhere, edit it, delete the copy in the editor and then insert the update in its place.
    • Large scale changes of necessity (say your designer gets back with you and asks for all of the images 300 DPI) compound the above problem multiplied by however many images you have.
    • Storing graphics in a text file is inherently inefficient because the “code” of the image must be converted to text (Base64). Everything being larger than it needs to be means you run into efficiency caps earlier.
    • Tangentially, massive RTF files are slower to work with, and image corruption can mean troublesome recovery diagnostics.
  2. Linked to the disk: using the Insert ▸ Image Linked to File... menu command, the result is a simple and short directive in the text file that points to that location. While you see the image represented as a graphic, none of its bulk is actually in the file, keeping it swift and easy to back up.
    • If the image on the disk moves or has its file name changed, the link breaks and you have to restore it, or fix the file system.
    • On the plus side, having all of your core graphics available on the disk directly means being able to solve problems just like this one, so much easier. You sort your image folder by size, and you’re done. You know which images are bloated and can fix them right then and there with an image editor.
    • Linked images are also advantageous if you need multiple versions of each image depending upon the output. You might need black and white for print, or colour and slightly lower res for ePub.
    • Since images are all kept outside of the project, it keeps your total project size down, way down, meaning frequent backups of only your text is more feasible. More backups is always a big plus!
  3. Linked to the binder: fundamentally this is very similar to the previous method, only instead of locating a file on the disk, you drop the image into the binder somewhere, and use Insert ▸ Image Linked to Document, or even just drag the image from the binder into the editor, to create a link to it.
    • With Scrivener managing the content, this negates the one big negative of linking in general. Renaming the image in the binder or moving it into another area will not break the link.
    • With images on the disk you can readily edit them with a graphics editor, or even run batch operations to clean them up and get them sized in an optimal fashion. With binder linked images you can only open them one by one, and they’ll all have a generic “content.jpg” name.
    • But that said, it’s still a whole lot easier to hit the shortcut to open an image in an external editor and be done with it, over the whole export-edit-delete-insert routine with embedded images.
    • Of course with the image actually still stored in the project, it also negates the frequent backup bit, but if your total image payload isn’t massive that can be okay.
      • There is an interesting combination of features that can combat that however. If the image is imported as a shortcut or alias, then it isn’t actually stored in the project, but is referred to in a way that is more resiliant to file system changes than a text path. You’re linking to a link to a file.
  4. Image placeholders: these can work like either linked to disk or link to binder images. The placeholder syntax allows you to either point to the images path on your drive, or to a binder name. They uniquely also allow you to provide a separate size directive to ebook output from print.
    • You don’t get a thumbnail, which for some can be a big downside. I’d count myself among them, I really like having a figure to write around, it helps me compose better than just staring at a code. Yeah I can open the image in another split or Quick Ref, or another program entirely, but that’s more juggling than just staring at it in the context it is meant to be within.
    • On the other hand, placeholders are text, which means they can be manipulated by things that manipulate text, unlike all other image tools. Recall the example of the folder name changing and breaking your image links? Not a problem if you can run a global search and replace to fix all of the old paths to the new path.
    • By extension, text can be manipulate by Replacements when you compile. Shorthand can be used to refer to full paths, reducing the need for particular management of them in the placeholder, and keeping them more readable. You can also more easily swap out images for purposes, if “image_name.jpg” can turn into “image_name-pdf.jpg” or “image_name-epub.jpg” depending on your compile format.
    • For some, typing is easier than messing with menus and commands. Those that like Markdown-type writing styles may find working with image placeholders to be equally convenient and preferable. (And of course, those actually writing using Markdown can and should use its native syntax for image referencing, though Scrivener’s Markdown integration includes compatibility with all of the above techniques.)