Hi, when I use File/Insert Image from file and add an image that is 1080 x 1430 (JPEG) at 300dpi. Then double click own the image to slide the size back to 1080 x 1430 Scrivener reports the dpi has been reduced to 72. I don’t want that to happen. In preferences the import JPEG compression is set at the lowest (I have already optimized in photoshop to level 8 and removed color profiles and metadata, I have chosen 1080 x 1430 at 300 dpi to match the Kindle White. How do I stop Scrivener changing the dpi from 300 to 72 ?
Quite right, my error, but that was background info. I am talking about the image being converted from 300 dpi to 72 dpi or am I missing the meaning of what you are saying? Thank you for your response, I truly appreciate the attention.
Actually DPI is not a physical “thing”, it is just metadata on how to go from pixels to an preferred “real-world” size. An 800x600px image is identical whether it is at 300DPI or 72DPI, it is not changed by changing DPI. Only when it is time to estimate its size for printing is when this matters.
But Scrivener is respecting the DPI metadata, here I dragged an image I just created in Pixelmator at 300DPI into Scrivener and Scrivener has correctly picked up its DPI metadata:
Another way of looking at it is that an image that is 1080 points tall with a 1080 pixel tall raster will be 72 DPI on a Mac because that is the basis for the measurement of a point on a Mac (1 point = 1/72nd of an inch). That is all Scrivener is telling you, that (a) the image will be 15" tall (1080pt / 72) and to get it that tall with 1080 pixels, each pixel will need to be precisely one point tall, and since there are 72 points in an inch that means each pixel is 1/72nd of an inch tall and thus 72 DPI.
To change the print size of the image without changing the DPI requires subtracting or adding literal pixels from the raster—which requires interpolation (damage) to the original image. I.e. to increase the height of the image to 1080 points while retaining a 300 DPI setting on an image starting with 1080 vertical pixels, you will need to increase the amount of pixels to 3,399. For a job like that, you need to use a pixel editing program, not something that just adjusts the display of those pixels.
Here is how it would matter: If you have a 1080 x 1430 pixels image and drag the slider to 1080 x 1430, you are asking Scriv to scale the image to 1080 x 1430 points. If one point size equals multiple pixels, you are effectively asking to blow up the image – which means that your image would have to be “printed” at a lower dpi, since DPI is determined by the resolution of your image (pixel dimensions) together with the scaling (target real-world size).
You notice that the pixel dimensions of the image never change. Scriv is not downsampling your image.
OK I understand now. But here is the thing. When I drag a image that is 1080x1440 at 300 dpi into my project, I now understand that when I look at the slider it says 259x345 POINTS which since a Kindle PaperWhite is 4.16666 pixels per point calculates correctly at 4.8 inches x 3.6 inches which is spot-on. Thanks to your explanation, I get that now. So I don’t touch the slider, compile for epub3 and open the ebook using the built-in ebook reader on my iMac. At the default window size the picture looks tiny, It fills about 1/4 of the book page.
However, if I open a downloaded EPub from anywhere (example Gutenburg Project) and open that using the same app and the same window size their pictures look the correct size. If I break open the EPub and examine the JPG inside using preview or Photoshop the pictures are SMALLER e.g. the in Les Miserables there is a file called @public@vhost@g@gutenberg@html@files@135@135-h@images@1frontispieceTH.jpg
It is 373x589 pixels (200 pixels per inch) and it looks fine.
It is as though there is something in the Scrivener created EPUB that is causing the app to scale-down when opened. Is it something in the CSS?
Also… If I break open a downloaded EPUB which opens and looks fine. The the JPEG out of it and re-compile using Scrivener then open that EPUB, the picture looks tiny
If I create the EPub on Scrivener, break it open I see this line in the xhtml code:
This is a 1080x 1440 jpeg, why does the code say “height:346px;width:259px;” ??? surely this should use ‘pt’ not ‘px’ or just use “height:1440px;width:1080px;” />
Hi Mick can you make a minimal test project zipped up and shared so we can have a look? It sounds as if you may be onto something. Did you check that photoshop is correctly tagging the DPI of the images you are testing with?
I am curious what happens if you do pull up the slider like you were and then generate the epub. Does it come out correct in that case-- that is, properly sized and not unduly pixellated? (Something would still seem amiss in Scriv, but it would be informative to know and you would also know that you could work around the bug in the meantime.)
-gr
P.s. Since the epub format is driven by css, it seems to me that any internal dpi marker there might be in the image file would be irrelevant.
I will make a minimal project and send. In answer to your last question, yes and that is at the heart of it. You all had to educate me before I finally presented my final suggestion of a bug. If I slide the slider so that the points = pixels (because I was too stupid to realize that it said points) then the issue is fixed in the sense that Scrivener incorrectly codes the points to pixels and those numbers are correct. In a sense the bug took it one way and my stupidity took it back the other way. This also explains the the amazing (not) coincidence that me misreading the word ‘points’ for ‘pixels’ just happened to make the image the intended size. I agree with your last point on CSS except I can prove that not to be the case. If I break open the Scrivener produced ePUB, edit the code with a tool like Sygil (or even just a text editor) by simply changing the XHTML then the images are correct. I achieve that by not touching any CSS. What is not clear to me is whether the image looses quality if I use the slider to pretend points=pixels. My illustrations are like pencil sketches, so they may not have enough texture to tell. I’ll make a project and send within the next few hours.
In my zip you will find an image ColorBurst.jpg. Photoshop and Preview both agree this is 1080x1440 and 300 DPI. Used Photoshop to create this from the MacBook Pro wall paper. You will also find my minimal project and the resultant ePUB that Scrivener made.
Here is how I made it.
New Project from “Novel with Parts”
Added the graphic to the Front Matter as a cover
I also added the graphics to the second scene of part 1, chapter 1. I centered it and reduced the left indent so that the image is truly centered.
I did not touch the slider and it correctly reports 1080x1440 pixels at 300 dpi. It also correctly reports 259 x 345 points. This is expected since multiplying those numbers by 1/72 inches gives a size of 3.6 inches by 4.8 inches which is the size of a Kindle PaperWhite which is what I want and why I start with 1080x1440 at 300 DPI.
Compile to ePUB3
However, the ePUB contains the file ‘body2.xhtml’ which contains the following incorrect line:
I must be doing something wrong, when I compile this is makes a folder with an ePUB inside but the file only shows the image from my original example but no second rendering of the image from your tag.
I’ll take a more thorough and proper look at this when I’m off break, but in general I do agree that using percentages is better for eBook publishing. If the image is meant to fill the screen, then 100% is the way to go. We do have a way of specifying width by percentages:
<$img:/path/to/image.jpg;w=259;ebook=100%>
I was going to point you to the user manual, but regrettably it looks like 3.0.1 was released without the 3.0.1 manual, so this capability is for the moment undocumented.
As to the default behaviour—I’m pretty sure the Mac works this way because when the RTF to HTML converter was implemented, nobody would have ever dreamed of putting a 300 DPI image into a Web page (and that would have been true even only a few years ago for eBooks as well), and at 72 DPI the output is correct. It only becomes incorrect when points cease to equal pixels.
At any rate, for screen display, em and % are better units of measurement than pixels or points. All of this is perhaps a good demonstration as to why. Generally we have an idea of how big the image should appear relative to the size of the display, so saying 45% or 100% is a fine way of doing so, so long as we have the pixels to back it up—and if an image is a decorative element meant to embellish or work with text as part of its design, then the em unit that scales with the reader’s font settings is preferable.
I realize I started all of this by going on about DPI (the title of this thread) but wasn’t I wrong about that? My current understanding is that this has nothing to do with DPI. It is down to Scrivener reading X points on the slider and coding X pixels in the code.
