04-29-2013, 09:11 PM | #16 |
Wizard
Posts: 1,613
Karma: 6718479
Join Date: Dec 2004
Location: Paradise (Key West, FL)
Device: Current:Surface Go & Kindle 3 - Retired: DellV8p, Clie UX50, ...
|
Don't ever use a JPEG or PNG that was saved from Photoshop using the "File>Save..." or "File>Save as ..." menu options, period. These are as "evil" as Word HTML files. Always use PS's "File>Save for Web and devices..." option which omits tons of PS specific extra editing info.
|
04-30-2013, 05:56 AM | #17 |
Digital Amanuensis
Posts: 727
Karma: 1446357
Join Date: Dec 2011
Location: Turin, Italy
Device: Several eReaders and tablets
|
For maximum compatibility with eReaders, my suggestion is to always "convert" the images using ImageMagick (i.e., "convert" in linux).
|
Advert | |
|
04-30-2013, 11:46 AM | #18 |
A Hairy Wizard
Posts: 3,095
Karma: 18727053
Join Date: Dec 2012
Location: Charleston, SC today
Device: iPhone 11/X/6/iPad 1,2,Air & Air Pro/Surface Pro/Kindle PW & Fire
|
|
04-30-2013, 12:08 PM | #19 | |
Resident Curmudgeon
Posts: 74,015
Karma: 129333114
Join Date: Nov 2006
Location: Roslindale, Massachusetts
Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3
|
Quote:
|
|
04-30-2013, 02:00 PM | #20 | |
Digital Amanuensis
Posts: 727
Karma: 1446357
Join Date: Dec 2011
Location: Turin, Italy
Device: Several eReaders and tablets
|
Quote:
Example: Code:
$ identify original.jpg original.jpg JPEG 900x1200 900x1200+0+0 8-bit DirectClass 439KB 0.010u 0:00.019 $ convert original.jpg clean.jpg $ identify clean.jpg clean.jpg JPEG 900x1200 900x1200+0+0 8-bit DirectClass 411KB 0.010u 0:00.000 |
|
Advert | |
|
04-30-2013, 02:27 PM | #21 |
A Hairy Wizard
Posts: 3,095
Karma: 18727053
Join Date: Dec 2012
Location: Charleston, SC today
Device: iPhone 11/X/6/iPad 1,2,Air & Air Pro/Surface Pro/Kindle PW & Fire
|
hmmm...that's interesting...I appreciate it!
It's amazing how much work I do to get all the bloat out of the html/CSS, but never realized it was in the image as well!! Thanks! |
04-30-2013, 02:33 PM | #22 |
Imperfect Perfectionist
Posts: 464
Karma: 724664
Join Date: Dec 2011
Location: Ølstykke, Denmark
Device: none
|
Erm ... I just tried the imagemagick convert jpg to jpg, and the file grew from 721 KB (saved with Photoshops save-to-web) to 756 KB ...
Any explanations? Regards, Kim |
04-30-2013, 03:38 PM | #23 | |
Grand Sorcerer
Posts: 11,470
Karma: 13095790
Join Date: Aug 2007
Location: Grass Valley, CA
Device: EB 1150, EZ Reader, Literati, iPad 2 & Air 2, iPhone 7
|
Quote:
Dale |
|
05-01-2013, 01:32 AM | #24 | |||
Curmudgeon
Posts: 629
Karma: 1623086
Join Date: Jan 2012
Device: iPad, iPhone, Nook Simple Touch
|
Quote:
Also, for some fonts, the calculated line height ends up being less than 1.2, and if you don't force it up to 1.2 either by redesigning the font or by setting line-height, you'll end up with different layout in different readers. (Oops.) So instead of saying "don't set it", I would say that if you are going to set the line height, never set it to less than 1.2 (many readers will ignore it if you do) or more than about 1.5. I would also add that the typical calculated line height for 99% of fonts is approximately 1.2, so if the font you're using requires a much larger spacing to be readable, you probably chose a lousy font. Quote:
First, you can't include uncompressed images in a valid EPUB book. The EPUB spec only allows you to include GIF, JPEG, PNG, and SVG images. The first three are compressed bitmap formats. The fourth is a vector graphics format, and if an SVG image contains any bitmapped content (in the context of EPUB), that bitmapped content must be in one of the first three formats, AFAIK. Second, some people read books on laptops and iPads that have retina displays. If, for example, you read a book on a 15" laptop with a retina display (2880×1800 resolution), you will see the difference if your cover image is significantly less than 1800 pixels tall. And if your content has text (which most covers do), reducing the JPEG compression quality below a certain point will result in ringing around the sharp edges. Using PNG avoids this, but then you have no real way to increase the compression; it is what it is. I recognize that older, slower readers might struggle with large images. If enough people are having trouble with this, you might use an image with a low-res image by default, then use media queries so that if the device has a higher resolution, that image goes away and a background-image property on the enclosing div provides a higher-resolution image, confident that any device that supports media queries also supports background-image.... That said, it is probably better to just ship with a future-proof high resolution copy and let people with ancient, slow devices either upgrade their hardware or shrink the cover image themselves. Quote:
Unless the original is a photo that is starting out as JPEG, don't do that. Always tell Photoshop or Illustrator or whatever to export a PNG or TIFF file so that you have a lossless starting point. Then convert to JPEG from there. |
|||
05-01-2013, 02:38 AM | #25 |
Wizard
Posts: 4,520
Karma: 121692313
Join Date: Oct 2009
Location: Heemskerk, NL
Device: PRS-T1, Kobo Touch, Kobo Aura
|
There actually is something like lossless jpeg. It generates huge files, but it does exist.
|
05-01-2013, 03:04 AM | #26 | ||||||
Wizard
Posts: 2,297
Karma: 12126329
Join Date: Jul 2012
Device: Kobo Forma, Nook
|
Quote:
Your typical image does have lots of worthless metadata called EXIF data, which can be easily tossed out to save some space: https://en.wikipedia.org/wiki/Exif This is somewhat what the "Save Image for Web" does in many programs. Quote:
Quote:
Quote:
Quote:
I usually keep the book covers as JPG. I shoot for is a MAX of ~300-400 KBs covers, with a 800x1200 resolution. Hopefully the next ebook format will be able to handle SVG much better, so that a lot of computer generated images (charts/tables/graphs) can auto-scale. Quote:
There are multiple PNG compression programs out there, I personally use ScriptPNG (There is also OptiPNG, PNGCrush, etc. etc.). This allows easy, drag and drop the files onto the batch file: http://css-ig.net/scriptpng Also, if you wanted to go the lossy PNG route, you could do things like drop from 24-bit encoding to 8-bit. I consider 800x1200 a "Mid-resolution" (works well on older devices I tested on, also works well/looks good on PC). You could always offer the much higher quality resolution cover directly on your site, for those of us who want to hunt it down and replace it ourselves. For B/W or Grayscale images though, I go PNG all the way. If it is something that is a few colors (such as a table/charts/graphs), I go with PNG. You can easily Index all the colors and make a VERY small file size (with much higher quality when compared to JPG). In the future, if better lossless compression algorithms come out, you could always just recompress your images to get better filesize, with zero loss in quality. Example: In February 2013, Google released the Zoplfi algorithm, which allows ~3-8% better PNG compression than previous algorithms: http://googledevelopers.blogspot.com...th-zopfli.html If I ever go back to fix up little typos, or make tiny changes to the EPUB, I make sure to recompress the PNG images in the books I previously worked on, and am able to save a lot more space (for example, this book that I just fixed a few nights ago, I saved ~42 KBs from recompression). Here is a sample Chart of different compressions I attached. #1: GIMP, saved as "85 quality" JPG. (LOSSLESS) #2: GIMP, saved as PNG (max compression) #3: Image #2 through ScriptPNG (~31% smaller) (LOSSY) #4: GIMP, saved as Indexed PNG (256 colors) #5: Image #4 thorugh ScriptPNG (~11% smaller) The JPG is ~130 KBs while the Indexed/ScriptPNG is 44.5 KBs (and looks WAY cleaner). You can really tell if you super zoom in on the solid color bars. In JPG, you can see the artifacting with different shades of red/blue/yellow, instead of being one solid color. Last edited by Tex2002ans; 05-01-2013 at 03:11 AM. |
||||||
05-01-2013, 04:31 AM | #27 |
Fanatic
Posts: 580
Karma: 810184
Join Date: Sep 2010
Location: Norway
Device: prs-t1, tablet, Nook Simple, assorted kindles, iPad
|
For ink/pencil b&w sketches I go for fifteen shades of grey. Looks good even on full-colour devices, and makes for smaller png-files than jpg.
|
05-01-2013, 05:35 AM | #28 | |
Digital Amanuensis
Posts: 727
Karma: 1446357
Join Date: Dec 2011
Location: Turin, Italy
Device: Several eReaders and tablets
|
Quote:
Clearly I agree that retaining high resolution, lossless resources and "convert" them to lossy resources is the way to go, and I am well aware that PNG works better for line-art, charts and graphs. |
|
05-01-2013, 07:32 AM | #29 |
Guru
Posts: 776
Karma: 2751519
Join Date: Jul 2010
Location: UK
Device: PW2, Nexus7
|
Man Eating Duck wrote:
Don't ever adjust line-height. Leave it at default. Readers will render a sensible default, many can override it if desired, but a silly value here can make it difficult to hit the correct value if you adjust the view. dgatwood wrote: This one, I disagree with. Here's why. Setting line height can make certain things possible. For example, drop caps. If you don't set the line height, it becomes highly dependent on the font, which means that changes to your font result in severe formatting breakage. Also, for some fonts, the calculated line height ends up being less than 1.2, and if you don't force it up to 1.2 either by redesigning the font or by setting line-height, you'll end up with different layout in different readers. (Oops.) So instead of saying "don't set it", I would say that if you are going to set the line height, never set it to less than 1.2 (many readers will ignore it if you do) or more than about 1.5. +1 I have also found it necessary to use a line-height of 1.4 for books with a lot of superscripting, otherwise readers render variable line spacing depending on whether a line has any superscripts or not and this uneveness looks a bit messy. Last edited by Agama; 05-01-2013 at 07:35 AM. |
05-01-2013, 09:07 AM | #30 | |
Addict
Posts: 254
Karma: 69786
Join Date: May 2006
Location: Oslo, Norway
Device: Kobo Aura, Sony PRS-650
|
Quote:
If your font is broken, I suppose you might correct that, but that sounds like a very badly wrought font which you maybe should avoid in the first place. I don't agree with the point made by Agama in reply to your post either. Even if you have occasional superscripts which can erroneously cause a few lines to be rendered with too much space on some readers (my prs-650 does this), that's no reason to style *every* line wrongly. No, this one definitely stays in the list |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Error: "can only concatenate list (not "unicode") to list" | bmuesse | Library Management | 2 | 01-11-2013 03:50 PM |
epub "padding left" to mobi "block quote" conversion issue | 1611mac | Conversion | 3 | 01-11-2012 02:10 PM |
Convertion error txt to epub "IndexError: list index out of range" | economix | Conversion | 6 | 12-25-2011 06:14 AM |
How to remove "Fully read" books from "Last Open" list? | pjeanetta | PocketBook | 4 | 12-08-2010 10:30 AM |
Suggestion: Don't set "color" tag in .epub css | McAlsop | Calibre | 16 | 06-17-2010 09:13 AM |