|
|||||||
 |
|
|
Thread Tools | Search this Thread |
11-12-2014, 12:16 PM
|
#1 |
|
Junior Member
 Posts: 3
Karma: 10
Join Date: Mar 2013
Device: iPad
|
Problems with downsampled Hi-def images on a standard-defintion screens
Hi All-
First time posting, long time reading posts here—tons of knowledge and insight  I work for a small publisher doing desktop publishing, creating graphics, and overseeing ebook conversion. We don't create our epubs in house (we send PDFs to conversion house), but since I have a background in HTML/CSS, I have the opportunity to work closely with our vendor to get the kind of output we want, standardize design, etc. One issue we initially had with the conversion house was image resolution. We proof our books on an iPad, which has a higher density display than a standard screen, and the display of images in the books was really poor. I did some research and came across a good article detailing a few methods for creating graphics for a high-density display (http://www.smashingmagazine.com/2012...ds-retina-web/). It's not ebook-specific advice, but applying a version of the HTML/CSS principle they lay out has given us really great looking images on the iPad. However, the hi-def images look crap in Adobe Digital Editions for desktop PC (1280x1024 screen--I know, not the most modern setup). The article warned that there'd be some downsampling and possible loss of quality on standard def screens, but the difference is really stark. Some images that have text in them are almost unreadable in ADE. What to do? Have any other posters wrestled with this issue? I want to future proof the books but I don't want to alienate desktop readers or make them think we have a crap product. Thanks in advance for any help you can offer. |
|
|
|
11-12-2014, 01:17 PM
|
#2 |
|
Wizard
 
Posts: 4,520
Karma: 121692313
Join Date: Oct 2009
Location: Heemskerk, NL
Device: PRS-T1, Kobo Touch, Kobo Aura
|
Well, the first thing you can do is stop sending PDF to your conversion house. That is the most crappy format to start from...
With regards to your image problem, that is just the current situation. Downsampling is really depending on the algorithms and for a lot of readers they are not great. Also, high resolution is fine, but there are millions of readers that do not support those resolutions. So, there is a problem there. Some publishers make two versions. One with a high resolution and one with a lower one. If you have full screen images, you could use a SVG wrapper. Downscaling of those are usually acceptable. |
|
|
|
|
11-12-2014, 01:37 PM
|
#3 | |
|
Well trained by Cats
Posts: 29,801
Karma: 54830978
Join Date: Aug 2009
Location: The Central Coast of California
Device: Kobo Libra2,Kobo Aura2v1, K4NT(Fixed: New Bat.), Galaxy Tab A
|
Quote:
 PDF is a Printed PAGE format |
|
|
|
|
11-12-2014, 02:32 PM
|
#4 | |
|
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 |
|
|
|
|
|
11-12-2014, 03:39 PM
|
#5 |
|
Junior Member
Posts: 3
Karma: 10
Join Date: Mar 2013
Device: iPad
|
So SVG wrapper affects how a file is downsampled? And the downsampling is smoother than if the size is just called out using html/CSS? What about support across readers/devices--are there known (mainstream) readers that definitely don't support SVG?
RE: PDF, I would guess that most presses send PDF for conversion. What format would you send instead? |
|
|
|
|
11-12-2014, 09:04 PM
|
#6 | |||||
|
Wizard
Posts: 2,297
Karma: 12126329
Join Date: Jul 2012
Device: Kobo Forma, Nook
|
Quote:
You will then have to either do the HTML/EPUB cleaning in-house, or find a conversion place (or independent contractor) that DOES handle InDesign/EPUB/HTML files directly. (Note: These conversion houses are most likely going to be more expensive than the dirt-cheap "Indian"/"Chinese" conversion companies, but you will pay slightly more for much higher quality). The closer you can work to the original source material, the better! Look, you ALREADY have the exact digital text... leading it through PDF is just going to create a whole host of extra problems. PDF is meant as a final OUTPUT format, it is just about THE WORST format to ever work backwards from. Workflow A (Correct):
Workflow B (Horrible, Inefficient, Waste):
It is maybe turning a "few hour" job of just cleaning code, into a "many hour" job. Quote:
For example, you don't want your original 3-5MB+ cover file in your EPUB. You might want to save that as a lower quality JPG. What typically happens is the method used to pull the image from the PDF -> EPUB probably degraded it. Again, this is one of the flaws with working as PDF as the INPUT format. You have the advantage, because you guys already have all the source files.  So what you would typically do, is hand over your original InDesign files, PLUS, hand over a ZIP file of all the original images. (This is how I handle InDesign -> EPUB conversions). Quote:
And as Toxaris said, it is really up to the resizing algorithms of the device. Quote:
My personal philosophy is to avoid text in images as much as possible, and try to pull as much of that into the HTML equivalent as possible. Where you HAVE to use it, save as PNG (AVOID JPG IN THAT CASE). If it is a vector chart/graph, already in InDesign/Illustrator, then it would probably be best to go back to the source material, and generate a "lower resolution" PNG directly from the vector files! Side Note: I wrote about advantages/disadvantages of HTML/Image Tables here: https://www.mobileread.com/forums/sho...d.php?t=223062 Quote:
The entire reason I got into this in the first place was being of EPUBs that were HORRIBLY converted. Tons of typos, tons of mistakes, horrible code, low-resolution images, etc. etc. Anyway, I work on non-fiction economics books mostly, and I do a lot of work doing PDF -> EPUB conversions (mostly from scanned books). When I work on newer books though, where we have the original InDesign files, that is DEFINITELY the way to go. Avoid PDF completely if you can. Side Note: This isn't getting into the discussion of perhaps having to change the entire "print book" workflow. Typically, the companies do a "print book FIRST" mentality, and then ebook is just a dirty side-thought. What has to start happening, is shifting to an "HTML/ebook FIRST" mentality. And start designing the books in InDesign in ways which will make it easier to generate both (consistent usage of styles/classes, etc. etc.). Last edited by Tex2002ans; 11-12-2014 at 09:35 PM. |
|||||
|
|
|
|
11-14-2014, 05:41 PM
|
#7 |
|
Junior Member
Posts: 3
Karma: 10
Join Date: Mar 2013
Device: iPad
|
You make some good points, but you make a bunch of incorrect statements about PDF. If you generate a PDF from InDesign, you get fully searchable, highlightable, copyable text--OCR is not in the picture at all. And if you export from inDesign with no downsampling, a 3-inch, 300dpi image in indesign is a 3-inch, 300dpi image in PDF--there's no loss there. And as I said, from the PDF source file, using CSS/html to squish 2x pixels into a given screen pixel space (a 400 px wide image gets screen pixel width="200" for example), we get high quality results on the ipad screen (I'm a little afraid of what is going on on the various HD Kindles, but I like the iPad better as a high-density screen standard.)
The issue I'm seeing, as far as I know I can tell is that by allowing the reader software (which is essentially a browser) to resize with HTML/CSS, you can end up tasking the software with rerendering a bunch of pixels into a really small space, so whereas I'm squishing a 400 px image into 200 screen pixels in iBooks and that looks good because the screen resolution is pretty high, it ends up looking pretty bad in ADE on an older monitor due to extreme downsampling and lower pixel per inch. The more I think about this, the more I'm realizing how old the monitors we use at work are. I think monitors even slightly older have better output and are hopefully not showing these problems to the reader. Also, I checked the same epub in ADE and Readium, and the downsampling in Readium is much smoother. It's a shame that the niceties that people have come to expect from the browsers have not hit all of the ereader platforms. Yet another reason we need to just be able to open the books in the damn browser and call it a day :/ |
|
|
|
|
11-14-2014, 07:45 PM
|
#8 | |||
|
Wizard
Posts: 2,297
Karma: 12126329
Join Date: Jul 2012
Device: Kobo Forma, Nook
|
Quote:
But get down into the nitty gritty, and things get UGLY. For example, ligatures might disappear in the text backend, characters with symbols 'ñ' might just show up as 'n'. (In the printed PDF though, you can see the little tilde + ligatures, but in the actual text backend, nope). Then a lot of metadata can be tossed out the window, things such as footnotes/sidebars/headers/footers/captions, might not be marked as such. The PDF knows the LOCATION of this text, and it knows exactly where to plop them when you are printing/displaying it in a PDF Reader, but it doesn't know WHAT they are (this is extremely important when making an ebook). You can pull the PLAIN TEXT out very easily (although, no formatting). But formatting is EXTREMELY important to the look of the book. Then if you look at the actual code, oh boy. Using something like xpdf or poppler might get you this: Spoiler:
That is just to display the words "Boer War Veteran Status Thomas returned Adelaide wounded decorated War Veteran". The way that PDF works is that it places words in EXACT positions. This is why you have things like "heuristics" in Calibre, to try to GUESS what goes where, and what goes in what logical order, what font that was supposed to be, was it supposed to be bold/italics, what is a paragraph. (Again, heuristics are going to get a lot of things wrong, lots of errors introduced). Any way you slice it, to pull out formatted text from a PDF, big waste of time (which is why in most cases, it is easier/faster to just re-OCR the entire thing). Perhaps you have more knowledge of tools though. If so, teach me, I would LOVE to be able to pull out data from PDFs much more efficiently! It would be AMAZING. And then get people to start doing the PDF workflow that actually allows this to be possible! And the original InDesign/Quark files ALREADY have all that nice formatting information just sitting in there, so if you export directly from there, that will be MUCH cleaner than trying to work backwards from the PDF. Similar thing with images from PDF, now I am saying, that not all PDF -> XYZ format WILL just pull out the image losslessly. Again, it all depends on how the conversion place you send it to does it. Perhaps they do it right, but in my experience, I have not seen that. Perhaps you have had better luck and sent it to a place that does it properly. Which is why I settled on the method, you just send me the original images separately, and I can work from that. No need to go through some hideous PDF middleman.  Quote:
Now, if you don't like the specific downsampling on the devices, then the only possible solution is to downsample them using an outside program, and inserting the lower resolution image in the file. For example, this downsampling talk reminded me a lot of what GrannyGrump does with high-quality line-drawings scanned from older books. For example: https://www.mobileread.com/forums/sho...15#post2682815 These specific types of drawings downscale HORRIBLY due to the downscaling algorithm on most devices. So the best bet would be to manually downscale using other tools, which might have more efficient/better algorithms for dealing with lines (Photoshop, GIMP, etc. etc.). So maybe you just pick a decent size resolution, like 1024x1024. Quote:
Again, any sort of examples would be helpful. I personally haven't seen any sorts of images that are TOO bad (besides images with text). Last edited by Tex2002ans; 11-14-2014 at 07:59 PM. |
|||
|
|
|
|
11-15-2014, 02:47 AM
|
#9 | |
|
Wizard
Posts: 4,520
Karma: 121692313
Join Date: Oct 2009
Location: Heemskerk, NL
Device: PRS-T1, Kobo Touch, Kobo Aura
|
Quote:
The example from Tex2002ans is even a nice example. Since PDF is defining where on the screen it must be, it can even put the text out of order in some cases. So, copying the text will then also be out of order. The only way you would know is by actually comparing the texts next to each other. No conversion house will do that due to the costs. |
|
|
|
|
|
| Tags |
| epub, image quality, ipad |
«
Previous Thread
|
Next Thread
»
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Again Problems with images | epublisher | ePub | 2 | 11-01-2012 06:14 AM |
| Using Class Variable in Def | Agama | Development | 1 | 08-21-2012 07:05 AM |
| Questions About def get_browser(self) | Finbar127 | Recipes | 6 | 02-24-2011 09:36 PM |
| Displaying images on e-ink screens | Ea | Workshop | 4 | 06-25-2008 10:18 AM |
| Stop squinting - eyestrain problems caused by small screens | Alexander Turcic | News | 9 | 04-27-2006 03:29 AM |
All times are GMT -4. The time now is 09:10 AM.