Best practice to add an image

[Turtle91]

My comment was agreeing with Peter's comment...

The point is that I wouldn't reduce the quality of an epub that could be used on multiple devices just to cater to the foibles of an eink device. If you can do whatever to make it look decent on an eink without sacrificing quality on the rest of the devices, then it's your time/effort to spend. I have other things that I can use my time on...

[Hitch]

Originally Posted by PeterT

While the original post might have referred to e-ink I doubt that anyone is going to produce multiple versions of a book for differing classes of readers.

Sent from my Nexus 7 using Tapatalk

Originally Posted by Turtle91

Agreed....and I certainly wouldn't "dumb down" an epub just to make it look better on eink at the expense of every other device.

Oh, laddies, ye of little faith!

You think you have to "dumb down" a file, to make it look good on all readers? That's why the CSS gods invented media queries. Sheesh!

Don't assume that you have to tank a book to make it work on eInks, you really don't. If the imagery is good enough, it will work in various environments.

Hitch

[PeterT]

Originally Posted by Hitch

Oh, laddies, ye of little faith!



You think you have to "dumb down" a file, to make it look good on all readers? That's why the CSS gods invented media queries. Sheesh!



Don't assume that you have to tank a book to make it work on eInks, you really don't. If the imagery is good enough, it will work in various environments.



Hitch

I came so close to mentioning media queries in my post but was afraid of being technically incorrect

Sent from my Nexus 7 using Tapatalk

[Turtle91]

Sooo...revealing my ignorance here... I thought media queries could only select a different image to display based on the query results - thus requiring multiple sets of the same images. I don't think they can actually change the rendering of a particular image, other than basic dimensions,/transparency/z-order etc., can they??

[Hitch]

Originally Posted by PeterT

I came so close to mentioning media queries in my post but was afraid of being technically incorrect

Sent from my Nexus 7 using Tapatalk

Great minds think alike.

Originally Posted by Turtle91

Sooo...revealing my ignorance here... I thought media queries could only select a different image to display based on the query results - thus requiring multiple sets of the same images. I don't think they can actually change the rendering of a particular image, other than basic dimensions,/transparency/z-order etc., can they??

Well, you can, for example (using a Kindle mq here) set the display of a given image to different sizes, based on the screen size of the device--which we use, for example, to target the difference between an iPad and a "real" Kindle. Or an eInk versus a tablet. It's tedious as hell, don't get me wrong, but it can be, and is, done.

And, in the circumstances we were discussing--rendering a specific image this way or that, due to which device it would be read upon--wouldn't using specific images for specific devices make sense? We do this, also, in MOBI, for the whole KF7/KF8 scenario--we set the size of images in pixels for KF7s and percentage of screen for KF8. It's not that different, really, from what we're discussing here. Yes, it would be far harder to try to target screen dimensions to make that equal certain devices, in the "world" of ePUBs, but it could be done, or at least, take a decent crack at it, I would think.

Just my thoughts on it. My point is, really, you don't have to "dumb down" for eInks, and I wish you guys wouldn't, as someone who reads almost exclusively on one. :-)

Hitch

[JSWolf]

Originally Posted by Hitch

Oh, laddies, ye of little faith!

You think you have to "dumb down" a file, to make it look good on all readers? That's why the CSS gods invented media queries. Sheesh!

Don't assume that you have to tank a book to make it work on eInks, you really don't. If the imagery is good enough, it will work in various environments.

Hitch

Sorry, but media queries are out as they fail on RMSDK used in most Readers that use ADE. And as ePub is most read with different versions ADE, you cannot rely on media queries to works. I don't know if they work with the latest ADE 4.x. I've not tried it and I never will as long as ADE 2.0.1 still works.

[JSWolf]

When creating images for eInk, you should make them of high-resolution so they look good on a 300DPI eInk screen. When you have a 300DPI eInk screen, a low-resolution image can be hard to see.

[Hitch]

Originally Posted by JSWolf

Sorry, but media queries are out as they fail on RMSDK used in most Readers that use ADE. And as ePub is most read with different versions ADE, you cannot rely on media queries to works. I don't know if they work with the latest ADE 4.x. I've not tried it and I never will as long as ADE 2.0.1 still works.

Well, then, Jon, with all due respect, you're kinda blowing smoke, aren't you? ADE 2.xx has been old news for quite a while. It's fine if that's what YOU want to use, but basing your statements of "fact" on a version that's yesterday's news...c'mon. Media queries are supported in the standard, and, AFAIK, they work on the more-common ePUB devices, from the iBooks software on iPads to Nooks.

Originally Posted by JSWolf

When creating images for eInk, you should make them of high-resolution so they look good on a 300DPI eInk screen. When you have a 300DPI eInk screen, a low-resolution image can be hard to see.

Yes, but this is true for older devices as well. The resolution of the screen almost doesn't matter.

Hitch

[DNSB]

Originally Posted by Hitch

Well, then, Jon, with all due respect, you're kinda blowing smoke, aren't you? ADE 2.xx has been old news for quite a while. It's fine if that's what YOU want to use, but basing your statements of "fact" on a version that's yesterday's news...c'mon. Media queries are supported in the standard, and, AFAIK, they work on the more-common ePUB devices, from the iBooks software on iPads to Nooks.
Hitch

To toss in my two cents worth since I vaguely seem to remember that this thread was about "Best practice to add an image", if we are talking epub, image sizing can be done as percentages or for full page images by using svg wrappers (while you can do partial page images with an svg wrapper, some ereaders are not happy with the result) with no need for media queries. Now if we want to start talking about epub3 audio and video, media queries can come back into play but for simple image sizing, they are a non-issue.

As for ADE 2.xx being old news? Even with the firmware currently loaded on my Clara HD, I needed to convert to kepub for any media queries in Klaus Schallhorn's media query test ebook to do anything. An old Kindle DX one co-worker still keeps around also lacks media query support. I also have another test ebook which has a couple of empty amzn media queries which crashes and burns on older RMSDK versions though I haven't tested it in the last 18 months or so.

[Hitch]

Originally Posted by DNSB

To toss in my two cents worth since I vaguely seem to remember that this thread was about "Best practice to add an image", if we are talking epub, image sizing can be done as percentages or for full page images by using svg wrappers (while you can do partial page images with an svg wrapper, some ereaders are not happy with the result) with no need for media queries. Now if we want to start talking about epub3 audio and video, media queries can come back into play but for simple image sizing, they are a non-issue.

As for ADE 2.xx being old news? Even with the firmware currently loaded on my Clara HD, I needed to convert to kepub for any media queries in Klaus Schallhorn's media query test ebook to do anything. An old Kindle DX one co-worker still keeps around also lacks media query support. I also have another test ebook which has a couple of empty amzn media queries which crashes and burns on older RMSDK versions though I haven't tested it in the last 18 months or so.

Actually, the thread derailed somewhere along the line, and the conversation veered off into whether or not color images are viable on eInks, or something like that. I threw in MQs on that topic. I mean...personally, I find that most eInks--even my trusty old K2 (the battery of which is, I believe, finally going to that great Power Source in the sky....) render images remarkably well, color or otherwise. BUT, if someone is convinced that they need grayscale or B&W images, to "work" on an eInk, well...mqs.

You can easily swap out images--color for the tablet readers, B&W for the eInks, using MQs. That's what I was talking about, not the sizing, per se--although, we do, in fact, also use MQs for sizing issues, so that the KF7s render based on pixel sizes for each specific image, whilst the KF8s, etc., render using percentages/ems.

FYI, while DXes, K2's, etc., do not (themselves) have support for mqs, the Amazon rendering engine does. You can produce quite nice "old mobis" using MQs whilst simultaneously producing tasty KF8s and all that, using MQs. We use MQs all the time, at my shop, for all sorts of things. You can alter the color of text, if it's going to be seen on an eInk, for example. You can change font sizes, based on screen size.

There's even a section in Appendix C that talks about using MQs specifically for "backward compatibility with MOBI." You can target device-aspect-ratio, or device-height/width, to narrow down what you're doing, for eInks or KF7 devices over KF8, or vice-versa. The guidelines even have an example that targets 3 iPads, via the device-width. They have another that targets all Fires, using the device-aspect-ratio of 1280/800. We've been using similar coding, not to be "fancy," but to work around issues in the K4iPad/iPhone readers, for a few years now.

So, you're right, you don't use MQs on the DXes, K2s, KKeyboards, etc.--you use MQs to write the code for the Fires, the PPW, the Voyages, K4iOS, etc., and have the base code be the working code for the KF7s. :-) You just have to back into it. :-) It works.

FWIW.

Hitch

[JSWolf]

Originally Posted by Hitch

Well, then, Jon, with all due respect, you're kinda blowing smoke, aren't you? ADE 2.xx has been old news for quite a while. It's fine if that's what YOU want to use, but basing your statements of "fact" on a version that's yesterday's news...c'mon. Media queries are supported in the standard, and, AFAIK, they work on the more-common ePUB devices, from the iBooks software on iPads to Nooks.


Hitch

Do you know when ADE added media queries? The problem is that old versions of RMSDK are still in use and media queries won't work. So using media queries in ePub won't work for a lot of Readers. I don't know if the version RMSDK Kob is using works with media queries. I'll have to test it.

[Hitch]

Originally Posted by JSWolf

Do you know when ADE added media queries? The problem is that old versions of RMSDK are still in use and media queries won't work. So using media queries in ePub won't work for a lot of Readers. I don't know if the version RMSDK Kob is using works with media queries. I'll have to test it.

I don't know. Honestly we primarily use mqs for MOBI, but I'm reasonably sure that we had some issue, around iBooks, a while back, that we addressed with MQs for ePUB. Can't remember now what the hell it was, though.

Hitch

[j.p.s]

To get back on track, I can give an example of a 2015 e-book with a mix of really good and really bad images. It is currently $1.30 at amazon US and a free sample almost certainly has the tables that are the worst and likely has a couple of maps.

Originally Posted by sufue

Marcus Agrippa: Right-hand Man of Caesar Augustus is a biography of...you can probably guess ...by Lindsay Powell, published by UK specialty publisher Pen & Sword.

The multi-page "Chronology" and "List of Consuls" tables are scanned images with poor contrast and bad JPEG artifacts. Interestingly, the bottom of the "List of Consuls" table only takes up a few lines at the top of a page and was scanned with significantly higher resolution and better contrast, although the JPEG artifacts are little better.

Regardless of the target display, I think text should be scanned in monochrome at high resolution, say 1200dpi or more depending on scanner quality. (If the scanner is not that good, high resolution can get quite noisy.) Then the contrast should be aggressively stretched, then the image shrunk with a method that combines high resolution back and white neighboring pixels to make gray pixels. (Most web browsers do this as do many image processing utilities.)

[Hitch]

Originally Posted by j.p.s

To get back on track, I can give an example of a 2015 e-book with a mix of really good and really bad images. It is currently $1.30 at amazon US and a free sample almost certainly has the tables that are the worst and likely has a couple of maps.

https://www.amazon.com/Marcus-Agripp.../dp/B00TOXQLDY

The multi-page "Chronology" and "List of Consuls" tables are scanned images with poor contrast and bad JPEG artifacts. Interestingly, the bottom of the "List of Consuls" table only takes up a few lines at the top of a page and was scanned with significantly higher resolution and better contrast, although the JPEG artifacts are little better.

Regardless of the target display, I think text should be scanned in monochrome at high resolution, say 1200dpi or more depending on scanner quality. (If the scanner is not that good, high resolution can get quite noisy.) Then the contrast should be aggressively stretched, then the image shrunk with a method that combines high resolution back and white neighboring pixels to make gray pixels. (Most web browsers do this as do many image processing utilities.)

So, you think that the tables and images are not viable for eInks, but usable on Fires or other tablets, is that right?

Hitch

[j.p.s]

Originally Posted by Hitch

So, you think that the tables and images are not viable for eInks, but usable on Fires or other tablets, is that right?

Hitch

As I wrote some of the images look good on any screen, some of them are about as good as any I've seen in e-books so far, not that I have seen more than a very tiny fraction of e-books, but I've seen enough to have an idea of what is typical.

The tables, which are images, look bad on any screen, except for the last image of the list of consuls, which was pretty good, maybe even overkill, except for the JPEG artifacts.

I have seen similar tables in other books that are much worse, but these could have easily been a lot better at the same resolution. And I think these are still a good example of how not to do it.