Images DPI

[Bridey]

Attached is a zip with the compiled ePub and source folder.

You'd need to redirect the compiler to the right path (Desktop/LL in my case).

<$img:~/Desktop/LL/ColorBurst2.jpg;w=1080;h=1440>

The two images side by side look like this when compiled....

Second Version.jpg (331.24 KiB) Viewed 1969 times

E2.zip

(981.22 KiB) Downloaded 58 times

Know this is just a workaround to your preferred method.

[mickputley]

Yes confirmed, this workaround works. Thanks

I can also work around by "repairing" the error using Sigal or anything like that. In fact it can be repaired either by:

changing the style to "width:100%" or
chasing the px to pt or
deleting any mention of sizing (then defaults to native resolution of image).

I guess I'll try and put this out of mind and get on with writing until L&L confirm this a a bug and fix it.
M

[AmberV]

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:

Code: Select all

<$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.

[Bridey]

As an extra note, the % option is for ePub 3 and KF8 only...

viewtopic.php?f=2&t=41408&p=254997&hilit=scale#p254997

[mickputley]

Thanks,

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.

[AmberV]

Well yes and no. The basic answer is that at 72 DPI Scrivener’s reckoning of a point coincides with the size of a pixel, and so if you save your image into the editor that way it will be the right size on the Kindle. The above advice to use the <$img…> placeholder to specify the image as 1080px is identical to dragging the slider down to 1080px. Both achieve the same result.

What you’re running into is a print-context typesetting engine exporting to HTML-based technology with a priority on visual similarity: i.e. hold your Paperwhite up beside the text editor and you should see the 300 DPI image in the editor is about the same as the downscaled image on the Kindle. That isn’t the result you really want however: you want a 1080px wide image—so use 72 DPI. It doesn’t really make sense, for points to be used as pixels, in a technical frame of mind, but from a “WYSIWYG” kind of: just make my blog look like it did in Scrivener, it’s the better result.

Amazon’s recommendation to use 300 DPI is confusing and ultimately meaningless. The Kindle is entirely unaware of the DPI of an image. I think what Amazon is trying to get across to people is that their images should have enough pixels to provide a density of 300 ppi within the desired display width. That however is a mathematical statement for determining how many pixels wide the image should be—not an edict for setting the print dimensions in Photoshop, Scrivener, Word or anything that works in a traditional typesetting context with regards to image scaling. Pay no need to its DPI—or rather, manipulate your use of DPI to achieve your desired end: in this case 72 DPI is your best answer for Web and eBook related technology.

[mickputley]

I don't believe I agree. When I paste a picture into Scrivener and the slider says 346 x 259 *points* it codes 346 x 259 *pixels*. That is an error. The fact that I manifest the error by using a 300 dpi document shouldn't matter.

Forget what I mentioned about the Kindle. I am only using that as an example because I want to maintain one ePUB formats and not two. Amazon advises to publish by injecting ePUBs into their system not Mobi (although I confess they often change their mind). But never mind that. When Scrivener codes the picture at 346 x 259 *pixels* it is not doing what it said it will do. The bottom line is - it looks tiny because the code is wrong. I really would like this fixed, I appreciate the work-arounds but If I wanted to write code I'd be using InDesign or Sigil or something else. I really want to use Scrivener's excellent features including the WYSIWYG aspects.

Thanks

[AmberV]

Sorry, I don’t quite know what you are looking for then. The engine already works on a WYSIWYG framework, where an image about the size of a business card in the text editor comes out about the size of a business card on a Kindle/iBook/Webpage/etc. Just like it does in a PDF, or Word.

What you seem to be asking for is something other than that, where an image the size of a business card blows up to be the size of a postcard (how it knows that’s what you want, I don’t know). You can have that happen, but one needs to set the image to 72 DPI which will make it work in a more expected fashion with Web-based technology. No “code” necessary.

As I said, technically Scrivener’s use of points in a pixel field is inaccurate, but it achieves a consistent look (at least, as much as one can expect across different displays). That’s the reasoning—and if we changed that (assuming we even can, again I think this is how the text engine works) I’m sure we’d get nothing but complaints if the stuff that came out of the HTML/eBook format looked on average three to five times larger than in the editor.

[Bridey]

I don't believe I agree.

The politest and most diplomatic rejoinder on a forum. Ever. Love the civility of such a decorous reply.

Bravo.

[mickputley]

What I am looking for is for Scrivener to honor the setting on the slider. Right now it does not. I ask for so many points and I get pixels instead. What you seem to be telling me is that I have to change my DPI to compensate for the bug. Here is an *example* of the issue. When I open an ePub on a Mac, the application open the page at about 6.5 inches x 5 inches. A 72 dpi image looks significantly inferior to a 300 dpi image, I do not want to compensate for incorrect code by changing my DPI, I just want it to do what it says it is going to do which, by the way, every other product I have tried works.

As for keeping a bug because people are used to it... L&L are pretty much telling us that we have to re-learn the product for version 3. What a perfect opportunity to fix this.

[mickputley]

I have to confess I am dismayed by your response

An image the size of a business card blows up to be the size of a postcard

I am not asking for that. My image correctly displayed in photoshop at 100% is the size of an ebook page. When I open the page on the ebook reader it is tiny. We seem to be so far off the same page I attach a screenshot.

"(how it knows that’s what you want, I don’t know)."

It knows what I want because I tell it using the slider

"No code is necessary"
It is the Scrivener code the is specifically telling the reader to take the number of points I specify and wrongly specify that as pixels.

[AmberV]

Behold, what goes in, comes out.

That’s how it is intended to work. The above is not a bug.

If you want what is on the right side of the screen to end up being as large as what is in Photoshop (postcard), then you have been given the simple answer for how to achieve that result—and it involves making the left side of the screen look that way too.

As for your iBook window, all that demonstrates is that the image is smaller than the viewport you’ve created for it, which probably has more to do with the fact that the image was optimised for a small Paperwhite screen, originally. DPI is not used by any technology that displays eBooks. The metadata that is used to calculate the DPI is not used.

[mickputley]

I am disappointed by your increasing sarcastic tone and would like this issue escalated. Of course it is a bug, I am specifying a number of points in the slider and Scrivener is coding the HTML as pixels instead of points. Everything else is smoke and mirrors.

My support experience has damaged my opinion of this product, I have moved from elation to frustration and disappointment.

I would appreciate communicating with your supervisor or a developer.

[Bridey]

[quote="AmberV"]Behold, what goes in, comes out.[/quote]

Ioa, this is genuine ignorance and a desire to learn, not an attempt to inflame.

What goes in, as far as I see it, is a paperback-size image. What comes out is something much smaller. It doesn't look like a front cover from a book, filling one whole page.

This is emphasised by the fact that if we leave the image outside of Scrivener and compile using a placeholder tag, it still looks like a paperback-size image (see post above: viewtopic.php?p=256620#p256620).

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?

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.

Very confused...

[Bridey]

I would appreciate communicating with your supervisor or a developer.

FYI, Ioa is head of support. Keith is the only Mac developer (and founder).

http://www.literatureandlatte.com/about-us