When I put multiple images in texts things come to a crawl, constantly beachballing. JPG’s are 100Kb or so…
Is this normal behavior?
The same project on my iPad is not usable anymore…
I’m a screenwriter for film/docu and I need to put lots of images.
Was hoping scrivener was the right tool for the job…
Thanks,
Karel.
I’d say in most cases it is the right toolchest for the job, but mainly if you’re using the right tools within it. Embedded graphics are better employed as a stop-gap to more fleshed out workflows later on, or for their convenience when they are very small and limited in use. The Insert ▸ Image Linked to File|Document… command set is what you want for larger scale uses. Linking to images is how you will find most professional tools handle this basic problem of mixing high-impact files with low-impact container material like text.
This can be made fairly low impact with the following adjustment to how you work:
It’s only one extra step, and it means keeping your heavy weight material separate from your rapidly evolving text content. Everything in Scrivener should speed up and stop using as much space, from typing speed to stored snapshots.
Some like to use the image placeholders metho instead. It’s a better option for those that prefer to not have the images in the writing environment at all, though.
Image handling is a bit tricky cross-platform, and in fact you’ll get best results by not having iOS touch embedded images at all, in most cases (I’d honestly say the same goes for all text editors, the less contact a text editor has with graphics the better, that’s one big reason for why we use links in pro tools). Using linked images is a way of avoiding that problem. Of course the image won’t exist on the iPhone anyway, so you’ll see a “missing image” thumbnail instead.
Like the OP I created a document with embedded images and soon found it slowing to the point of being unusable. In several sessions I deleted images and put in a link for each instead. That helped a lot but it’s still a bit slow.
I may have missed replacing some of the embedded images. How can I find out which ones are still embedded, if any?
There is unfortunately no way to sort by or examine the actual disk size of binder items, in Scrivener, so you’ll need to use Finder. The good news is that it’s not too hard to do so:
File/Back Up/Back To To... menu command, to set aside a named backup copy of the project. While you wouldn’t be editing anything, you will be poking around in its internal folders.File/Show Project in Finder menu command.⌘F to load the Spotlight search toolbar.⌘J to load the display settings for the search, and change the Sort by and/or Group by settings to “Size”.At this point you’ll have a sorted list of the files used to store text in your project. The ones with images will in most cases be at the top. You can use Quick Look here (Spacebar) to read a bit of the text so you know where to look for it in the project itself. Note that Finder’s Quick Look tool is pretty simplistic—you won’t actually see any images.
Once you’re looking at it in Scrivener you’ll see the images, and you can double-click on each one to check its settings. Linked images will have buttons to reveal the original file, embedded images will only have buttons for changing the display size.
Thank you AmberV. However, that’s way too involved to be worth taking the time to do it – or risk causing a problem. I was hoping that there might be something on a pull-down menu that would highlight linked items in a document. I’ll just leave things as they are.
Sure, it’s one of those things where if one is struggling with a slow project, taking ten minutes to find the culprit file or two is going to be worth it in the long run. Otherwise, maybe not.
Hi,
I really appreciate the generous trial period for Scrivener - which I’m loving and would definitely purchase except that I could really use a bit of help on finding a workflow for bringing images into a document without creating slow downs? I’ve got a powerful desktop PC yet I’m getting Scrivener pausing up to 5 seconds between keypresses, and I’ve only got about 8 images in a 10 page document so far. What am I doing wrong?
My current workflow is simply to paste images from the clipboard using Cut and Paste directly into a document I’m writing in. Maybe, should I be using one of those Insert…Image menu options instead? Is there a way to have Scrivener not slow down at all with images if I follow an intended workflow?
much appreciated, Dom
I am writing a long form project that includes multiple JPEG impages on MACOS. I am spending a lot of time watching the rainbow wheel spin. I am able to type about four characters and then I have to wait 5 seconds while the wheel spins for Scrivener to catch up. I moved to Scrivener for the purpose of having a tool that could handle images. I am tech literate so please trust I have already ensured all my software is up to date, I have logged in and out, shut down, etc. I cannot write when the spinning wheel is in blocking my way. Help?
Windows user here, but can Import images as Research File Shortcuts in the Research area. The file will look normal and you will see the image without adding the bulk of JPEG images to Scrivener. If you can using png versions of the files will leave a smaller footprint as well. To make it easier with this method, I store all images for a project in one folder.
I’ve merged your query into a very similar one, wherein workflow advice was provide for reducing image impact in the text.
I’d also review §15.6.4, Linked Images, in the user manual PDF, which will cover all of the various things you might need to do with them, in the course of editing.
@GoalieDad : Windows user here, but can Import images as Research File Shortcuts in the Research area.
Storing images, as images in the binder (not in text files), shouldn’t negatively impact performance outside of some narrow cases (like having thousands of image thumbnails on the Corkboard at once, which alias/shortcuts won’t solve since that still involves rendering thousands of thumbnails on the fly). I wouldn’t worry about that necessarily. You could have gigabytes of images in the binder without slowing down typing.
That said I almost always keep images outside of the project (you can link to a binder image in the editor, and the binder image can be linked to the disk, which is an extremely low-impact way of doing everything you can do with images otherwise). But my main reason for doing so has little do with performance and more to do with integration with graphics editing tools (batch and individual).
I occasionally have Scrivener go slow in Windows. I find that sometimes the File > Save and Rebuild Search Indices can help with that problem. Not sure about a mac, but simple to try.
I’d say that’s probably a very specific Windows quirk, maybe in some odd cases if you have a lot of files open in RAM because you were using a large Scrivenings session, rebuilding the index—which must load and close every single text file in the project—would as a byproduct of doing so, flush a bunch of files from memory you no longer need open.
But for this, of having large images in the text editor and that causing text lag, I can think of no reason why that would change anything. It’s not a RAM issue that makes it slow. It’s the fact that you’re auto-saving and modifying a very large file over and over at a rapid pace, in a system designed for largely pure text in relatively small quantities. And there is really no way around that, other than us spending years on a sophisticated word processing grade text engine (in a program not meant to be one).
I read somewhere that jpg images are more of a size issue due to their format over png files. Is that true for how Scrivener handles image formats?
When it comes to image compression algorithms, there isn’t one simple way of saying that one format is definitely bigger than another. To speak in generalisations though, I would say that what you heard is the other way around: by and large JPG tends to be smaller than PNG.
But, that’s a pretty vague statement, and mainly only true when we’re talking low to mid-high compression settings in the JPG. An “archival” JPG with minimal compression can sometimes be larger than a PNG of the same image. PNG-24bit files can include a fourth channel, one that is a greyscale alpha mask, which increase the base uncompressed size over the JPG’s maximum of three channels (basically a 3-channel image has three images in it, one for red, green and blue). The amount of detail in the image itself can impact compression efficiency, such as a photograph of a forest being far more difficult to compress than a graphic novel panel comprised of large flat regions of colour. And then you’ve got PNG-8bit, which is much more like GIF in that it has a colour index of anywhere from two to 256 colours, and those colours are allocated in vector fields to redraw the image. For the aforementioned graphic novel, PNG-8bit would be very efficient and result in images far smaller than either JPG (which would have to use relatively low compression settings to avoid visual grunge around hard lines) or PNG-24. PNG-8 is also great for screenshots for similar reasons: large fields of flat colour, with a little anti-aliasing for the text, which can in monochrome be fully expressed with 16 shades of grey, but not if the screenshot has some form of sub-pixel rendering baked into it, which then uses a variety of colours to trick the physical display into using fractions of a pixel to draw letter angles, and is thus more expensive to compress than 16-grey aliasing. Almost all of the screenshots I upload to the forum are PNG-8bit, because I can say with 5kb what other people are saying with ten or even twenty times that in JPG/PNG-24. On the other hand, PNG-8 is horrible for complex images that lack large flat fields, like a photograph of a forest, and will probably be larger than either PNG-24 or JPG-archival, and look way worse to boot. Now as for PNG-24, the reason why it tends to be larger than JPG is because its compression algorithm is reactive only to the same kinds of repetitions in content that ZIP compression can exploit, and it is similarly lossless (which is very important!). You can save the same PNG file over and over and it will never degrade, while JPG will very quickly turn to useless mush—look at your average “meme” for evidence of that. PNG isn’t so much “looking” at the picture and deleting detail out that the human eye won’t see, like JPG does. There are even some general-purpose compression algorithms out there, like 7zip, that are better at compressing images than PNG is (though your browser won’t show them as images, so there is that).
And then on top of all of that you’ve got metadata, which can bloat file size quite a lot! Using tools that save clean “pixel only” images (or “web ready” as it is often called) can, over a large quantity of images, save you megabytes. Maybe not big deal in Scrivener usage terms, but that can mean the difference between one compensation tier or another in an ebook.
So yes… more complicated than A is better than B! 
A lot of the times it will depend more on what the image is for, than how much space it takes. The losslessness of PNG can be critically important to some workflows, or even phases of the workflow. I use PNG-24 for all original screenshots in the user manual (where I am not using XCF for layered composites that get exported to PNG). Before creating the PDF however, I batch convert them all, stepping down on them rather hard to about 65-compression JPG, because if I didn’t do that the user manual PDF would almost be larger than Scrivener itself! I use PNG on the production side because I never lose a pixel from one edit to the next, but I use JPG for the PDF treatment to keep the installer size reasonable. If I really had the time to dedicate to it, I’d probably go through an hand optimise each screenshot in the manual to PNG-8, which would make the PDF a small fraction of its current size. But alas, I don’t have that time.
WOW. What a professional explanation. I love when in these forums the arts and sciences are combined as in the time of the Renaissance.
I’m guessing this option is not available for windows not there in the options pane.
The option to turn binder linked images off on drag & drop is not present in the Windows version. Instead it is always on, so that is how all images work when you drag them from the binder into a text editor. All in all that’s probably not a bad thing to have missing, as this probably keeps performance higher for many who do not know what is going on under the hood.