Why when I insert a photo it is automatically scaled down (by pixel count)?
And when I want to scale it up again to the original size, the max size is set to 1190 px wide?
Could you be more specific about what you are doing, and where any scaling occurs? I can only think of one place where scaling occurs on purpose, and that is when a picture is inserted into the Notes pane. The presumption being, if you’ve got some picture that qualifies as “notes”, it’s actual production quality doesn’t matter and the main thing that matters is that you can see it.
This is not the case. I want to insert a photo into a document in Draft folder by Edit-> Insert-> Image From File…
The photo gets inserted, but very much scaled down. By clicking on the photo I get Scale Image where there are sliders that let me do it until 1190 pixels, no more.
(Mac OS X 10.8.2)
The text editor will attempt to display the image at its natural print dimensions, maybe that is what you are looking at. If you insert an image that is 1,500 pixels wide that is set to print at 5" wide @ 300 DPI, then the text engine will attempt to make it five inches wide on your monitor, even if 1,500 literal pixels is wider than 5".
Whatever the reason - in case of ebooks we see a lot of tablets now having a wider screen than 1190 pixels and more coming. How can I then produce an ebook in Scrivener that has photos that display nicely on new tablets?
My advice is to never mess with that slider if you drop the images in to scale, and in most cases that is what you should do. If you don’t touch the slider then Scrivener will just handle the image as-is without any scale modifications.
It’s also important to note that it doesn’t touch the pixels. This is purely a visual settings, and it will set the visual scale for formats that support it. However many e-book devices will show the image at full width, even if that means stretching or shrinking it. The main reason for handling images that way is the variety of devices used to read books. Some readers will be on an iPhone, many others on Pearl or Paperwhite e-ink displays, so images are treated flexibly.
I have a photo 1190 pixels wide (at 300 dpi), I inserted it into the document, Scrivener scaled it down to 285 pixels wide (according to that slider).
I inserted the same photo again a bit further in the document and scaled it up to allowed max 1190 pixels wide.
I produced a Kindle ebook (compiled to .mobi) and the first photo shows on the Kindle Fire also small, (hard to tell exaclty) the same 285 pixels wide. The other photo shows bigger, (hard to tell exaclty) seems to be some 758 pixels wide.
But .epub version shows both photos the same on iPad 2 (full width of the reading area that is 798 px wide in landscape).
So, it might be that the slider is only a visual tool.
But then there is an issue with conversion to .mobi format? I understand that Kindlegen app that Scrivener uses for conversion compresses images. But something seems strange - my photo is 365k in size and .mobi file that I get that includes only that photo is 516k (the same if the photo is left as inserted (small) or scaled up).
I still need photos to be wider than 1190 pixels also on the Kindle. Actually 2048 px is the screen of the iPad now and the Kindle Fire HD is coming close, so images with high pixel count are becoming mainstream for ebooks now. Do you have any idea what might be going on and how to fix it?
Let me take a look at this further and see what I can come up with. I won’t have a new generation iPad until later this week, so I can’t really do any testing there, and just have an older Fire to test with full colour e-books. However examining the “guts” of an e-book can be very illuminating as to whether what you see in the output is coming from the e-book (and the source graphics) or the software that is displaying them. A useful advanced toggle is in the KindleGen compile option pane, “Save the source files in a folder with the exported Kindle file”. This will create a folder tree that can be used to not only examine the source material Scrivener will feed to KindleGen, but give you a chance to step into the process and make manual alterations to the e-book’s code. So all of the graphics and the HTML used to display them will be available.
You can do a similar thing with ePub files, which are just Zip files in disguise. I find changing the name to “my_ebook.zip” instead of “my_ebook.epub” and double-clicking it in Finder produces variable results. Sometimes you just get a *.cp.gz file instead of a full extraction. If you have StuffIt, or know how to use the command-line to unzip files, that will always work in my experience. Once you’ve extracted the contents of the ePub you’ll have a very similar structure to analyse.
So the Kindle option is easiest, and should be nearly identical to the ePub extraction. I’d take a look at that and see if your graphics look okay there, and if you are conversant in HTML, see if Scrivener is specifying a size other than the image size. If you search for “<img” and scan the line, you should see a width and height setting.
In my test, I created a document with three images, all starting from the same graphic:
- Unedited 1600x1200 @ 180 DPI
- 1600x1200 @ 72 DPI (using Photoshop to adjust the DPI without resampling)
- Third image identical to above.
I then dragged all three into Scrivener, leaving the first two alone, and on the third I used the slider to resize it. The result is that the first image, having a high DPI, appears smaller than the 72 DPI image. I downsized the third image with the slider to 543x339.
Then I compiled to .mobi with the source option turned on. The ‘images’ sub-folder contained all three images, and all three were identical to the ones I had dropped in. No surprises there, as noted Scrivener doesn’t resample graphics.
The HTML has the first image sized to 640x480, which if you do the math off of 180 DPI, is the effective display size of a 1600x1200 image. The second image, which I reset to 72 DPI had its width and height set to the dimensions of the image. This image should show as pure as possible, assuming the display software does not resize it (most will). Finally the third image is set exactly as expected to the slider values I input in Scrivener.
Like I say, I can’t test on Fire HD or high-res iPad, so you might want to replicate this test and see which image gives you the result you desire, and use that as a pattern going forward.
Thanks a lot for a tip on how to dig deeper.
What I see is (in body.xhtml):
Like I say, with my second image test, with the image set to 72 DPI and not touching the slider in Scrivener, I got the native size of the image (larger than 1192 px) for both the graphic and the display size in the HTML. So I think my original point stands, it’s just that if you try to insert a graphic with a higher than 72 DPI, the text engine modifies the display size automatically. Basically it always tries to display the image at its print size and at 72 DPI the print size equals the pixel size, so nothing changes. I would suspect that most readers will follow this convention as well, being based upon the same display calculations that computers make.
So, you basically say that Scrivener is mostly for print and this ebook thing is just a small add-on? A bit strange attitude these days, at least IMHO.
Amazon says already for some time that images in ebooks should be 300dpi (to ensure future-proofness).
I have no idea how you extrapolated that from my clarification on a point that I made in response to your query for more information on how the text engine worked. I’m happy to be of help, but I have no interest in getting into an antagonistic tussle with you over this.
I would say that images in Scrivener are worse for print than e-books if anything, and then add that when used as a publication system it’s image handling leaves a bit to be desired for both workflows for different reasons. It works better when the images are considered low-res placeholders and the final output is not being produced from the compiler, but with some other software working with the product of the compiler, with final quality figures being used at that point. We make no claims about Scrivener being a publishing platform, anywhere. It is rather stressed that it is a first draft platform. That it can, for many people go further than that is fantastic (novelists for instance will most likely have no problem using the software from A to Z), but should not imply it is designed for finishing complex (in a formatting sense) works.
Secondarily to that I would also say we are in an awkward transitional period of time right now in terms of display technology. Computers (and reading hardware based upon computers) still kind of operate on the 72 pixels = 1 inch premise, even though this is becoming very noticeably incorrect. It’s been a problem for about a decade, but only a minor one as display DPI crept up into the low 100’s. Now we suddenly have 200 to 300 DPI displays, but not everything on the software side of that has caught up with this reality. This means we should prepare for the eventuality of high-res everywhere, but we should also prepare for a little clumsiness here and there in our workflows.
Sorry, if you read into my text any antagonism, was not meant this way.
You still did not answer my question: why Scrivener defines image pixel size (actually forces it, also in xhtml) as in the following:
What I see is (in body.xhtml):
Another question: what compiler would you recommend (Mac) to produce ebooks from Scrivener docs?
Then, what I was hinting at, was your business opportunity - why you define yourself as a draft editor platform? Draft editor’s value for customer is there, obviously, but it is not extremely high. If you positioned Scrivener as an ebook publishing platform (after some updates), the value for customer would increase dramatically (sorry if this sounds as a lecture from a guy with 20+ years of media/publishing management/entrepreneurship experience).
Wishing you all the best, Scrivener is, after all, the best I have seen so far 
All right, my apologies for misreading your tone.
It is considered good practice to put the width and height of the graphic into the meta-data for displaying that graphic. The reason for this is that in HTML, layout is a dynamic quality which can collapse down to zero pixels. If the image is not loaded for whatever reason, the page layout would collapse to zero around the image. That might be okay in many cases, but what if the image is being used as a scene separator? You would want it to retain its intended height even if the image were missing. Specifying the image’s dimensions forces the HTML rendering engine to prohibiting collapsing, leaving a space where should be one would the image be displaying.
So to me it seems the best way to approach this is to drop 72 DPI images into the editor so that Scrivener outputs the correction dimensions into the HTML syntax. Then after you have compiled, you can merely copy all of the high resolution graphics into the images folder and sew it all up with KindleGen into a .mobi file. You don’t even have to edit a single line of HTML code.
Sigil is my favourite tool for editing e-books. It’s free (and open-source), does code clean-up, has a WYSIWYG mode for those that do not want to mess with raw HTML code, but a code or split render/code view for those that do. It’s an ePub editor, so the Kindle workflow is to create the ePub from Scrivener, do any post-compilation polishing in Sigil, and then open the ePub using Kindle Previewer, which will automatically convert it into a .mobi file for you. You could also use the KindleGen command-line tool if you prefer the more direct route.
Focus, mainly. Once you start messing with an e-book in Sigil you’ll see that to become a proper publication platform for e-books, Scrivener would have to become something like Sigil, on top of being what it already is. So now it’s a writing program with Dreamweaver light tacked on top, and that’s just e-books right now. What about the rest of the publishing industry? It’s far from dead and likely won’t be in our lifetimes, even if it does become marginal (enthusiasts still purchase vinyl albums, for instance) so should Scrivener also become a desktop publishing system completely with InDesign levels of layout control, or at the very least, Microsoft Word. So now it’s a writing program, a Dreamweaver lite, and Microsoft Word in one massive, bloated singularity of features. And you can’t dismiss the need for full layout control because even though e-books do not need this right now, they will. Any publication software will need to be able to address full layout in digital as well as tradtional publishing.
It just seems to me that considering the complexity of making an e-book properly, considering the complexity of making a print volume properly, and considering the complexity of writing a book these are three distinctly different tasks. Creative writing, visual design, and finally technical wiring.
Scrivener gives you a huge leg up on the technical wiring and design, but some will still need to tweak that after they compile, and an editor that specialises in the technical aspects of the e-book as a piece of technology will be best for that. It’s the old 95% diminishing returns principle. It’s not too difficult to make software that gets you to 95%, but that last 5% is tough, expensive and increases the complexity of the software enormously.
That’s fine, we’re not looking to create an operating system for writers here. Rather, just focussing on the aspects that are not widely addressed by software and making those products the best they can be.
Wonderful. This discussion clarified a lot for me as a newcomer to Scrivener. Thanks for your in depth questions and answers.
Maripat