Images DPI

[nontroppo]

This is an interesting and sobering read: http://mademers.com/image-handling-in-e ... f-inanity/ — yikes!

[nontroppo]

I also checked the Amazon guidelines, and it isn't very clearly written but it does not say images should be metadata tagged at 300DPI, just that (as AmberV pointed out) they should be designed with a 300PPI minimum in mind to yield an image dimension that supports that (that is not the same thing): https://kindlegen.s3.amazonaws.com/Amaz ... elines.pdf (and it recommends CSS px for block images and em for inline images)

[lunk]

Excuse me if I am intruding, but I have been trying to follow this discussion from the start to learn about how to handle images when I in my next project will have to include a lot of them in the final ebook.

To understand all details I sat down and read a bit about dpi and ppi and image sizes and when you write...

I take an image that is is 1080x1440 at 300 dpi

... isn't this where everything goes wrong, from the start? The initial digital image you have is 1080x1440 pixels, right? And that's all. It has no dpi because it has no physical size. The info about dpi is information for a printer, if you decide to print it on paper. Or is the 1080x1440 something else?

[Bridey]

Thanks for the detailed replies. Know I didn’t start this thread (apologies to Mick for intruding), but there is a lot here that, however arcane, helps to scrape away some of the fog from the mud.

Now that we are all hopefully on the same page, the main problem we are facing when thinking about making this more intuitive or flexible, and what we’ve been discussing above, is that the ideal units of measurement are unreliable or difficult to extract from any form of WYSIWYG mechanism rooted in a print-based context, and particularly so in a program like Scrivener, where layout is something done to source material, rather than being an inherent property of that material (like in Word).

I have never thought of Scrivener as being rooted in a print-based context. For me, it has been an agnostic writing studio that has handed over granular print/layout work to post-compile WYSIWYG tools: of its twenty compile formats, only print and PDF are end-point compiles. Need to reset my brain.

And having read nontroppo’s link above (viewtopic.php?p=256852#p256852), I can see how difficult this whole issue is for tech savants, let alone end users, especially creative writers whose focus is on words, not recherché pixel-ology. We put (what we think is) a paperback-size cover with (what we think is) a good-quality DPI setting into a project and expect it to come out looking the same. Why it doesn’t, even if for the very best tech reasons of which we are stubbornly ignorant (that refers to me, not the OP), is white noise. We don’t really want to know how or why; we just want it to work – I have seen this frustration with writers/users I know online and offline. Anything that makes the process more intuitive or flexible would be very welcome.

As far as I understand things (and trying to create a simple rule of thumb that I can use going forward), if a user is outputting to an ebook format, it is best to prepare images at 72 DPI, although I don’t really get how that squares with Amazon’s 300 DPI requirement: if I tweak an image in Preview, it asks for a resolution, so doesn’t that figure need to be 300 DPI for Amazon? The dumbness of that question will undoubtably seem immense to those of you who are lucky enough to see both the wood and the trees.

And, to me, it still seems as though the image placeholder tag is the simplest way forward, because (1) it allows users to switch different images/resolutions in and out of final compiles, and (2) it allows users to use the ebook=xx% setting (which isn’t possible with an image imported into Scrivener?).

God, I love the smell of DPI in the morning.

[lunk]

As far as I understand things (and trying to create a simple rule of thumb that I can use going forward), if a user is outputting to an ebook format, it is best to prepare images at 72 DPI, although I don’t really get how that squares with Amazon’s 300 DPI requirement

As far as I understand it, the digital image has a pixel size, but no resolution whatsoever until the moment you print it on paper so you know what size those pixels are spread on.

The inch in DPI doesn't exist until you present the image in a given physical size. Your computer screen has a size and a number of pixels and thus a resolution, but images that you display on a screen only have pixels and, therefore, their size will vary with the screen resolution.

Edit, addendum: And when you change the displayed image size in the editor, using the slider, the no. of pixels is constant but the dpi changes because you are actually giving it a physical size.

[AmberV]

It’s a good point of interlude to briefly once again confirm that yes, 72 DPI sRGB graphics are what one should be using in digital publication for the screen (excluding PDF, which is a weird case of being a format built all around print fundamental but primarily used for digital distribution).

All of the above is therefore rumination on whether Scrivener should mitigate the use of incorrectly formatted graphics using a different system of measurement or algorithm for approximating what is ultimately a confusing request made of it, than it currently does.

So for someone looking for the best way to approach digital publishing and images, my advice from what I have observed and tested is:

• Use the above specifications as a starting point.
• Be prepared for the reality that you may need different images or different ways of expressing the sizes of those images for each vendor you target. Nontroppo posted a link to an article about the woes of that, and I can definitely corroborate, having worked with countless people over the years to get consistent looking results in Kobo, Apple, Kindle and Nook. There is no magic bullet. No single image that works everywhere perfectly. No method that solves everything. This is especially true with screen-width/height graphics, that’s where it gets really messy.

Fortunately, Scrivener makes that relatively simple. Image placeholders being text-based tokens can be modified by Replacements on the fly to target different graphics, adjust sizes, add ebook percentage-based instructions, etc. One can also use linked images and swap folders around on the disk if they prefer thumbnails in the editor to text tags. There are a lot options.

So here is how Scrivener works when using proper 72 DPI graphics (whether they be that way from the start of by using Scrivener’s tools to bring the size of the image down to that point):

• If the image exceeds 800x600 in either direction, then it assumes the best mode for displaying this image will be relatively. All size information will be replaced with “width:100%” as an inline CSS style.
• If neither edge of the image exceeds those limits, then Scrivener will not insert any size information with the image, allowing it to be displayed naturally and in accordance with the device’s preference, governing stylesheets, or to allow the user to target the image themselves in their own custom CSS.

So, if you go back to what the OP was reporting: we already support two of the methods they tested that work well. They also suggest substituting pixels for points, but I think we’ve provided adequate documentation to the fact that this would be a step backward, and no more reliable than using inches or picas.

I have never thought of Scrivener as being rooted in a print-based context. For me, it has been an agnostic writing studio that has handed over granular print/layout work to post-compile WYSIWYG tools: of its twenty compile formats, only print and PDF are end-point compiles. Need to reset my brain.

Welllll, take it with a grain of salt. When I say it is rooted in print mechanics, I’m referring to how the internal mechanisms record lengths, how sizes are stipulated, etc. RTF is a format designed to describe printed material. Scrivener uses RTF to store its material, so by nature it refers to images as having fixed point widths, and it refers to fonts as having very precise physical sizes (as opposed to the more HTML-ish relative scaling), and so on. It means that, when it comes to expressing formats that are flexible or dynamic like ePub, a little interpretation is required, and we cannot always extract the most optimum information from the storage format (RTF).

This is all perhaps abstract in the sense that Scrivener isn’t a page layout or desktop publishing program. You aren’t typing on virtual sheets of paper into text boxes and so forth like you would be in InDesign. Saying it uses print mechanics to store data doesn’t mean much, until we get into very technical discussions over why an image uses points for its measurements.

But yeah this whole topic of image resolution baffles even professionals. Just do some searching for digital photography articles on DPI to see that even people that make a career out of handling graphics struggle with these principles. When I took design many years ago, we spent several days going over this topic and I don’t think everyone in the class ever fully understood dots per inch vs lines per inch versus dot pitch versus pixels per inch.

It’s a lot for a writer to take in—but if one is going to be self-publishing I’d say it’s just as valuable to learn the basics as HTML and CSS will be. One doesn’t need to become a guru, but knowing some bases like how 72 DPI is what browsers and ePub readers measure by is going to save one a lot of grief.

I don’t really get how that squares with Amazon’s 300 DPI requirement: if I tweak an image in Preview, it asks for a resolution, so doesn’t that figure need to be 300 DPI for Amazon? The dumbness of that question will undoubtably seem immense to those of you who are lucky enough to see both the wood and the trees.

Yeah that’s confusing. As Nontroppo posted above however, Amazon doesn’t seem to specifically say they want graphics set to 300 DPI in their metadata. They are saying they want images with enough pixels for there to be 300 of them per inch when the image is displayed on a Kindle.

The distinction being: the image should have enough pixels that it could be 300 DPI at a defined width, but the actual metadata setting on the image should be 72 DPI. That setting is for print use only. The pixels are another matter entirely. So feel free to use the DPI settings in Photoshop to figure out the math of how many pixels you need, but when it comes to saving the image leave it set to 72.

And, to me, it still seems as though the image placeholder tag is the simplest way forward, (1) because it allows users to switch different images/resolutions in and out of final compiles, and (2) it allows users to use the ebook=xx% setting (which isn’t possible with an image imported into Scrivener?).

As to that, see above. Scrivener has rules for how graphics are treated at 72 DPI and those rules tend to handle how people need images treated in eBooks for most cases. For other cases you can force the issue with CSS, or by using placeholder tags to stipulate a precise measurement or relative screen usage.

There is fundamentally no difference between image placeholders, linked images and embedded images once we get down to compile. By the time the engine is converting graphics to HTML—everything is technically embedded. All linked graphics will be fully imported into the working data at the sizes we stipulate. So don’t worry so much about that aspect of it.

What these different tools provide are benefits to our flexibility as users. Embedded are the least flexible but require less management. Linked to the binder are also low management but allow a little more flexibility. Linked to the file system requires care in managing ones resources around the project, but a lot of flexibility. Placeholders and Markdown usage not only provide that flexibility, but also allow compile settings to manipulate image presentation and selections on the fly, and Markdown users also get a wide latitude of presentation control.

The decision is entirely down to what you want and what you need as part of your workflow. Don’t make the decision or force yourself down a path strictly to appease the compiler. It doesn’t care which type of image you use—and so long as its optimised for the type of document you are compiling, the result should be fairly intuitive.

[nontroppo]

AmberV: I think a yellow highlight box with a distillation of this discussion would be a welcome addition to §15.6 of the user manual

[Bridey]

Thank you, Lunk and Ioa, for your detailed replies. I have read them both at least a dozen times.

All of the above is therefore rumination on whether Scrivener should mitigate the use of incorrectly formatted graphics using a different system of measurement or algorithm for approximating what is ultimately a confusing request made of it, than it currently does.

...

If the image exceeds 800x600 in either direction, then it assumes the best mode for displaying this image will be relatively. All size information will be replaced with “width:100%” as an inline CSS style.

For me, that's the the crux of the issue: incorrectly formatted graphics. Most users I know don't know what a correctly formatted graphic should be (in Scrivener or anywhere else) [1]. We plough ahead, usually with the assumption that the bigger the numbers (especially the DPI) the better. We should get to grips with the underlying concepts, but most people I know just want a few simple A-into-slot-B examples that they can copy or adapt.

Also, if someone out there in the wider world came up with a simple single measurement, life would be a lot easier.

Why, out of curiosity, 800x600 in particular?

Thanks again to all.

Bridey

[1] A lot of writers (or other people using Scrivener) even struggle with things like indents and tabs and line height and paragraph spacing and ... and ... and... so the wonderful world of images is a hurdle from another discipline and of another magnitude for them. In a perfect world, we'd all employ specialists to handle typography, image processing, editing, and publishing for us.

[AmberV]

AmberV: I think a yellow highlight box with a distillation of this discussion would be a welcome addition to §15.6 of the user manual

A capital plan!

AmberV: what about vh and vw units — these are relative to viewport width and height, easier to conceptualise than width+height (which is relative to the containing block)? What I don’t know is which, if any, ereaders support vh and vx?

Yeah, I’d have to research the compatibility of those units, but if it is commonly used then that could be more intuitive and less easy to confuse with other functions than percentages.

Oh, and I meant to address this and forgot to:

If I perform the exact same test of any other ePUB creating program I can find, this problem does not exist.

It is very likely that whatever you are referring to (Sigil, etc.) are not treating images for the print metadata in the least. They are discarding that information, so all they see is your 1080x image and they treat it as Scrivener would if you used 72 DPI with it. It’s apples and oranges really, for so many reasons.

Why, out of curiosity, 800x600 in particular?

That was the recommended size for full screen and cover image graphics for many years, as that is how big the most common eInk screens were until the resolution explosion took off. So it is safe to assume that any image larger than that is meant to be at least full width, or at least wouldn’t be harmed in presenting it that way. It could be at some point that is no longer a safe assumption, if resolution goes higher—but I wouldn’t be surprised if we’ve plateaued. eInk already has the resolution of a high quality laser print, and arguably nobody would benefit from it being much higher than it is.

[Bridey]

Grateful to you, Ioa.

[lunk]

If I perform the exact same test of any other ePUB creating program I can find, this problem does not exist.

It is very likely that whatever you are referring to (Sigil, etc.) are not treating images for the print metadata in the least. They are discarding that information, so all they see is your 1080x image and they treat it as Scrivener would if you used 72 DPI with it.

Can't Scrivener do the same? Discard the print metadata or assume 72 DPI instead of the image's existing DPI? Wouldn't that solve the problem?

[AmberV]

Can’t Scrivener do the same? Discard the print metadata or assume 72 DPI instead of the image’s existing DPI? Wouldn’t that solve the problem?

Absolutely, we could do that, but then we’d have people wondering why when they resized an image in the editor the compiled book outright ignores the size they selected and no matter what always uses the native size of the image—or why the image that looks okay in the editor balloons out to full screen when they compile.

[lunk]

I guess I was unclear.
... discard the metadata when one compiles to Epub format, like other softwares do.

[AmberV]

That’s how I understood you, so it must be me that isn’t explaining this right. If the size of the image is discarded when you compile to ePub, then all there is to determine the size of an image is its raw pixels, which means an image will always be the same size coming out of Scrivener to these formats.

And to be clear, when I say an ePub creation program might be discarding the info, I mean it never reads it in the first place, only ever treats the image as pixels, and if it allows any kind of visual resizing at all, is going to be doing so with a simple floating point calculation on pixel dimensions directly. It is using the same technology that the reader or browser will be using, and so none of these complexities that Scrivener faces are relevant—hence apples and oranges.

[lunk]

And Scrivener can’t do the same, for some reason? Skip the oranges and go for apples like the others?