Best way to manage reference photos?

I’ve been interspersing photos amongst text in my documents (kinda like a web page) but I’m noticing that docs with lots of photos take forever to load. Is there a better way to save photos? Or that’s how it’s going to be with image files, and perhaps I should optimize them first? (which I really don’t want to, it’s not a step I want to take in the creative process).

There are some options you can take to approaching image usage in an efficient manner. Which to take depends on how you work with images, so here are a few approaches:

  • As you note, optimising a graphic for its intended use is always going to be one answer, and probably the best one as well. It’s a step, but there is hardly a case where I don’t do that for any use of an image no matter what, anyway. There may be tools out there that dramatically reduce this workload. I’m a Mac user, so I don’t know of anything to recommend for Windows, but look for tools that can make it possible to automatically compress anything you save into a special folder, for example.
  • Another approach is to take Scrivener’s ethos a bit further, and keep documents with images as small as possible. If a text transitions from one topic to another, split it off into a new entry in the binder. The smaller (more topically cohesive) your items are, the less you have to scroll through long chunks of text, the fewer images there will be to store in each chunk, statistically.
  • File images as separate binder items. Instead of dragging them into the editors, drag them into the binder. For those with a lot of reference images, this can make things easier in the long run because each image can have its own name, metadata (like keywords) and so on, and it can also be nice to load a Corkboard with a bunch of image thumbnails for visual navigation.

But most interesting to this particular task is the Document Notes tab in the inspector. From there you can jot down notes about the image, without having to place it into a text file where you can type around it. If you want to reference that image from your text in a contextual fashion, you can simply create a clickable link to the image in the text—that will make pulling it up simple when you need it.

There will be further options in the public beta, but both of them can be narrowed down to one concept: only display a thumbnail in the editor, but have the image itself stored elsewhere. This can either be as a file somewhere beyond the project, or an internal link. Either way from your side of things the experience is almost identical to fully importing it into the text—but without having to physically store all of those megabytes right there.

With linked images, in effect, you can have the advantages of both methods, since the image can be stored with notes and metadata in the binder, topically organised into folders or what have you—and be printed in the text.

I noticed the ‘Insert image linked to file’ after posting, and did that with a few pictures that I wanted to be in the research docs. But most of them I removed from Scrivener and saved in an images folder (which I can easily batch optimize if needed). So my file size went from 318mb (!!!) to 6mb.

Oh yeah, if you had 300mb of images in the text itself, I can see how that would start slowing things down. The project design itself is built so you can easily store that much information—far more really, gigabytes of research are not out of the question—but the design definitely is tuned more toward that being research, as binder items, rather than embedding files into text files. That’s always going to be less efficient, by nature of how an image essentially has to be converted to letters and numbers internally.

But yes, I forgot that they did manage to get the “Insert Image Linked to File” feature in the stable version at some point, so that’s already a good approach to the problem that is presently available.

A good one from v3 that I forgot to mention is importing shortcuts to stuff, instead of the stuff itself. If your research is mainly just very small shortcut files then you don’t have any project bulk problems, but yet have seamless access to it all, just as if it were imported. That approach also leaves open the option for batch processing and so on, naturally.