Image scaling best-practices - Page 2

theducks · 11-24-2018, 08:01 PM

Greg, you really need to avoid ABSOLUTE units whenever possible. No in. cm. even pt
Those stop scaling the item.
OK, there are a few items I choose absolutes: border: 1px,
sometimes padding: 2 px
but in most cases, I want things to track when I Zoom the page (eg. make font bigger)

Gregg Bell · 11-24-2018, 08:17 PM

Quote:

Originally Posted by jhowell

I can account for why the image in your book is smaller when delivered directly to the device from Amazon as compared with transferring via USB.

The USB copy will be in KF8 (azw3) format and will have the same HTML coding that you placed into the book. In this case the image will be displayed 200x300 pixels on a 600x800 pixel screen or 1/8 of the screen area.

The copy sent directly by Amazon will be in KFX format for newer Kindles, including the Kindle 7th gen with up-to-date firmware. This is the format used for delivery of most books these days and enables enhanced typesetting features such as hyphenation and page flip.

During conversion to KFX format Amazon applies several fixups to the book's original formatting intended to increase readability. Images coded with dimensions in pixels are converted to percent instead to promote consistency of display across devices with widely varying screen resolutions. The exact details are complex and I don't understand all of the rules, but in the case of your book the new size is width:23.4375% which happens to be 300 (your image height) divided by 1280 (typical HD screen height).

The result is that the image is displayed at 23.4375% of the screen width on all devices. For your Kindle 7 that will be 140x210 pixels or 1/16 of the screen area, so that the image appears about half the size of the KF8 version.

Wow, thanks for the explanation, jhowell. I really thought I was losing my mind there for a while. I still have one question, though, how come when I took the "height" and "width" out of the html (eg. screenshot 23), the final version from KDP of the image looked right sized (roughly 200X300)?

Okay back to your method. So, once Amazon's done with KFXing the file, all widths of images will be displayed at 23.4375% width of the device's screen size, right? So, as you said my 200X300 image would be 140X210 in a 600X800 device. So on a 800X1200 resolution device it would be displayed as 187X281, right? On 1600X2560 devices it would be displayed as 374X561, right? So it would behoove me to have an image size of at least 400X600, right?

And would I leave out the "height" and "width" info in the html img tags (as in 23) or leave it in as in 24)?

Gregg Bell · 11-24-2018, 08:33 PM

Quote:

Originally Posted by DNSB

1. I would specify the width in percent not absolute pixels. Setting the width to 33.3% would keep the image to approximately the same size regardless of the screen resolution (on a 600x800, 33.3% would be 200 pixels, on an Oasis 2, 33.3% would 421 pixels but the amount of screen used would be the same. Absolute units should be banned, IMNSHO.

2. The back/font cover image size? Personally, I like larger images. Using width=95%, a 1200 by 1800 image would pretty much fill the screen without pixelating on the higher PPI devices. On my personal devices which use epub ebooks, I use a SVG wrapper to display the image so it automagically fills more or less full screen however I suspect that while a KF8 ebook would be happy with this technique a KF7 (mobi) would tend to upchuck over the screen. I seldom do much with Kindle book creation hence the uncertainty.

Code:

<style type="text/css">
@page {padding: 0pt; margin:0pt}
            body { text-align: center; padding:0pt; margin: 0pt; }
</style>
</head>

<body>
  <div>
    <svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 1200 1800" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink"><image height="1800" width="1200" xlink:href="../Images/cover.jpg"/></svg>
  </div>

In an epub3, you have to add the svg property in the content.opf file.

Thanks David. That's very helpful. Question though, on the bigger screen sizes it seems they flip the width and height. So when a tablet is listed at 2560X1600, for an ebook we're still considering 1600 to be the width, right?

Gregg Bell · 11-24-2018, 08:57 PM

Quote:

Originally Posted by Hitch

THERE it is. I was sort of plowing my way toward this, but I thought it would be a KF7/KF8 thing; I don't have this mad depth of KFX expertise that @jhowell does, but I thought it would be something like this. I used to have these issues with the "send to kindle" and the faux WiFi-xfer functionality. Or, to be more accurate, I didn't, but our clients did, and it was a major source of aggro for me.

So, now--about percentages versus fixed-units. @DNSB--if he's serious about making MOBI files, he doesn't really have a choice--he has to use fallback coding that specifies the precise pixels, due to the KF7 devices that are still out there. If he doesn't, and uses percentages, that's ignored in the KF7, and his image can/will be blown up to the size of the screen, which sucketh when you have a small image. There's a thread--a very long, very tedious thread--somewhere here in the Sigil forum, in which slowsmile/William and I had a heated discussion about his plugin that creates the fallback coding for this very purpose. You (Gregg) can now ignore the heated part, but look at the info that his plugin provides--it does the heavy lifting for you.

@Gregg--you should be sizing your images primarily by the use of percentages, not pixels (for the KF8s) as that's more consistent in terms of look/feel. However, you do also need the fallback stuff for the KF7s. And honestly, speaking as a highly-paid perfesshnul (ha), only God knows why KFX is "fixing" the coding and changing the damn size. That one just makes my head hurt.

HOWEVER, bear in mind that what that means is that what you refer to as the "whispersynch" version is what other people are seeing--so break out the codebook, and write your media queries--you can use slowsmile's plugin's coding as a starting point.

HTH.
Hitch

Thanks Hitch. Couldn't find the thread (was surprised though that you were arguing with someone.

) I did find this one though https://www.mobileread.com/forums/sh...d.php?t=288294 and I read it. It was a little scary at first, doing all that it does. I start with .odt and turn it into an .html so that's what I'd be starting with. I did see this in his Cleanup Options:

Quote:

Reformat ebook images using percentage screen values to help normalize smaller image sizes across all ereaders.

But I didn't see anything about fallback stuff (specific pixel sizes) for the KF7.

Maybe you have a link for the thread I should look at?

btw I really like the % stuff the guys were sharing. But could they all be letting their images display improperly in KF7?

Gregg Bell · 11-24-2018, 09:00 PM

Quote:

Originally Posted by theducks

Greg, you really need to avoid ABSOLUTE units whenever possible. No in. cm. even pt
Those stop scaling the item.
OK, there are a few items I choose absolutes: border: 1px,
sometimes padding: 2 px
but in most cases, I want things to track when I Zoom the page (eg. make font bigger)

Thanks ducks. That's good to know about the scaling and absolute units. But from what I'm hearing I need absolute (fallback) units (pixels) for my images to display properly in KF7.

Turtle91 · 11-24-2018, 10:10 PM

Quote:

Originally Posted by Gregg Bell

...And why would a small image get overblown? And not sure what you meant by how much zooming I'm willing to allow.

If you use the % method and set an image to be 75% of the width of a 1000 pixel wide screen then the image would be expanded (or shrunk) to be 750 pixels wide (and whatever the aspect ratio drives the height to be).

If your original image is already 1000 pixels wide then your image will be compressed (from a viewing perspective - it doesn't actually change the image file). This is no big deal. Most readers/apps out there have good image rendering capabilities. The problem comes when you have a low definition image....say one that is only 200 pixels wide. This causes the device/app to expand (or zoom) the image to fill the space. In this case almost 4 times the original size. That much zoom will usually cause small images to look all pixelated and fuzzy. It is usually OK to zoom an image a little bit...but it depends on the quality of the image to begin with...you just need to experiment with your images and find what level is acceptable to you. I would think allowing a 200 pixel wide image get zoomed to 250 pixels will probably (maybe??) be ok...

I personally don't like putting any styling in the document itself. I like to keep it all centralized in the CSS file for ease of editing. I find you can give multiple images a unique id, or class, for easy reference in the CSS file. This is a matter of taste...some people find it easier to put the values in the <img> tag

.

Hitch · 11-24-2018, 11:13 PM

Quote:

Originally Posted by Gregg Bell

Thanks Hitch. Couldn't find the thread (was surprised though that you were arguing with someone.

) I did find this one though https://www.mobileread.com/forums/sh...d.php?t=288294 and I read it. It was a little scary at first, doing all that it does. I start with .odt and turn it into an .html so that's what I'd be starting with. I did see this in his Cleanup Options:

But I didn't see anything about fallback stuff (specific pixel sizes) for the KF7.

Maybe you have a link for the thread I should look at?

Took me a while to find it--this is the thread: https://www.mobileread.com/forums/sh...d.php?t=289277 There's some unnecessary heat because there was a lack of understanding, on the part of one of the posters, about whether certain devices were KF7 or KF8. After banging my head against the wall for a while,I lost my sense of humor about it.

Quote:

btw I really like the % stuff the guys were sharing. But could they all be letting their images display improperly in KF7?

Well, if the image is a large one, and intended to display the full-width of the screen, then they don't need to use px. However, if they have an image, let's say it's 1000px wide, and they only want it to display at, say...IDK, 40% of the width of the screen, and they use %, it will display at 40% on the KF8s--but it will be full-screen on the KF7s, period.

KF7 does not recognize % in image sizes, or in the CSS for images. You have to do fallback coding that sets the image size in px, period, or it will display as large as it can/as large as it is.

Hitch

DNSB · 11-25-2018, 01:12 AM

Quote:

Originally Posted by Gregg Bell

Thanks David. That's very helpful. Question though, on the bigger screen sizes it seems they flip the width and height. So when a tablet is listed at 2560X1600, for an ebook we're still considering 1600 to be the width, right?

If you read in landscape mode the width would be the larger dimension but for portrait mode which is still the most commonl use, width will be the smaller number. It gets worse -- if you look on Amazon and Kobo's pages, they flip the width/height on the ereader itself.

DNSB · 11-25-2018, 01:19 AM

Quote:

Originally Posted by Gregg Bell

btw I really like the % stuff the guys were sharing. But could they all be letting their images display improperly in KF7?

My personal stuff is all epub. The few times I've helped an author who is using Amazon, I've, ummm... borrowed (sounds much nicer) from several sources for the Amazon fixup bits and pieces. Even then, mobi, AZW3 and KFX do not display images identically. But neither do they display text identically. I strive for acceptable since I don't make a living from this -- that's what my day job is for.

DNSB · 11-25-2018, 01:31 AM

Quote:

Originally Posted by Hitch

So, now--about percentages versus fixed-units. @DNSB--if he's serious about making MOBI files, he doesn't really have a choice--he has to use fallback coding that specifies the precise pixels, due to the KF7 devices that are still out there. If he doesn't, and uses percentages, that's ignored in the KF7, and his image can/will be blown up to the size of the screen, which sucketh when you have a small image.

The next question is if you have tried generating a KF7 with an embedded SVG wrapper? I may have to try this just to see what happens though I suspect my upchuck all over the screen comment is a probable outcome.

jhowell · 11-25-2018, 09:26 AM

Quote:

Originally Posted by Gregg Bell

Wow, thanks for the explanation, jhowell. I really thought I was losing my mind there for a while. I still have one question, though, how come when I took the "height" and "width" out of the html (eg. screenshot 23), the final version from KDP of the image looked right sized (roughly 200X300)?

When you leave out the width/height styling entirely for those images in your book the KFX coding generated becomes width:39.063%, producing a 234x351 pixel image on your 600x800 device. I can't explain why this occurs. I do not understand all of the heuristics used during KFX conversion.

Quote:

Originally Posted by Gregg Bell

Okay back to your method. So, once Amazon's done with KFXing the file, all widths of images will be displayed at 23.4375% width of the device's screen size, right? So, as you said my 200X300 image would be 140X210 in a 600X800 device. So on a 800X1200 resolution device it would be displayed as 187X281, right? On 1600X2560 devices it would be displayed as 374X561, right? So it would behoove me to have an image size of at least 400X600, right?

Yes.

In the Amazon Kindle Publishing Guidelines section 9.4.2 (Image Size and Quality Standards) the minimum recommended size for a full page image is 1200x1800 pixels. So if you want your covers to occupy approximately 1/4 of the width of a screen the minimum image width should be 1200/4 = 300 pixels. Using 400 wide would be a good choice.

Quote:

Originally Posted by Gregg Bell

And would I leave out the "height" and "width" info in the html img tags (as in 23) or leave it in as in 24)?

In section 9.4.3 (Image Dimensions for Responsive Layouts) has guidance for how to style the images: "Amazon recommends that block and float images be styled using a percentage value for the width style attribute. This will ensure that images always occupy the same percentage of space on the screen irrespective of device resolution."

They fail to mention that this won't work well on older devices that only handle mobi7 format. For the best results across all devices I think that you should use media queries to have different coding for mobi7 (pixels) and kf8/kfx (percent) devices.

Hitch · 11-25-2018, 11:10 AM

Quote:

Originally Posted by DNSB

The next question is if you have tried generating a KF7 with an embedded SVG wrapper? I may have to try this just to see what happens though I suspect my upchuck all over the screen comment is a probable outcome.

KF7 no can do SVG. Test all you want, but upchucking is the result. (Actually, nothing is the result, but same idea. :-)

Hitch

Gregg Bell · 11-25-2018, 01:37 PM

Quote:

Originally Posted by Turtle91

If you use the % method and set an image to be 75% of the width of a 1000 pixel wide screen then the image would be expanded (or shrunk) to be 750 pixels wide (and whatever the aspect ratio drives the height to be).

If your original image is already 1000 pixels wide then your image will be compressed (from a viewing perspective - it doesn't actually change the image file). This is no big deal. Most readers/apps out there have good image rendering capabilities. The problem comes when you have a low definition image....say one that is only 200 pixels wide. This causes the device/app to expand (or zoom) the image to fill the space. In this case almost 4 times the original size. That much zoom will usually cause small images to look all pixelated and fuzzy. It is usually OK to zoom an image a little bit...but it depends on the quality of the image to begin with...you just need to experiment with your images and find what level is acceptable to you. I would think allowing a 200 pixel wide image get zoomed to 250 pixels will probably (maybe??) be ok...

I personally don't like putting any styling in the document itself. I like to keep it all centralized in the CSS file for ease of editing. I find you can give multiple images a unique id, or class, for easy reference in the CSS file. This is a matter of taste...some people find it easier to put the values in the <img> tag

.

Thanks a lot, Dion. Yeah, that makes sense. I don't have a lot of images in the backmatter and I could actually make all but one the same size, so it would be nice to get that done in the CSS. And thanks for the explanation about zooming.

Gregg Bell · 11-25-2018, 01:47 PM

Quote:

Originally Posted by Hitch

Well, if the image is a large one, and intended to display the full-width of the screen, then they don't need to use px. However, if they have an image, let's say it's 1000px wide, and they only want it to display at, say...IDK, 40% of the width of the screen, and they use %, it will display at 40% on the KF8s--but it will be full-screen on the KF7s, period.

KF7 does not recognize % in image sizes, or in the CSS for images. You have to do fallback coding that sets the image size in px, period, or it will display as large as it can/as large as it is.

Hitch

Thanks for finding the thread, Hitch. I too looked for it and couldn't find it.

I knew the Previewer in KDP changed but I didn't not know there was a downloadable Previewer 3. But you said, in that thread, it's pretty much worthless, right?

I thought Dion's

img {width:75%; max-width:250px}

might be the ideal solution. KF7 wouldn't work with that? It wouldn't recognize the 250 limit?

I wanted to try SlowSmile's plugin, https://www.mobileread.com/forums/sh...d.php?t=288294 but didn't know if I had Python 3.4. (screenshot) Does that mean I have 3.4 or do I have to get it? (And if I have to get it, where would I get it?)

Thanks.

Gregg Bell · 11-25-2018, 01:51 PM

Quote:

Originally Posted by DNSB

If you read in landscape mode the width would be the larger dimension but for portrait mode which is still the most commonl use, width will be the smaller number. It gets worse -- if you look on Amazon and Kobo's pages, they flip the width/height on the ereader itself.

Thanks David. Ah, confusion. I'm going to stick with portrait mode in my head. Landscape mode is too much for me right now.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
image scaling problems: due to PNG format	stumped	ePub	23	03-06-2017 05:30 AM
Scaling up an image via SVG	Kayto	ePub	27	01-26-2013 03:38 AM
Full page image best practices & TOC	illustrata	Sigil	2	04-26-2011 01:50 PM
Calibre News Epub Image Scaling	grib	Calibre	3	01-07-2010 06:45 AM

11-24-2018, 08:01 PM	#16
theducks Well trained by Cats Posts: 29,791 Karma: 54830978 Join Date: Aug 2009 Location: The Central Coast of California Device: Kobo Libra2,Kobo Aura2v1, K4NT(Fixed: New Bat.), Galaxy Tab A	Greg, you really need to avoid ABSOLUTE units whenever possible. No in. cm. even pt Those stop scaling the item. OK, there are a few items I choose absolutes: border: 1px, sometimes padding: 2 px but in most cases, I want things to track when I Zoom the page (eg. make font bigger)

Advert

Advert