Optimum scanning resolutions for images in Sigil?

[Jim the Obscure]

I'm in the process of assembling my first ePub book (Gertrude Jekyll, Wall & Water Gardens @ 454 KB / 91 pp of text in MS Word Doc) and will be using Sigil to do so once I've scanned the 150 odd b&w photographs (+/- 3 1/2" x5 1/2") in it. I did a test scan on my HP flatbed @ 300 ppi / 256 grayscale and got a 1.42 MB file (which is going to add up) so I tried the same grayscale at 150 ppi and got a 260 KB, which is better, but would still add up to about 40 MB in images alone - couldn't see much difference in quality between them. I will be importing them into Word 2003 and saving as HTML, Filtered, then opening in Sigil (which I’m still learning).

My question is (& I've searched a lot) what is the optimum PPI resolution for scans of b&w photographs to be imported into Sigil for display on both e-readers and in something like Calibre on a computer? What is the trade-off point between file size and quality in terms of resolution? Most of the ePubs that I've downloaded from places like archive.org are crawling with OCR errors from the Google scans and I've edited this text carefully for spelling (horror show of old & Latin plant names and tons of italics) and would like it to look nice but not be too huge. Also wondering about resolutions for colour scans too for future projects. (Best saved as JPEG's?)

I post a lot of cleaned-up text of (mostly) old gardening book excerpts on my blog (jimtheobscure.com) if anyone's interested – ps - wordpress.com doesn't support the upload of ePubs but I contacted Scribd support (looking for a place to park some) to inquire and they replied that they hope to be supporting them within the next quarter - now to work on Wordpress.

Thanks!

[Hitch]

Originally Posted by Jim the Obscure

I'm in the process of assembling my first ePub book (Gertrude Jekyll, Wall & Water Gardens @ 454 KB / 91 pp of text in MS Word Doc) and will be using Sigil to do so once I've scanned the 150 odd b&w photographs (+/- 3 1/2" x5 1/2") in it. I did a test scan on my HP flatbed @ 300 ppi / 256 grayscale and got a 1.42 MB file (which is going to add up) so I tried the same grayscale at 150 ppi and got a 260 KB, which is better, but would still add up to about 40 MB in images alone - couldn't see much difference in quality between them. I will be importing them into Word 2003 and saving as HTML, Filtered, then opening in Sigil (which I’m still learning).

My question is (& I've searched a lot) what is the optimum PPI resolution for scans of b&w photographs to be imported into Sigil for display on both e-readers and in something like Calibre on a computer? What is the trade-off point between file size and quality in terms of resolution? Most of the ePubs that I've downloaded from places like archive.org are crawling with OCR errors from the Google scans and I've edited this text carefully for spelling (horror show of old & Latin plant names and tons of italics) and would like it to look nice but not be too huge. Also wondering about resolutions for colour scans too for future projects. (Best saved as JPEG's?)

I post a lot of cleaned-up text of (mostly) old gardening book excerpts on my blog (jimtheobscure.com) if anyone's interested – ps - wordpress.com doesn't support the upload of ePubs but I contacted Scribd support (looking for a place to park some) to inquire and they replied that they hope to be supporting them within the next quarter - now to work on Wordpress.

Thanks!

Jim:

You're asking the wrong question, and truthfully, in the wrong forum--the moderator should move this to another forum, where you'll get more answers than you will here. The question has really nothing whatsoever to do with Sigil, it's about best resolution trade-off for the myriad devices out there. Generally speaking, we (at my company) use 96ppi (actual, not print rez) which is what the iPad still displays, although proponents of its later screens will tell you to significantly up-rez your images (to take advantage of the retina display). BUT, as you've noted, with 150 images, it adds up pretty quickly, so you have to trade-off the higher-rez for usability. Many older e-readers will crash if you try to feed them a huge file, particularly if it's not broken into many smaller chapters. We'll even down-rez images to 75ppi, depending on the type of book. If the images are illustrative, and not the main driving force behind the book, we'll do 75 if pressed for space. For "coffee table" type ePUBs, we'll make the image higher in rez and larger in size (for the pinch-zoom on the Fire and iBooks).

For what you're doing, I suspect 96 would be fine.

For on-desktop reading, AFAIK, the reader of choice tends to be ADE over Calibre for non-geeks. Geeks like Calibre, but I don't love it for reading ePUBS, myself. I love it for other reasons (cataloging), but not for reading.

I hope that helps?

Hitch

[Perkin]

Originally Posted by Jim the Obscure

I did a test scan on my HP flatbed @ 300 ppi / 256 grayscale and got a 1.42 MB file

If you're saving as jpg, resave that 1.42MB file from another image program (Irfanview), that will likely reduce the filesize as the compression is usually less in scanning SW but has little difference in display quality.

[Ripplinger]

I usually scan at a higher dpi and not worry about the original image size so I have good starting images to work with. Then I run it through my regular graphics program once I determine what physical size it needs to be for the ebook and experiment with what format gives the smallest file size and still maintains good image quality. Usually gifs and pngs will give better quality than jpgs and lower file size.

I also use an old program that is probably now free, ULead SmartSaver Pro, that reduces the file size even further without quality loss.

Another trick I often do when I need to reduce the physical size of the image (what comes direct from the scan is always much too large for use within an ebook): Instead of using your graphic program's reduce size tool, try zooming the image out until it's the correct size you want, take a screenshot and crop to the image only. That quite often gives a much clearer image than the reduction tools even in Photoshop.

After that I still run it through SmartSaver Pro though to reduce the file size.

[pdurrant]

Originally Posted by Jim the Obscure

150 odd b&w photographs (+/- 3 1/2" x5 1/2") in it.

For ebooks you really need to consider pixel size of the final image, rather than scanning resolution of the scan.

I would scan at the best native scan resolution of the sensor of my scanner to get the best quality out of it. (In my case, the native resolution is 400dpi.)

Then you can perform appropriate adjustments and scaling to get to the final desired pixel size. This used to be no more than 600x800, but nowadays with high resolution eInk displays and even higher resolution tablets, I'd suggest going for something no less than 768x1024

For a 3.5"x5.5" original, that would need a minimum scan resolution of about 200dpi. If they're black and white, don't neglect to reduce them to greyscale images (saving about 2/3rds the space).

[DaleDe]

As pdurrant says ignore ppi when determining the picture size. Use pixels to determine the size you want for the image. For most eBook readers anything over about 1024 pixels wide is overkill for the purpose of displaying images. Most eBook readers will not let you zoom an image so you are restricted to viewing it with the number of pixels on the screen. Figure out the target devices and set the image sizes appropriately. Setting a bit bigger will allow for future high resolution devices but I would worry more about the sizes of the image that a super high resolution that the reader will never notice.

[Hitch]

Originally Posted by DaleDe

As pdurrant says ignore ppi when determining the picture size. Use pixels to determine the size you want for the image. For most eBook readers anything over about 1024 pixels wide is overkill for the purpose of displaying images. Most eBook readers will not let you zoom an image so you are restricted to viewing it with the number of pixels on the screen. Figure out the target devices and set the image sizes appropriately. Setting a bit bigger will allow for future high resolution devices but I would worry more about the sizes of the image that a super high resolution that the reader will never notice.

I'd be very interested to hear a discussion (seriously) on what the difference is, in this day and age, screen-wise, between ppi (particularly in a program like Photoshop, which uses actual pixels, not print output) and "pixels." In the old days, we had DPI for print, which did have an effect on the outcome resolution. Now, though, we are discussing images in ebooks, which by definition are being displayed on a screen. Obviously, the screen does not change when it encounters an image with a rez different than its own; the difference in "resolution" is simply how many pixels you put in the total area of the image, and thus, how much the eye-brain interprets, creates and extrapolates. How is that really distinguished--differentiated--rom PPI? How does one exist without the other?

I don't see how, in other words, when someone says, "use pixels," that that exists separate and apart from PPI. You calculate the image size you need based on the device, if you are making a book strictly for one device. If you're not, you're guesstimating, and at that point, you say, well, the average reading device is ~3.5" wide, and thus, this image will be somewhere between X and Y, X being (for example, 75ppi) one figure for width and Y being the greater if you're thinking 96 or higher. No?

Hitch

[Ripplinger]

I'm sure DaleDe was using "pixels" in reference to the width and height of the finished image, which is more important for spacing in epubs than dpi.

Such as a small logo often found in the published dates page can be as small as 40x40 pixels. I recently scanned an old book with 2 signatures included, one just an initial, and one the entire name, and they were 54x40 pixels and 253x40 pixels. A larger logo for the book was 150x110.

There's a never a set size you can predetermine while scanning to know what size will look best once you get the words around it in the ebook. Which is why I always scan in the highest res or dpi possible. That way I have a good clean image to play around with while I determine the proper size for the image and I never have to go back and rescan it again. And the only way to determine that is to try a size, put it in the ebook, load it in your reader and check it. What might look great on your PC in Calibre's viewer might look way too big on your reader. There's a lot of resizing usually to get it right.

It's all about the spacing, which is the number of pixels for width and height, once it gets into the ebook itself. Dpi doesn't matter at all in the end result.

[jbacelar]

Originally Posted by Ripplinger

Dpi doesn't matter at all in the end result.

That is so.

[pdurrant]

Basic HTML never actually defines the size of a display pixel. It's entirely up to the display software. Most assumes that a pixel is between 1/72" and 1/96".

With CSS it is possible to specify sizes in real units, but even there the accuracy is dependant on the rendering software.

So IMO it's best to look at the number of pixels in the screens of the devices where ebooks are usually displayed.

For full page images, that's currently around 600-800 pixels

[Jellby]

When specifying lengths in "pixels" in CSS, note that they may or may not correspond to actual screen pixels. In particular, the CSS2.1 spec says:

px: pixel units — 1px is equal to 0.75pt.

and since 1pt=1/72in, that assumes that all devices are 96ppi.

Of course, an image's (bitmap, not vector) dimensions are most meaningful in real pixels, it is only when setting the image size in CSS that this fixed-size pixel enters play.

[derangedhermit]

Originally Posted by Hitch

You calculate the image size you need based on the device, if you are making a book strictly for one device. If you're not, you're guesstimating, and at that point, you say, well, the average reading device is ~3.5" wide, and thus, this image will be somewhere between X and Y, X being (for example, 75ppi) one figure for width and Y being the greater if you're thinking 96 or higher. No?

IMHO, no.

I think an overview of the optimum process is this:

1. Scan at the native rez of the scanner. The idea here is that it is better to resample in another program that gives you more control over the process than using the scanner software.

2. Use an image processing program to crop and resample the image to the desired final size (in pixels). (More below on "desired final size")

3. Save in a format (GIF, PNG, JPEG, SVG) optimum for quality v. size tradeoff for that image and intended display devices.

On color and bits per pixel: if your target is current e-readers using electronic paper displays, then only 4-bit grayscale is needed, since they only support 16 levels of gray. Or if the source image is monochrome, there is no reason to use anything that takes more file space than 8-bit grayscale.

On image size: the target for resizing for optimum quality (without zoom in the reader) is the minimum available width and height for images across the target displays. This may not be the physical width and height in pixels, but something less. For example, if the two target devices both have physical 600wx800h displays, and one has an available display area of 590x780, and the other has a display area of 580wx790h, then the image should be resized to 580x780. This is to avoid resizing in any of the readers' software.

[Jim the Obscure]

Thanks for your answers. Due to my newbie status I'm still somewhat confused but at least now have some information that I can use to experiment. I've noticed that when I've got images in a MS Doc file that is then saved as "Web Page, Filtered" the size of the file (htm) seems to drop considerably from the size of the Doc file. I've opened both Jpegs in my browser (Firefox > New Tab > Open File) and, while image quality looks similar, the size of the images are different - the smaller one is smaller and the larger file is larger. I then started a Word Doc and inserted both scanned images into it - the quality seems very similar (the lower PPI scan has less contrast) but the size difference (on the screen) seems to differ less than when the Jpegs are opened with the browser, which is probably a result of being displayed within a smaller context..

I saved the Doc file and it is 1.7 MB - opened it again and saved it as "Web Page, Filtered" and the file size is 1.71 KB. This surprised me as the size of the final htm file seems to bear no relationship whatsoever to file sizes of the images that it contains; to go from 1.7 MB to 1.71 KB is, I think, an order of magnitude, so it leaves me with the impression that I may as well "go nuts" and scan at a higher resolution from within the scanner (assuming that I don't run into problems with the images becoming too large for an e-reader screen).

I opened the MS web page file in Sigil and saved it as an ePub and the file size is 80.2 KB (all file sizes are taken from file properties > Size. I opened Calibre and imported the ePub file, then opened it in the Calibre reader (my only reader) and, lo-and-behold, the difference in image size (on the screen) is negligible although the larger (scanned) image still shows better contrast.

So now I'm more confused; it seems as though scanning at a higher resolution has little bearing in terms of final file size in terms of MB's of either the web-page file or the ePub file (which was my initial concern, not wanting the ePub to balloon to an unmanageable size) and has negligible impact on the visible size of images in the e-book reader's screen - after all, one image was scanned at twice the resolution of the other. So for the time being, I'll assume that scanning at 300 PPI is acceptable unless someone can explain otherwise. I’ve uploaded the ePub file if you’d like to have a look at it.

A few comments were related to “target device” but a look at the Wikipedia page for e-book comparisons (http://en.wikipedia.org/wiki/Compari...e-book_readers) lists about 130 different models which makes for a rather diffused target. Beyond that, people will be reading e-pubs on smart phones and tablets and, especially with regard to tablets, with better and better (and bigger) displays, image quality starts to become more important than it is with dedicated e-readers.

My feeling is that the storage capacity on e-readers and tablets is something of a rip-off in a world where Gigabyte thumb drives are a dime-a-dozen and I suspect that these flash drives will increase dramatically in size once manufacturers have milked us sufficiently and one of them comes out with a device with reasonable storage capacities at a reasonable price. At that point, perhaps my concerns about larger ePub file size will be similar to worrying about what will fit on a floppy disk.

I looked for ULead SmartSaver but it is now part of Corel and sells for around $70.00 which is more than I would like to spend, although it seems as though it would be a helpful solution.

I do have Irfanview installed so I’ll experiment with that – it is worth my while to try things out before setting out to scan 150 images. I’ll also try saving as PNG to see if that helps rather than Jpegs.

Thanks again for your suggestions and please keep them coming if you feel you have something that would help to educate me.

[Ripplinger]

Take both of your images, open them in your graphic program of choice, and resave them as jpg. Note that there should be an options settings somewhere that lets you set the amount of compression for saving in jpg. I use Paint Shop Pro, and it's a slider that goes by percentages as an option in the save window, not sure where you'll find it in Irfanview. For normal usage I keep that set to 5% compression, so the images lose very little quality usually not visible at all, yet have some compression. When I resave your images at that 5% setting, the sizes come down to only 77kb and 84kb for the larger scanned image. Since it'll be an image for an ebook, you can probably adjust the compression up a bit higher, you'll have to experiment with it.

If I set my compression to 25% through Paint Shop Pro, it reduces the file size down to only 42kb, so that pretty much matches what SmartSaver Pro can do as far as file size, it just tends to keep a bit sharper image using SmartSaver Pro. You can probably go lower for that type of image also and compress it even further.

But the important thing is you should never use the image from a direct scan without running it through some graphic program first. That's where you can adjust the file size... both dimensions if you need to change that, as well as file data size so the ebook doesn't balloon up to a unnecessarily huge file size.

[Hitch]

Originally Posted by Ripplinger

I'm sure DaleDe was using "pixels" in reference to the width and height of the finished image, which is more important for spacing in epubs than dpi.

Such as a small logo often found in the published dates page can be as small as 40x40 pixels. I recently scanned an old book with 2 signatures included, one just an initial, and one the entire name, and they were 54x40 pixels and 253x40 pixels. A larger logo for the book was 150x110.

There's a never a set size you can predetermine while scanning to know what size will look best once you get the words around it in the ebook. Which is why I always scan in the highest res or dpi possible. That way I have a good clean image to play around with while I determine the proper size for the image and I never have to go back and rescan it again. And the only way to determine that is to try a size, put it in the ebook, load it in your reader and check it. What might look great on your PC in Calibre's viewer might look way too big on your reader. There's a lot of resizing usually to get it right.

It's all about the spacing, which is the number of pixels for width and height, once it gets into the ebook itself. Dpi doesn't matter at all in the end result.

Well, in this context, dpi doesn't matter at all. DPI only relates to printers, AFAIK, and of course, scanners (about which I, at least, wasn't really talking). I was very specifically talking about PPI, or pixels. To me, a saved image contains the pixels it contains--if it has, for example (just to make my life easy), 96x96px, on the iPad 1, it will display 1" x 1". On an older monitor, with a "rez" of 72dpi, you should, in theory, get a slightly larger image display. To match a specific device, you match the pixels of the screen resolution, whether that's 1024 by whatever, etc.

With regard to eBooks, I'm reasonably comfortable that somewhere between 72 and 96ppi tends to get you a credibly good image for most purposes.

@derangedhermit: Honestly, I disagree about the "optimum" process, and I think downsizing images so that no e-reader resizes it does not work. In an instance as narrow as the one you've cited, sure--that will work; but generally, it won't. If you're using an ePUB reader, it will resize it, and even older Kindles will resize images (in an attempt to fill the screen) unless you expressly set the height and width of the image in hard pixels. Hell, it will get resized if you're using an i-anything and rotate the device. What you're suggesting only works if you're making books for yourself, or have finite control over what devices a book will be read upon. Given that those of us making them commercially have zero control, the safer assumption is that people will see them on larger devices, so that when the image is reiszed, it's resized into a smaller space, not enlarged into a space it doesn't really have the size or rez to fill well.

While some images definitely benefit from additional rez and format (e.g, pngs), many don't, and people waste size on over-rezzing images, particularly if they're driving for i-devices.

This whole discussion reminds me of High School (back when Dinos walked the earth). In geometry, my long-suffering teacher endeavored to get me to agree that a bunch of points--which didn't exist--constituted a line. Now, of course, I knew damn well what she meant, but...now we're having a conversation about what resolution is the best, when a pixel doesn't even have an actual dimension. Talk about baking your noodle. And, probably, grossly over-thinking something that, for the most part, doesn't need over-thinking. The average ebook cover of 600x800 will work just fine. Whether at 72 or 96. ;-)

@Jimtheobscure:

Make sure that when you are calculating the final size of the html file, you add the image folder size to the html file size. However, unless your images have tiny writing, or are line drawings, charts, etc., it's extremely unlikely that you need 300ppi images inside the eBook. It's not a bad idea to start out with that much rez--it gives you more pixels to work with (less space between pixels, in other words), but--and watch out now, this will be heresy if real image guys are reading this--you can probably safely batch convert those down to 96 and be fine. Save a ton of room in your ebook. (I'll get flogged for suggesting batch-conversion, but again: it depends on the images, and your experience. My Prod. Mgr., who is a photographer, faints when he hears me utter The Batch-Convert Words of Doom. )

Hitch