For some reason, Evince 2.28's rendering/scaling quality of images in PDFs is horrible. It was OK in previous versions. PDF files affected, jpeg and png images dragged into evince don't exhibit the behavior. poppler 0.12.0 (cairo) Sample file: http://go2.wordpress.com/?id=725X1342&site=doctormo.wordpress.com&url=http%3A%2F%2Fdivajutta.com%2Fdoctormo%2Fubunchu%2Fubunchu-episode-01.pdf Will attach screenshots.
Created attachment 31457 [details] screenshot 1
Created attachment 31458 [details] screenshot 2
Created attachment 31459 [details] screenshot 3
Created attachment 31460 [details] screenshot 4 (by johanbr)
This is actually a bug in previous versions of poppler because we were ignoring the Interplotae flag in Image dictionary. Current output is the right one even if it looks worse than before. Try opening the document with xpdf or acroread and the output will be exactly the same. See bug #9860. Thanks for reporting.
This is unsatisfactory. Just look at the gnome shell design document (http://www.gnome.org/~mccann/shell/design/GNOME_Shell-20091114.pdf on page 17), it's horrible. I initially thought it was because they used 10dpi images or something. I also tested making PDFs out of OOoImpress presentations; while Impress shows the images with decent quality, Evince renders them without any smoothing, making them look like random 320x240 gif taken from the web. Then I did as suggested and actually opened the file in Adobe Reader ("acroread") 9.2 and the results were as Evince 2.26 used to present them (ie: they didn't look like shite :). Attaching some screenshots comparing Acroread 9.2 and Evince 2.28. This really looks like a bug. I don't think that lack of interpolation is a feature when 100% of the PDFs I have tried are affected and the "official" (acroread) implementation does not have the problem.
Created attachment 31472 [details] screenshot 5 - vs acroread
Created attachment 31473 [details] screenshot 6 - vs acroread
I guess this is because the filter used by acroread when it doesn't interpolate is better than the cairo one. These are the possibilities we have with cairo: CAIRO_FILTER_FAST: this is what we currently use when interpolation flag is not present. CAIRO_FILTER_NEAREST: I see mostly the same output than FAST Any other cairo filter CAIRO_FILTER_GOOD, CAIRO_FILTER_BEST or CAIRO_FILTER_BILINEAR would affect bug #9860. I still think it's a bug in the PDF producer, if you want to make sure images are rendered high quality, use the Interpolate flag as the PDF spec says.
Well, we can't expect all of the PDF-producing apps on the planet to fix themselves. Evince should be liberal about the documents it accepts, or have very good interpolation. I would also argue that interpolation is what 9 users out of 10 want. Evince is a viewer, not an editor. GIMP can afford pixel-perfectness. According to my calculations, the original image in bug #9860 must have had a resolution of 30x30 pixels or something like that. This allows us a simple workaround then. Such low resolution images must be scaled dozens of times to be displayed full-width on the screen. Thus, why not deactivate interpolation only when the stretching is over 400% or 800% ? GIMP takes this approach for zooming: interpolation for moderate levels of zooming, but no interpolation for high zoom levels. For what it's worth, to actually display the 30x30 image "as big as I saw it in the PDF", I had to scale it to *2300%* in GIMP! I suck at math, but I'm thinking there has to be way, based on zoom levels or image size or whatnot, to corner both scenarios. Currently, you're impairing all the users who don't work with pixel art/tiny non-vectorial graphs (which, I'd venture a guess, is the vast majority).
hmm, I like the idea, thank you very much for your comments, I'll try to find a solution based on that approach.
Created attachment 32749 [details] Scaled down text vs. xpdf This problem makes scanned text much harder to read than in xpdf. I'm happy to have a go at a patch myself if anyone can suggest where to get started.
Created attachment 33027 [details] test case - scanned scientific article
Articles that have been scanned like these *abound* in the scientific community. Imagine the pain of trying to read that. I have to use another pdf reader for these at the moment and I hate it, because I'd love to use evince like I used to.
(In reply to comment #14) > Articles that have been scanned like these *abound* in the scientific > community. Imagine the pain of trying to read that. I have to use another pdf > reader for these at the moment and I hate it, because I'd love to use evince > like I used to. > This is a different issue, see bug #5589, which is already fixed in git master.
I have a point of view half way between the two camps. I take pixel perfect artwork in PDF then export to (render as) TIFF @1200dpi for processing by other software. Acrobat does exact original on images in PDF which is great for most stuff but not when a customer sends a 300dpi () image in PDF especially if mixed with higher res and vector stuff. GIMP PDF import using poppler was great (before the fix), it interpolated low-res images for me whilst not disturbing higher res and vector graphics. So, I think that the interpolation of images (CAIRO_FILTER_BILINEAR) needs to be exposed as an option in libpoppler then in poppler glib/qt so that it can be a checkbox in GIMP PDF import for me and any other poppler using gui that wants the option.
FWIW, in my opinion, poppler should just always interpolate, regardless of what the Interpolate flags says. Reasons: - It is clearly what acroread does. - From a theoretical perspective, you can't upscale an image without interpolating. It doesn't make sense, because interpolation is what upscaling _is_. - By using CAIRO_FILTER_NEAREST, poppler is still interpolating, it is just using a poor interpolation filter. - The PDF spec says that Interpolation is turned off by default for performance reasons, but that is kinda bogus because a PDF file can't know the performance characteristics of an output device. - It also says that the interpolation filter is not defined even when it is turned on, so a PDF producer can't rely on this flag for any kind of accurate output.
(In reply to comment #17) > FWIW, in my opinion, poppler should just always interpolate, regardless of what > the Interpolate flags says. > > Reasons: > > - It is clearly what acroread does. really? With the test cases attached to bug #9860 acroread only shows smoothed graphic for the interpolate=true case. Maybe there's a configuration option in acroread to enable/disable it, I haven't found it though. > - From a theoretical perspective, you can't upscale an image without > interpolating. It doesn't make sense, because interpolation is what upscaling > _is_. > > - By using CAIRO_FILTER_NEAREST, poppler is still interpolating, it is just > using a poor interpolation filter. > > - The PDF spec says that Interpolation is turned off by default for performance > reasons, but that is kinda bogus because a PDF file can't know the performance > characteristics of an output device. > > - It also says that the interpolation filter is not defined even when it is > turned on, so a PDF producer can't rely on this flag for any kind of accurate > output. > Ok, so maybe we could try to find a smarter way to select the filter depending on the image resolution, as Jean-François proposed.
> > Reasons: > > > > - It is clearly what acroread does. > > really? With the test cases attached to bug #9860 acroread only shows smoothed > graphic for the interpolate=true case. Maybe there's a configuration option in > acroread to enable/disable it, I haven't found it though. Well, based on the screenshots in comment 7 and comment 8, it certainly looks like it. I'm not sure I understand what you meant by this comment: I guess this is because the filter used by acroread when it doesn't interpolate is better than the cairo one. since presumably "doesn't interpolate" just means NEAREST. (But feel free to ignore me. I am basically arguing that the spec is wrong, which I guess should require more evidence than I can provide).
(In reply to comment #19) > > > Reasons: > > > > > > - It is clearly what acroread does. > > > > really? With the test cases attached to bug #9860 acroread only shows smoothed > > graphic for the interpolate=true case. Maybe there's a configuration option in > > acroread to enable/disable it, I haven't found it though. > > Well, based on the screenshots in comment 7 and comment 8, it certainly looks > like it. But based on the test cases of bug #9860 it doesn't look like it ... > I'm not sure I understand what you meant by this comment: > > I guess this is because the filter used by acroread when it > doesn't interpolate is better than the cairo one. > > since presumably "doesn't interpolate" just means NEAREST. No, doesn't interpolate means FAST > (But feel free to ignore me. I am basically arguing that the spec is wrong, > which I guess should require more evidence than I can provide). > Maybe we should just ask Leonard what acroread actually does.
Created attachment 33595 [details] Comparison of acroread and evince for a pdf containing a graph Here's a good test case of a graph that is reduced to utter garbage by the nearest neighbor filter, while acroread handles it just fine. This is on Gentoo using poppler 0.12.3. So while there might be a test case where interpolation should be off, I'd argue that this is a clear point where the lack of interpolation makes poppler vastly inferior to acroread.
Created attachment 33596 [details] Test-case pdf for graph PDF containing the graph used for previous screenshot. The page of interest is 24.
I've just applied a patch to git master that should wotk for all the test cases, please test it.
Created attachment 33645 [details] Comparison of acroread and evince (with new patch) for a pdf containing a graph I've backported the patch to 0.12.3, since that's what's available on Gentoo. The patch definitely improves the appearance of the graph for me. However, the image quality is still clearly inferior to acroread. I'm not sure if this is due to a limitation of cairo or even because I'm not using git master.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/394.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.