View Full Version : ADE image resampling and lack of zoom


sarah_pnix
12-10-2012, 06:45 PM
If I put an image in an epub and it displays at the exact size, say 600 pixels wide, it looks great. I set the max-width to 100% so if it's viewed on a smaller screen it doesn't get cut off. But when it's reduced to fit, it looks like crap. Like really bad (I'm dealing mostly with line drawings so it's more noticeable than a photograph). It seems like whatever formula Adobe's using is just not adequate.

Has anyone else experienced this or have a solution? I'm mostly dealing with the Bluefire app, but it appears to be an ADE issue. I saw one post from someone with a similar problem with their sheet music images. Didn't see a good solution.

I wish you could zoom. So frustrating. Do you think ADE will ever add zoom for epubs? iBooks is much better on this particular issue of image resampling and zoom.

Thanks for any ideas,
Sarah

DSpider
12-11-2012, 06:59 AM
Use SVG; they scale really well. There are lots of tutorials on YouTube on how to trace a bitmap image in, say, Inkscape. There's also Adobe Illustrator and Vector Magic. Good luck.

sarah_pnix
12-11-2012, 06:31 PM
I have the original vector images in Illustrator. Is SVG universally supported? I've seen some examples on this forum, but have never tried it myself. One thing I don't get is that you set the image to appear at a specific size, right? Then what happens on different screen sizes? I'll have to find a tutorial that explains the basics. Any recommendations?

wallcraft
12-11-2012, 07:11 PM
Start with wiki: SVG (http://wiki.mobileread.com/wiki/SVG). The most common examples give fine control over image scaling, for example illustrated ebooks with epub: using the svg image element (http://denis.papathanasiou.org/?p=592). Scaling an image isn't what you want to do, but it shows how the automatic sizing to the screen works.

sarah_pnix
12-11-2012, 08:10 PM
I apologize for my ignorance on this topic. Most examples I see are a bitmap image wrapped in SVG. That is different than having an actual SVG vector image, right?

sarah_pnix
12-13-2012, 06:17 PM
Spent the day experimenting with svg files out of Illustrator. Could not get gradients fills to display correctly in Bluefire, even though they look fine in ADE on my desktop. Otherwise it seemed promising, but I think I'm giving up.

So, I'm back to jpg/png and dealing with ADE's horrible image scaling. Found another post about it, good to know it's not just me (http://www.mobileread.com/forums/showthread.php?t=170918&referrerid=58168).

Any other thoughts or ideas? It's depressing that some readers will see these embarrassingly poor images and I have no control over it.

Toxaris
12-14-2012, 04:35 PM
Wrapping an image in SVG will already solve several scaling issues. The problem with SVG is that not the whole 1.1 spec should be supported and that not all readers actually support it that well.
If you keep it simple, it will work. I don't work with Illustrator, but I would not be surprised if it would use a newer format than 1.1 and contains some operators that are not readily supported.

sarah_pnix
12-14-2012, 06:48 PM
Thanks for the reply, Toxaris. Illustrator says it's saving as SVG 1.1, but who knows.

Are you saying that wrapping a bitmap image in SVG will result in better scaling quality? Is there a way to set the SVG wrapper to display the image at max-width:100% ? When you set the view box to a certain size, I don't understand how you can get the image to scale to the screen width. Basically, on a smaller screen I don't want the image to be cut off.

Toxaris
12-15-2012, 05:15 AM
Even if it is SVG 1.1, certain things won't work. Things like animation, scripting and a lot of options with regards to text will not work.

Yes, an image in a SVG wrapper will give better results with scaling. As an example, the code I use as a base for my covers are:
<div>
<svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 522 800" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink">
<image height="800" width="522" xlink:href="../Images/cover.jpg"></image>
</svg>
</div>

The viewbox and image resolution must be equal to the resolution of the image. The width and height are set to 100%. That means that the image is scaled to either the maximum width or height of the screen, depending on what is reached earlier. If the screen resolution is below the image resolution, the image is rescaled upwards. If the image is larger, the image is scaled down.
The aspect ratio is preserved.

DSpider
12-15-2012, 08:09 AM
Yes, an image in a SVG wrapper will give better results with scaling.

[...]

...the image is scaled to either the maximum width or height of the screen, depending on what is reached earlier. If the screen resolution is below the image resolution, the image is rescaled upwards. If the image is larger, the image is scaled down.
The aspect ratio is preserved.

Doesn't that depend entirely on the e-reader?

Some may interpret them one way, while some may stretch both height and width to 100% resulting in a stretched image to the aspect ratio of the screen.

Toxaris
12-15-2012, 09:02 AM
No, I preserve the aspect ratio with the addition of: preserveAspectRatio="xMidYMid meet"

That would lead to the result I described.

Jellby
12-15-2012, 09:34 AM
Doesn't that depend entirely on the e-reader?

Some may interpret them one way, while some may stretch both height and width to 100% resulting in a stretched image to the aspect ratio of the screen.

If they obey the SVG code, they shouldn't alter the image's aspect ratio (as Toxaris said).

What is not clear at all is what "height: 100%" means in the <svg> tag. Try it in a browser, you'll probably see it ignored (i.e. the image doesn't fit the screen's height, or the window's height, or whatever). The CSS spec only says it's relative to the container's height, but there's no container, or rather the container's height is not defined, as it's a <div> inside <body>. It seems Adobe-based readers interpret this relative height with respect to the screen (minus margins, statusbar, etc., maybe), at least in some circumstances, but unfortunately that's not guaranteed.

sarah_pnix
12-17-2012, 03:02 PM
I tried wrapping a png image with svg following Toxaris' example above, but the scaling quality is no different. The original problem still exists—if the image has to be reduced to fit the screen, the quality is significantly worse than the original image.

dgatwood
12-19-2012, 03:45 PM
The CSS spec only says it's relative to the container's height, but there's no container, or rather the container's height is not defined, as it's a <div> inside <body>. It seems Adobe-based readers interpret this relative height with respect to the screen (minus margins, statusbar, etc., maybe), at least in some circumstances, but unfortunately that's not guaranteed.

The <div> element should have an explicit size—height: 100%; width: 100%; in the CSS. This should result in a <div> that fills the screen.

The SVG scaling rules are then applied within that container, which means that if you tell it to scale proportionally, it should grow to the maximum size that will fit entirely within that div, which is the size of your screen.

If a reader doesn't do that, it's a bug. :)

Jellby
12-20-2012, 01:49 PM
The <div> element should have an explicit size—height: 100%; width: 100%; in the CSS. This should result in a <div> that fills the screen.

Again, that 100% means 100% of the container's height, and the container (probably <body>) has no fixed height, but rather is as high as needed to fit its contents. As humans, we assume it means "100% of the screen height", but that's not what the spec says, and that's not what all renderers interpret (though it might be what some do).

Set it to "height: 10cm", or similar, instead, and it should work as expected (but not as wanted).

This, of course, unless I'm mistaken due to ignorance or misunderstanding of the specs :)

dgatwood
12-20-2012, 11:25 PM
Again, that 100% means 100% of the container's height, and the container (probably <body>) has no fixed height, but rather is as high as needed to fit its contents. As humans, we assume it means "100% of the screen height", but that's not what the spec says, and that's not what all renderers interpret (though it might be what some do).

Set it to "height: 10cm", or similar, instead, and it should work as expected (but not as wanted).

This, of course, unless I'm mistaken due to ignorance or misunderstanding of the specs :)

You're right. What I said wasn't quite complete. You'll also need to set sizes for the body and html tags and clear out their margins/padding.

It might also be worth using min-height instead of height just in case A. your content ends up on a device that doesn't support SVG, B. your fallback content is used, and C. it is taller than a screenful.


In other words:


<html style="min-height: 100%; width: 100%; padding: 0; margin: 0; border-width: 0;">
<body style="min-height: 100%; width: 100%; padding: 0; margin: 0;border-width: 0;">
<div style="min-height: 100%; width: 100%; padding: 0; margin: 0; border-width: 0;">
<object data="..." preserveAspectRatio="..." viewBox="0 0 100% 100%">
Optional non-SVG fallback HTML or image here
</object>
</div>
</body>
</html>


Because the outer html tag has no containing element, per section 10.1 of the CSS 2.1 spec (#1 in the numbered list), a width or min-height value of 100% causes it to fill the viewport (if it isn't already larger than the viewport) or the page, depending on whether you're talking about the web or paged media. In the case of an EPUB reader, I'd expect that distinction to be moot. :)

In an ideal world, we would all just use the new CSS3 viewport-relative lengths (vw and vh), but I suspect it will be many years before you can count on that unit being supported broadly enough to be useful.

Jellby
12-21-2012, 07:17 AM
Specifying 100% for html and below could work according with the spec, but I wouldn't trust readers to comply. On the other hand, it's only a solution if a file contains an image and nothing else (like a cover page), it's no good for mid-text illustrations.

Toxaris
12-21-2012, 07:46 AM
Some readers will actually give strange results if you set the <html> and/or <body> to 100%. For example in some cases the PRS-T1 will not advance to another page unless specifically the page number is entered.

dgatwood
12-21-2012, 12:45 PM
Some readers will actually give strange results if you set the <html> and/or <body> to 100%. For example in some cases the PRS-T1 will not advance to another page unless specifically the page number is entered.

As I said, you should probably use min-height, not height. By my reading of the thread (http://www.mobileread.com/forums/showthread.php?t=178947&page=2) from a few months ago, the bug in question involved setting height to 100%. IIRC, the spec is a little ambiguous about how height should be handled if your content exceeds a single screen height worth of content, which I'm assuming those test cases that triggered this bug probably did. And I could see how a reader could get confused (though it's still a bug) if that happens.

If it fails in this way with min-height: 100% and a single-page SVG image, however, then the reader is broken (and this seems much more unlikely). The specification is unambiguous about how that should be handled, and if you find that it does not work on the Sony reader, please file bug reports with Sony. They really need to fix that bug, as designs that include full-page-size images (for things like title pages) are likely to become more and more common as time passes, not less.

dgatwood
12-28-2012, 05:46 PM
As I said, you should probably use min-height, not height. By my reading of the thread (http://www.mobileread.com/forums/showthread.php?t=178947&page=2) from a few months ago, the bug in question involved setting height to 100%. IIRC, the spec is a little ambiguous about how height should be handled if your content exceeds a single screen height worth of content, which I'm assuming those test cases that triggered this bug probably did. And I could see how a reader could get confused (though it's still a bug) if that happens.

If it fails in this way with min-height: 100% and a single-page SVG image, however, then the reader is broken (and this seems much more unlikely). The specification is unambiguous about how that should be handled, and if you find that it does not work on the Sony reader, please file bug reports with Sony. They really need to fix that bug, as designs that include full-page-size images (for things like title pages) are likely to become more and more common as time passes, not less.

Actually, I'm going to have to correct that statement. You must use min-height only on the innermost div or whatever.

Because of a rather severe ambiguity in the CSS specification (Thanks, W3C), some browsers treat the parent element's height as zero if it is constrained only by a min-height. I consider that interpretation to be incorrect, but it's a popular interpretation, exhibited by both WebKit and Firefox. *sigh*

dgatwood
12-28-2012, 08:37 PM
-----
Deleting erroneous reply.