View Full Version : Besides file size, is there any reason I shouldn't use images larger than 600px wide


SarahMB
01-12-2013, 11:26 PM
I am new to e-publishing, so please forgive me if this is a silly question. I have tested this out by using images at, for example, 1000 px wide. When previewed in the online Kindle previewer, they seem to automatically size down to auto width or height (which ever hits the page margin first). It keeps proportion and seems to look fine. What is the down side to using images larger than the screen? If my file size is below the max file size, then should I still be concerned about optimizing the photos?

Thanks for your help!

Sarah

AnemicOak
01-12-2013, 11:48 PM
Most outlets have requirements or recommendations for minimum cover sizes...

Apple = at least 1,400 pixels wide required
Amazon (https://kdp.amazon.com/self-publishing/help?topicId=A2J0TRG6OPX0VM#dim) = 625x1000 minimum, 1563x2500 recommended
B&N = 1,200 to 2,000 pixels high recommended
Smashwords = Same as Apple (http://blog.smashwords.com/2012/06/new-ebook-cover-image-requirements.html)

With all the higher resolution devices it's nice to have high rez covers (speaking as a consumer). The biggest thing for an author/publisher to keep in mind is that higher rez is nice, but some distributors (such as Amazon) charge a fee based on the size of your file.

This post on cover size from Smashwords might be helpful..
http://blog.smashwords.com/2012/06/new-ebook-cover-image-requirements.html

PeterT
01-13-2013, 12:55 AM
I think Sarah is asking about images in general; not just covers.

AnemicOak
01-13-2013, 12:59 AM
I think Sarah is asking about images in general; not just covers.

I guess I missed that. Still I'd think you'd want to take into account people using higher rez screens. I know it sucks when I get a book that has a map or two and the publisher includes small images.

Jellby
01-13-2013, 03:28 AM
Large images are scaled down, fine, but this means two things:

1. The device must do the downscaling itself, this could make everything slower if there are many images.

2. The downscaling algorithm used by the device typically gives noticeably worse results than what you can get with an image processing program.

But, of course, there are also reasons to use large images ;)

SarahMB
01-13-2013, 02:50 PM
Thank you so much for taking the time to help me out.

So besides the higher resolution readers, are there additional reasons to use larger images?

In your experience, is there an ideal size? Does that "ideal" size differ for Kindle versus Epub formats?

Thanks again!

Sarah

mrmikel
01-13-2013, 03:41 PM
To my mind, it comes down to device. If it is a 800 x 600 pixel e-ink reader, then the images should be scaled down to just a bit smaller than that. For the tablets, it is a different story.

Design for the small screens should not be the same as for the bigger ones because pull quotes etc for the big screens that work great only create reading problems in the smaller ones. Inset pictures only squeeze the text or become microscopic without detail in the smaller ones.

I have just been working on this problem with some very nice commemorative pdfs put out by the US Marine Corps. They have inset paragraphs on general topics in the middle of the text flow that are fine on a big page, but would end two or three pages later in an e-ink reader. The reader would lose their train of thought if allowed to stay in place. My ultimate solution was a link to these general topics (and back). Pictures are not super clear on e-ink readers because of the narrow grayscale range, so they need to be a big as possible. A tablet can display images in color and hi-res.

The bigger the better, but only if the machine can display them to advantage and it doesn't have to waste cpu cycles resizing, slowing everything down.

Jellby
01-14-2013, 04:04 AM
So besides the higher resolution readers, are there additional reasons to use larger images?

Future, zooming and archive.

Future: Most readers may be 600800 today, but who knows what will be the norm in 5-10 years? Would you like to redo your book, re-scan the images, re-process them to adapt them to better screens?

Zooming: Some readers allow zooming of images, and I hope more readers will join. That means you should not feel limited by the screen size and resolution.

Archive: A low-resolution version of an image may be good enough for casual viewing, but some users may want a better version to observe smaller details, or for other uses.

mrmikel
01-14-2013, 06:24 AM
I hope there will always be small readers, as I find the size most useful to me. If I were to want to study closely some of the epubs I produce which contain maps, then the smaller size is not ideal.

Start with big images and mark them in your file system as read only so they won't accidentally overwritten. Then shrink them down to suit the need. Start with non-compressed formats (like tif) so that working with them won't create artifacts of being saved as something like a jpg in the end.

Zooming is reason to use larger images, but it will mean doubling the number of pictures. Even the PRS505 allows you to pan images so you can have larger ones.

I agree with Jelby on all but one point. If you save big images to begin with, you don't have to do anything but shrink them for a smaller format. And irfanview, a free program will batch resize them for you, if they can be the same size.

But the layout of a small book is never going to be the same as that of a larger one, for reasons I cited earlier. But a small book is not the best place for an image packed book in the first place.

One way to cut the Gordian Knot may be to save off the images for larger and smaller with almost identical names. Add a 1 at the end for the larger or smaller versions, then you could do a search and replace for .jpg and replace it with 1.jpg. That way you can use the same HTML and tweak for best appearance.

pdurrant
01-14-2013, 06:26 AM
The Mobipocket source format used to allow specifying different images for different resolution devices. Alas, I don't think ePub has any way of doing this.

mrmikel
01-14-2013, 06:37 AM
Instead of trying to turn epubs into web pages, epub3 ought to include something useful like you report pdurrant!

JSWolf
01-15-2013, 05:03 PM
Future, zooming and archive.

Future: Most readers may be 600800 today, but who knows what will be the norm in 5-10 years? Would you like to redo your book, re-scan the images, re-process them to adapt them to better screens?

Given that there are now some 768x1024 eInk readers out there, I expect eventually they will all be like that for a 6" display.

SarahMB
01-18-2013, 03:31 PM
Design for the small screens should not be the same as for the bigger ones

I did not realize that we could specify different files for different situations and different types of readers.

JSWolf
01-18-2013, 03:44 PM
I did not realize that we could specify different files for different situations and different types of readers.

Actually, you cannot. You cannot specify to use a specific image based on the screen size. You can't do "if it's an iPhone, use the smaller image and if it's an iPad, use the larger image" Standard ePub does not work like that. You have to build your ePub to fit most situations.

But what you can do is make your images aspect ration correct for most screens and then if you make them full screen, they will fit. Like the cover or maps.

dgatwood
01-18-2013, 04:19 PM
Actually, you cannot. You cannot specify to use a specific image based on the screen size. You can't do "if it's an iPhone, use the smaller image and if it's an iPad, use the larger image" Standard ePub does not work like that. You have to build your ePub to fit most situations.


Sure you can. You can use media queries with screen dimension limits. I can't imagine why you would want to, but you can. Media queries are fully supported by both iBooks and Kindle, as well as nearly all other non-Adobe-based readers.

Caveat emptor, however. If memory serves, Adobe Digital Editions barfs on media queries, so you need to put them in a separate CSS file if you care about compatibility. ADE is violating the EPUB spec (where it says that readers must ignore unknown CSS gracefully), of course, and I've written to Adobe about it, but I'm not holding my breath for a fix. It's easy enough to work around by putting anything that makes ADE angry into a separate CSS file (and in the file that ADE doesn't ignore, specifying a set of default behavior that you can live with).

That said, I think it is well understood that ADE fully complying with published specifications is one of the signs of the apocalypse, so it is arguably good that they'll probably never get around to fixing the bug. :D

JSWolf
01-18-2013, 05:32 PM
Sure you can. You can use media queries with screen dimension limits. I can't imagine why you would want to, but you can. Media queries are fully supported by both iBooks and Kindle, as well as nearly all other non-Adobe-based readers.

This is the ePub forum. ADE is the reader that most use to display ePub. Since it doesn't work in ADE, it doesn't work.

pdurrant
01-18-2013, 05:33 PM
This is the ePub forum. ADE is the reader that most use to display ePub. Since it doesn't work in ADE, it doesn't work.

The real question is whether "media queries" are part of the ePub spec. I haven't checked, but I suspect not.

JSWolf
01-18-2013, 05:42 PM
ADE & the ePub 2 spec do not support media queries. I just found the answer on Adobe's support forum and Jim Lester confirmed this.

http://forums.adobe.com/message/4325696?tstart=0

dgatwood
01-18-2013, 08:01 PM
ADE & the ePub 2 spec do not support media queries. I just found the answer on Adobe's support forum and Jim Lester confirmed this.

http://forums.adobe.com/message/4325696?tstart=0

The EPUB 2 specification does not require readers to support any CSS features beyond a subset of CSS2, and ADE does not support very many features outside the required subset (and does not support some of the required subset, either, but again, I digress).

The EPUB 2 specification does require readers to ignore anything that they do not understand, which ADE does not, and thus ADE does not comply with the specification as published.

"A conforming Reading System must render all OPS CSS 2.0 required subset properties. A Reading System may support CSS properties beyond the OPS CSS 2.0 required subset, however, any unsupported properties must be gracefully degraded per the CSS 2.0 specification." (OPS 2.0.1 section 1.3.5)


The graceful degradation section says:

"A conforming UA must also adhere to the forward-compatible parsing rules, the property and value notation, and the unit notation." (CSS 2.0 spec, Appendix D).

The forward-compatible parsing rules include this:

"In some cases, user agents must ignore part of an illegal style sheet. This specification defines ignore to mean that the user agent parses the illegal part (in order to find its beginning and end), but otherwise acts as if it had not been there." (CSS 2.0 spec, Section 4.2)

...

"All levels of CSS -- level 1, level 2, and any future levels -- use the same core syntax. This allows UAs to parse (though not completely understand) style sheets written in levels of CSS that didn't exist at the time the UAs were created. Designers can use this feature to create style sheets that work with older user agents, while also exercising the possibilities of the latest levels of CSS." (CSS 2.0 spec, Section 4.1)

And in particular:

"An at-rule consists of everything up to and including the next semicolon (;) or the next block, whichever comes first. A CSS user agent that encounters an unrecognized at-rule must ignore the whole of the at-rule and continue parsing after it." (CSS 2.0 spec, Section 4.1.5)

So from the EPUB specification, you can see that @media and @page rules are clearly legal in an EPUB 2.0.1 document. The EPUB spec clearly defines how such rules are to be handled. Specifically, a reader may interpret them, or it may ignore them, at its option, but it must not break.

JSWolf
01-18-2013, 08:14 PM
It doesn't matter that the spec says to ignore stuff. If epubcheck 1.1, 1.2, aND MAYBE 3.0 flags it as an error, then it won't be put up for sale.

So go put in the media queries to do the image selection based on screen size and see if it actually validates in all those versions of epubcheck.

dgatwood
01-18-2013, 08:15 PM
This is the ePub forum. ADE is the reader that most use to display ePub. Since it doesn't work in ADE, it doesn't work.

The comment I replied to was about iPhone and iPad, so in that context, that's not true for two reasons:

1. From what I've seen, the ADE-compatible readers on iOS appear to be built on top of WebKit rather than Adobe's rendering code, so there is a fair chance that they will handle media queries even though ADE on other platforms does not.

2. It is not a foregone conclusion that most iPhone and iPad users use an ADE-based reader rather than iBooks.

:)

dgatwood
01-18-2013, 08:23 PM
It doesn't matter that the spec says to ignore stuff. If epubcheck 1.1, 1.2, aND MAYBE 3.0 flags it as an error, then it won't be put up for sale.

So go put in the media queries to do the image selection based on screen size and see if it actually validates in all those versions of epubcheck.

Yup. Media queries pass validation in 1.1, 1.2, and 3.0.

JSWolf
01-18-2013, 08:53 PM
The comment I replied to was about iPhone and iPad, so in that context, that's not true for two reasons:

1. From what I've seen, the ADE-compatible readers on iOS appear to be built on top of WebKit rather than Adobe's rendering code, so there is a fair chance that they will handle media queries even though ADE on other platforms does not.

2. It is not a foregone conclusion that most iPhone and iPad users use an ADE-based reader rather than iBooks.

:)

Bluefire is based on ADE, not WebKit. All the offshoots of Bluefire are based on ADE. Sony's Reader software is based on ADE. I would guess that Overdrive would be based on ADE due to the DRM.

dgatwood
01-18-2013, 09:24 PM
Bluefire is based on ADE, not WebKit. All the offshoots of Bluefire are based on ADE. Sony's Reader software is based on ADE. I would guess that Overdrive would be based on ADE due to the DRM.

I could be wrong, but I thought I was seeing some WebKit-specific bugs in one of those. Maybe not, though.

That said, I just did an experiment, and can confirm that Sony, Bluefire, and Nook on iOS barf on media queries in the same way that ADE does on the desktop, sadly.

Ah. I just figured out which reader it was. Kobo. It's ADE-compatible (as in, it can read EPUB files with ADE DRM), but it uses WebKit for the rendering, supports CSS3 media queries, and even supports fun WebKit-specific variants of CSS3 properties, such as -webkit-border-radius.

pholy
01-18-2013, 11:27 PM
I don't have a new Kobo reader, so I can't check this, but it may be that the kepub renderer uses webkit, but I'm pretty sure any renderer that understands Adobe DRM has to be using the Adobe renderer. That's what I was told a couple of years ago.
I'm not sure how to create test cases for this either, without going through Kobo's Writing Life and getting both the kepub and DRM'd epub to check and compare.

AnemicOak
01-19-2013, 12:56 AM
I don't have a new Kobo reader, so I can't check this, but it may be that the kepub renderer uses webkit, but I'm pretty sure any renderer that understands Adobe DRM has to be using the Adobe renderer. That's what I was told a couple of years ago.


IIRC that's correct. They use WebKit for kePub and the RMSDK for ePub (or at least DRM'd ePub's if not all).

Jellby
01-19-2013, 03:50 AM
Just out of curiosity: How would you write a code to select images based on screen size or orientation based on media queries that would degrade gracefully in a theoretical perfectly-ePub-and-only-ePub-compliant reader?

dgatwood
01-19-2013, 05:02 PM
Just out of curiosity: How would you write a code to select images based on screen size or orientation based on media queries that would degrade gracefully in a theoretical perfectly-ePub-and-only-ePub-compliant reader?

Many ways. For example:


<div id="myimage"></div>

myimage {
background-image: .... default image here
}


@media ...
{
.myimage {
background-image: ...
width: ...
min-width: ...
height: ...
min-height: ...
}
}


or



<div class="smallDevice"><img src=... /></div>
<div class="mediumDevice"><img src=... /></div>
<div class="largeDevice"><img src=... /></div>

.smallDevice {
display: none;
}
.mediumDevice {
display: block;
}
.largeDevice {
display: none;
}

@media screen and (max-device-width: 720px) {
.smallDevice {
display: block;
}
.mediumDevice {
display: none;
}
}


@media screen and (min-device-width: 2000px) {
.mediumDevice {
display: none;
}
.largeDevice {
display: block;
}
}

Jellby
01-20-2013, 04:12 AM
Many ways.

"background-image" is not in the list of supported CSS properties in ePub 2.0.1. The other method (selectively disabling with "display: none") would work.

dgatwood
01-20-2013, 03:11 PM
"background-image" is not in the list of supported CSS properties in ePub 2.0.1. The other method (selectively disabling with "display: none") would work.

My bad. I forgot that EPUB doesn't even support all of CSS 1.0. I swear, every time I work with this stuff, it makes me feel like it's 1996 all over again, and I'm developing code for Netscape 2.0 while trying to maintain backwards compatibility with Netscape Mosaic 0.9b3 and lynx. :D

*sigh*