Why do small pasted images ballon the file size?

I’m pasting small (200k) jpeg’s into my Document Notes in the inspector.

However when I check the file size (by looking inside the Scrivener project package in the finder) I see that that the file size of that note is around twice the size of the image file! So the 200k jpeg makes a 400k file. Not a big deal for one note, but I’m adding hundreds of images…

Thank you…

JPEG images require recompression given how the storage mechanism works with RTF, so we use minimum compression settings for storage to reduce recompression artefacts. There may also be a little bloat since the image has to be converted to ASCII characters for safe storage inside an RTF file, but that wouldn’t be enough to explain a doubling of the storage size by itself.

What I would recommend using is the Edit/Insert/Image Linked to File… command, which will only add a few bytes to your project size per image (enough info to store the original location of the file). Usage is seamless, it will appear fully embedded while you work in the project. This method is also superior for JPEGs in general since Scrivener is now working from a static external source rather than recompressing the image into the text file being used to store your notes. Drawback of course: it’s not as easy as copy and paste, but I prefer the benefits of this method myself and use it in nearly every project that deals in a lot of images. Binding a keyboard shortcut to the “Image Linked to File…” command can save a lot of time.

Hi Amber,
Thanks for quick reply. I need to be able to share the Scrivener package with my editor. Can I put the linked image folder INSIDE the Scrivener package?

BTW, some note files are TRIPLING in size !!!

Ah, portability is the other drawback to linking, I forgot to mention that. It is possible in theory since the way Scrivener points to a linked image is by using its full path. Thus if two machines have the same path to the file, they will have no problems finding the links. Of course that’s easier said than done for images stored in your user folder, as both the Mac disk and your user folder name are likely to be different from your editor’s (and so it wouldn’t really solve anything even if you could safely put your images folder inside the .scriv package, since the path to the .scriv itself is still different from where they will be opening it).

The most portable approach is to use a DMG for your images. These can work like external drives in the sense that they attach to the computer using a predictable name and will attach in the same place on all Macs. An image link to “/Volumes/My Images/this_picture.jpg” will work from any Mac that has that “My Images” DMG available and mounted to the desktop. You would then provide your editor with the DMG and .scriv together, with instructions to double-click the DMG before opening the project so that the images can be found—or even skip the DMG aspect and use an actual external disk or Flash thumb drive.

That assumes everyone is on a Mac. If your editor is using the PC version of Scrivener, there is no way to reconcile the differences in how Windows and Macs work with file paths. Assuming a PC can even open a DMG, it would end up looking something more like “E:" than ”/Volumes/My Images".

For the future, relative linking is something we’re looking to provide support for, and in that case you could just keep a simple image folder beside your project file, then copy both to another computer and still have those images available. I can’t say for sure if we’ll find a good way of doing that though, so don’t hold us to it. :slight_smile:

P.S. The amount of expansion you see will depend on various factors such as the compression setting of the original JPEG and how complicated the image is. Highly compressed very detailed files will expand more than lightly compressed simple images, for instance. It may well be sometimes more than triple the original to do that.

Wow, that is way too complicated.
I’ll stick with the large package for now.
Hoping that new feature comes soon !