Images DPI

User avatar
nontroppo
Posts: 874
Joined: Mon Mar 05, 2007 5:22 pm
Platform: Mac
Location: Airstrip One

Wed Jan 03, 2018 7:58 am Post

The mapping between points and pixels (and physical pixels and CSS px units) is not straight forward!!!! There are several intents at play — especially when different devices deal with multi-resolution displays differently. Once upon a time, we had a simple rule. 1 inch is 72 points, and mosts screens used an broadly equivalent resolution so 72 (or otherwise 96) physical pixels was also roughly 1 inch. Now we have retina displays, 300DPI ereaders and the like and the question is the pixel does not mean what we used to mean by it. On the Mac, with retina displays, a pixel is actually not a pixel, but 4 pixels (2X and 2Y), and when it tells you the resolution width is 1800 it really uses 3600 display pixels and scales back to make things the same size as if it was 1800 traditional pixels on a 72dpi device.

So the pixel is a relative measure that tries to follow the general intent. Here is what W3 the organisation that maintains HTML and CSS that EPubs are made from has to say:

The px unit is the magic unit of CSS. It is not related to the current font and usually not related to physical centimeters or inches either. The px unit is defined to be small but visible, and such that a horizontal 1px wide line can be displayed with sharp edges (no anti-aliasing). What is sharp, small and visible depends on the device and the way it is used: do you hold it close to your eyes, like a mobile phone, at arms length, like a computer monitor, or somewhere in between, like an e-book reader? The px is thus not defined as a constant length, but as something that depends on the type of device and its typical use.

https://www.w3.org/Style/Examples/007/units.en.html

Clear as mud. They go on to clarify:

CSS also defines that raster images (such as photos) are, by default, displayed with one image pixel mapping to 1px. A photo with a 600 by 400 resolution will be 600px wide and 400px high. The pixels in the photo thus do not map to pixels of the display device (which may be very small), but map to px units. That makes it possible to exactly align images to other elements of a document, as long as you use px units in your style sheet, and not pt, cm, etc.


So pixels in CSS are not equivalent to image pixels, but the intent to display. If you have a 300DPI image then you have to recalculate the CSS px values to follow the intent of the 300DPI. That is what I think Scrivener is doing, it is saying display a 900x1300 physical pixel image with a 300DPI resolution (screenshot below) to yields an equivalent CSS reference pixel of 216 x 312px [ 300/72 = 4.16 --> 900 / 4.16 = 216]

Screen Shot 2018-01-03 at 16.04.28_SMALL.png
Screen Shot 2018-01-03 at 16.04.28_SMALL.png (467.61 KiB) Viewed 508 times


You cannot simply treat a CSS pixel as a physical pixel, otherwise each device may show an image at a different size (because they also treat physical pixels differently). That is why this is not a bug, and what I think Ioa was trying to convey.


----
postscript: the dry definition of the CSS reference pixel is here (assumes 96dpi to yield a size of 0.75pt):
The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm's length, 1px thus corresponds to about 0.26 mm (1/96 inch).
https://www.w3.org/TR/CSS22/syndata.html#values
Last edited by nontroppo on Wed Jan 03, 2018 9:57 am, edited 4 times in total.

User avatar
Bridey
Posts: 390
Joined: Wed Nov 22, 2017 2:24 pm
Platform: Mac

Wed Jan 03, 2018 8:12 am Post

Ouch. Brain needs to work too hard.

So if a user wants to display an image at 100%, they can use the placeholder tag and the ebook=100% setting but keep the original file outside of Scrivener, but once inside Scrivener it is restricted to a reduced pixel-defined output?

Mick's original image is 1080x1440 pixels. When output, it is height:346px;width:259px.

I just don't understand why it gets changed. If it goes in with a set pixel size, why isn't that size maintained? 1080x1440 pixels in and 1080x1440 pixels out. (If your post above explains the answer, I apologise for asking again. I just don't get why outside of Scrivener it can be one thing, but inside it is something else.)

User avatar
nontroppo
Posts: 874
Joined: Mon Mar 05, 2007 5:22 pm
Platform: Mac
Location: Airstrip One

Wed Jan 03, 2018 8:36 am Post

It doesn't get changed!!! - in my test I added a 900x1300 300DPI image to Scrivener's binder, then drag it into a document, then compile it to EPub3 and in the EPub ZIP file the image is still a a 900x1300 300DPI image. Scrivener is NOT changing any images (at least not for this workflow). It utilises CSS reference pixel values in the HTML to size it to retain the 300DPI intent.

Mick's original image is 1080x1440 pixels. When output, it is height:346px;width:259px.


Again the image is not changed, the CSS is simply saying that to display a 300DPI image using CSS reference pixels it need to apply the maths [300/72 = 4.16 | 1080 / 4.16 = 259][1], the image is unchanged (and because it is actually still 1080physical pixels, will display with a higher visible resolution). It is an incorrect assumption to expect a physical pixel to always equal a reference pixel. Mick should just remove the 300DPI metadata from his images, and stop worrying about pixels and start thinking about the final goal.

Use Percentages for ereaders is what seems to be the simplest solution. If the image looks low resolution, increase the size of the source image and keep the percentage the same.

----
[1] I would argue Scrivener is actually applying wrong maths because the reference pixel in CSS is not 1pt but 0.75pt (as it is based on a 96dpi reference) so it should be 300/96=3.125 --> 1080/3.125 = 346

User avatar
Bridey
Posts: 390
Joined: Wed Nov 22, 2017 2:24 pm
Platform: Mac

Wed Jan 03, 2018 9:02 am Post

Thank you.

I need to digest.

Understand all the words, but not why images inside and outside of Scrivener are treated differently. The same image dragged into Scrivener looks smaller than the same image compiled from outside Scrivener. If a user wants to display an image at 100%, we know it will scale to 100% of what is available on the reader's device: it won't overlap any boundaries...it remains fluid. I don't get why Scrivener doesn't just output a percentage (or have that as an option) for images dragged into projects. Few people would want their ebook cover crunched down to a third of its original size.

I'm happy as I use placeholder tags. I know that other Scrivener users are similarly perplexed by what happens to their images once inside Scrivener. I advise people to use placeholder tags or or manage images post-compile, but I would still like to understand as much as I possibly can.

User avatar
nontroppo
Posts: 874
Joined: Mon Mar 05, 2007 5:22 pm
Platform: Mac
Location: Airstrip One

Wed Jan 03, 2018 9:30 am Post

If your image is 72DPI, it will look the same in Scrivener's binder as it does in macOS Preview:

Screen Shot 2018-01-03 at 17.20.06.png
Screen Shot 2018-01-03 at 17.20.06.png (550.16 KiB) Viewed 469 times


The problem is if you start trying to use DPI, thinking it is doing something it is not. Preview does not scale images to take DPI into account, nor does an image editor like Pixelmator because they are physical pixel based, so they both will look different to Scrivener. But look what happens in Microsoft Word 2016 when I drag in my 300dpi (top) and 72dpi (bottom) image (remember this is the SAME 900x1300px image, only the DPI metadata is different), Word is doing eactly what Scrivener does, read the 300dpi metadata tag and size the image to respect that intent:
Screen Shot 2018-01-03 at 17.26.32.png
Screen Shot 2018-01-03 at 17.26.32.png (54.6 KiB) Viewed 469 times


I think I agree that allowing to have Scrivener's "Scale Image" dialog to work in percentages may make some sense, but consider that the width in scrivener is not a hard value, it depends on the writing mode (page view etc) you are in and your editor width settings — Scrivener must appeal to both the editing side and the compile side. And each output format the % will mean something different! But for ebook users having a % entry would at least bring parity with the recent addition to the placeholder syntax...

User avatar
AmberV
Posts: 20801
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Santiago de Compostela, Galiza
Contact:

Wed Jan 03, 2018 12:02 pm Post

Sorry I’m clueless as the whole antagonistic undertone from the posts a bit ago. It seems there is some reading into the tone here that certainly wasn’t intended. I’m not inclined to get in a tussle over it however. As noted you are alas already speaking with “the super”, and I don’t think anyone else on our tech support staff has extensive experience in graphic design—at least I’m always the one that gets deferred to for questions of this nature.

Hopefully you manage to find the best way to use Scrivener from someone else then, if you’d rather not work with me.

⠂─────── ⟢⟡⟣ ─────── ⠂

Bridey wrote:I’ve long struggled when working with imported images that I can actually see in Scrivener, though appreciate that it isn’t a layout/image program. They always look smaller than the originals outside of Scrivener, which is partly why I have defaulted to using placeholder tags: the compiled images look more like they do in Photos or Preview etc.

That’s a good question! Think in terms of relative sizing and whether or not the image is in fact the right or wrong size in context with the other elements in the editor. Here is a simple test demonstrating what I mean:
  1. Drop the example ColorBurst image into an editor. We know from the numbers that it is set to display 259pts wide.
  2. Set your font to Courier (or any perfectly 10 pitch font) and create a number scale along the bottom of the image. You will be able to fit 36 characters along the bottom of the image. A 10 pitch font means that 10 characters will fit within an inch. Thus our 36 character “ruler” correlates with the known fact that 259pts = 3.6". The image is perfectly sized within the context of the text.
  3. All right, so the contention is that the image is larger in Photoshop than in Scrivener. So let’s test that. Do the same exact thing in Photoshop with the 12pt font along the bottom of the image. You should get the same result: 36 characters in a 10 pitch font = 3.6", just as the image is set to print.
    So why is the image larger in Photoshop? There is a very simple answer to that which should probably be more obvious now that you have the same exact text typed into two different places using the same exact metrics: the font in Photoshop looks about twice as large.

    Image
    The answer is that tool in the lower left hand corner of Scrivener’s editor, which in the screenshot shows “100%”. Try setting that to 210% and then see how things compare to editors, like Preview and Photoshop, that display the image bereft of any typesetting or page layout style factors. Why 210? I don’t know, that seems to be the factor by which macOS considers native scaling vs the literal pixel weight it takes to construct fonts and pictures at a certain scale. It’s not displaying a 12pt font at its literal size using the pixels of your display to do so—it is scaling it to create a useful balance.
So that’s why a postcard sized image looks a bit smaller in Scrivener—it is still postcard sized, and if you blow up the magnification of the editor so that the text and layout matches a sheet of A4, you will see that it is the correct size—you’re just zoomed out by default. :)

I understand about using the placeholder image tag and setting the ebook percentage, but is it possible to achieve the same 100% if the user drags an image in from the binder within Scrivener?

Yes. That is what I mentioned above when I said that using 72 DPI images and leaving the slider alone—or using the slider to set the image to 72, has the same exact effect as using a placeholder and stipulating the width of the image to its raster size. Both will be detected by the software as “native size”, and result in 100% being used in the eBook output automatically. Here is the HTML one gets when using the slider to correct the image’s settings back to screen-optimsed 72 DPI:

Code: Select all

<div><img src="images/ColorBurst1.jpg" alt="" id="colorburst1" style="width:100%;" /></div>


Hence, one doesn’t need “code” if they don’t want it. That isn’t sarcasm.

nontroppo wrote:I think I agree that allowing to have Scrivener’s “Scale Image” dialog to work in percentages may make some sense, but consider that the width in scrivener is not a hard value, it depends on the writing mode (page view etc) you are in and your editor width settings — Scrivener must appeal to both the editing side and the compile side. And each output format the % will mean something different! But for ebook users having a % entry would at least bring parity with the recent addition to the placeholder syntax…

Yeah there are a lot of problems with percentages being based on the sliders. I think a better approach is probably more in line with how the placeholder works: you still have static measurements (the slider) because that is how the text engine is designed, but you can override that for contexts where it makes sense to do so with a separate setting.

It’s a bit difficult to convey precisely what the means in a short UI label though. You’d have to somehow convey that the percentage only applies to dynamic viewports like eReaders, that it has nothing to do with the appearance of the image in the editor, will be ignored when compiling to PDF, and isn’t actually a modification or scaling of the image itself, but rather a declaration of how much of the relative viewer space available the image should occupy. I.e. it’s not “display the image at 50% scale”, it’s use 50% of the viewer to display this image—which might in some cases be magnifying the image by several thousand percentage points, if we have it blown up on a 16 x 16 monitor grid at a convention centre wall.

Whew. :)
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

User avatar
nontroppo
Posts: 874
Joined: Mon Mar 05, 2007 5:22 pm
Platform: Mac
Location: Airstrip One

Wed Jan 03, 2018 1:18 pm Post

Yes, explaining the intent is tricky indeed! As we've seen with pixels, it is easy to jump to conclusions based on false assumptions due to a technically complex space. How about: "EBook device width override [ 75% ]", or just short circuit this and directly say "CSS width override for EBooks [ 50% ]", it is up to the user to understand what CSS width actually specifies.

User avatar
AmberV
Posts: 20801
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Santiago de Compostela, Galiza
Contact:

Wed Jan 03, 2018 2:43 pm Post

Using technical language might indeed be the best approach if the capability is elevated to the UI. It might also be better to have a toggle between “%” and “em” after the numerical entry field. For things like dividers and fancy capitals, you’d want the image to scale with the layout.

The question is whether having a technical setting off in a panel like that is a worthwhile code expense over the placeholder stuff. Would the original confusion have been resolved by such an approach, and would a hypothetical individual adverse to working directly with the technical underpinnings of an eBook be inclined to self-resolve point/pixel/DPI/screen/print/ppi/resolution madness via that approach?

Hmm, maybe breaking the panel up between print settings and digital settings too.

Anyway, in the words of Dante. :lol:
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

mi
mickputley
Posts: 30
Joined: Sat Dec 23, 2017 1:13 am
Platform: Mac

Wed Jan 03, 2018 3:22 pm Post

I give up. You clearly feel that when I set the slider to state 346x259 POINTS I have an unreasonable assumption that the code Scrivener produces would state 346x259 POINTS instead of 346x259 PIXELS. If we cannot get on the same page about that, then this conversation isn't really going to go much further.

User avatar
nontroppo
Posts: 874
Joined: Mon Mar 05, 2007 5:22 pm
Platform: Mac
Location: Airstrip One

Wed Jan 03, 2018 3:49 pm Post

Mick, it is not what we may feel that matters, it is the specifications of the output medium that define this. Points are not used or generally recommended to set image sizes, but CSS pixels are:

In CSS there is no reason to use pt, use whichever unit you prefer. But there is a good reason to use neither pt nor any other absolute unit and only use em and px.
https://www.w3.org/Style/Examples/007/units.en.html

A pixel in CSS is NOT an image pixel, they are not the same thing. You have not understood that 100px in CSS can actually contain 1000px worth of image data.

Why not just remove the 300DPI metadata from your images, you do not lose any image quality, and then the correct translation Scrivener makes will match your feelings that a pixel in CSS is the same as an image pixel.

mi
mickputley
Posts: 30
Joined: Sat Dec 23, 2017 1:13 am
Platform: Mac

Wed Jan 03, 2018 4:16 pm Post

If we are not supposed to use points, why does the GUI express points, you cannot have it both ways.

User avatar
kewms
Posts: 3392
Joined: Fri Feb 02, 2007 5:22 pm
Platform: Mac

Wed Jan 03, 2018 4:47 pm Post

mickputley wrote:If we are not supposed to use points, why does the GUI express points, you cannot have it both ways.


You actually do use points for all formats except ePub/mobi.

Katherine
Scrivener Support Team

User avatar
AmberV
Posts: 20801
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Santiago de Compostela, Galiza
Contact:

Wed Jan 03, 2018 5:06 pm Post

What we seem to be having a hard time communicating is that the debate between points and pixels is beside the point, so to speak. In this context both of those units are inadequate within a flexible layout design; neither has a solid advantage over the other, and in the present tense, neither is terribly reliable or predictable and will differ from one system or device to the next. Given that this is the case, it would not make sense for us to spend time unravelling and changing how this works, if the result of doing so does not in fact provide an improvement in the output (and I would even go so far as to say it would be a detriment).

This has been stated, but perhaps not illustrated well enough. Have you tried what you are suggesting and substituted “px” for “pt” in Scrivener’s generated CSS and then opened the result in the ADE ePub engine and iBook reader and compared it with the Photoshop copy? I have, and it doesn’t solve your problem. It makes it a little larger than the pixel indicated version, but it’s still markedly smaller than the intended image:

Image
Here we have a cropped selection of samples as displayed in iBooks. They have been left to scale with one another, all I did was trim out the grey matte so that the illustration can be more concise.

On the left side we have the image that roughly matches what the graphic looks like in Scrivener’s editor, when imported as a print-ready graphic. On the right-hand side we also have an image that matches what we see in Scrivener, only we’re using a proper screen-ready 72 DPI graphic instead of a print image. In the middle we have something that is awkwardly neither. It is larger than what we have in Scrivener, but smaller than the image as it is intended to be displayed at screen resolution—this is the result you are arguing for, set manually to 259pts in the CSS. In the middle bottom we of course have the file as it opens in Photoshop, and at the scale it is intended to be viewed at.

So yeah—if you feel like your suggestion isn’t being acknowledged, this is part of why. I thought we had moved past that point in the conversation, but did not realise it had yet to be really thoroughly addressed, sorry about that.

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):

  • Em scales with the local font metrics around the image. What does that mean in a program that allows one to use 18pt Consolas while writing?
  • What is “width: 98%” when the fixed width editor setting is entirely arbitrary, and even more reliable markers of relative measurement between elements in a page and the page, like print settings, are unreliable when one can with the flip of a switch go from paperback novels to printing outlines on A4 (never mind there is no paper with an eBook so any use of paper is as weird as using points and pixels).
Do you have any suggestions toward these issues?
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

mi
mickputley
Posts: 30
Joined: Sat Dec 23, 2017 1:13 am
Platform: Mac

Wed Jan 03, 2018 6:17 pm Post

I appreciate your scientific view on this, but lets take a moment to think about your users. Most of them are not typesetters, or coders or web-page creators. Let's pretend for a moment that I was not in receipt of all the technical education you have provided.

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

I place that in Scrivener

To satisfy my curiosity by double-clicking the image

The slider tells me it is set to 346x259 points

I complile

I double-click the ePUB

My Mac opens the application and the 'view port' as you call it is set to a the same size as it always opens at, it is not configurable.

The graphic is tiny.

I break open the ePUB and look at the code. It says 346x259 Pixels not points.

I edit that code to either say 100% or change the pixels to points or remove any mention of the size so that it defaults to the native, or embed the picture as a tag

I open the ePUB and it looks perfect.

How can you not see that there is an issue to solve here? Do you not see

If I perform the exact same test of any other ePUB creating program I can find, this problem does not exist. If the resulting code does not reflect what the GUI says then the GUI is wrong. Put it another way. Why does the GUI even bother displaying numbers in Points?

User avatar
nontroppo
Posts: 874
Joined: Mon Mar 05, 2007 5:22 pm
Platform: Mac
Location: Airstrip One

Thu Jan 04, 2018 12:21 am Post

If Scrivener simply removes points in the GUI, your 300DPI image should still output 346x259 CSS px in the HTML, and that would still confuse you and other users... You say "If the resulting code does not reflect what the GUI says then the GUI is wrong", the resulting code IS correct[1]!!! A CSS pixel states it is based on a 96DPI reference, and you use 300DPI metadata in the image, so a conversion must take place, you cannot avoid it unless you use a standard DPI image.

So what if the GUI said 346x259 CSS px, would that solve this confusion? For ereader users they would at least become aware that CSS and image pixels are not the same thing. But what about all the users that output to Word, or PDFs, or Markdown, or ... — perhaps there should be a table of sizes for each possible compile format. I think this would be fascinating for me, but confusing for the users you are describing.

Or should Scrivener perhaps simply remove the 300DPI metadata to then make points and image pixels equivalent? That would have solved all this confusion, but then users may be angry that they think Scrivener is downsampling their 300DPI image to 72DPI (again to reiterate it wouldn't be, DPI is just metadata).

The solution is to guide HTML and eBook output authors to percentages or other relative units, but this may still yield some confusion and the GUI still has to take the other compile formats that wouldn't use % or another relative unit into account (what AmberV is discussing above). This is where IMO Scrivener needs to tweak the Scale image dialog.

-----------

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?

----
[1] well, almost :-) viewtopic.php?f=3&t=50135