Bug 25268 - image scaling is ugly / not antialiased in Evince 2.28
Summary: image scaling is ugly / not antialiased in Evince 2.28
Status: REOPENED
Alias: None
Product: poppler
Classification: Unclassified
Component: cairo backend (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-24 16:31 UTC by Jean-François Fortin Tam
Modified: 2010-03-12 07:40 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
screenshot 1 (585.22 KB, image/png)
2009-11-24 16:36 UTC, Jean-François Fortin Tam
Details
screenshot 2 (139.78 KB, image/png)
2009-11-24 16:36 UTC, Jean-François Fortin Tam
Details
screenshot 3 (243.81 KB, image/png)
2009-11-24 16:36 UTC, Jean-François Fortin Tam
Details
screenshot 4 (by johanbr) (848.61 KB, image/png)
2009-11-24 16:37 UTC, Jean-François Fortin Tam
Details
screenshot 5 - vs acroread (139.34 KB, image/png)
2009-11-25 07:24 UTC, Jean-François Fortin Tam
Details
screenshot 6 - vs acroread (366.66 KB, image/png)
2009-11-25 07:25 UTC, Jean-François Fortin Tam
Details
Scaled down text vs. xpdf (142.23 KB, image/png)
2010-01-21 00:09 UTC, Jonathan Newnham
Details
test case - scanned scientific article (802.46 KB, application/pdf)
2010-02-03 05:20 UTC, Jean-François Fortin Tam
Details
Comparison of acroread and evince for a pdf containing a graph (275.01 KB, image/png)
2010-02-26 09:55 UTC, Ryan May
Details
Test-case pdf for graph (967.81 KB, application/x-download)
2010-02-26 09:59 UTC, Ryan May
Details
Comparison of acroread and evince (with new patch) for a pdf containing a graph (266.90 KB, image/png)
2010-02-28 09:30 UTC, Ryan May
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-François Fortin Tam 2009-11-24 16:31:52 UTC
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.
Comment 1 Jean-François Fortin Tam 2009-11-24 16:36:12 UTC
Created attachment 31457 [details]
screenshot 1
Comment 2 Jean-François Fortin Tam 2009-11-24 16:36:27 UTC
Created attachment 31458 [details]
screenshot 2
Comment 3 Jean-François Fortin Tam 2009-11-24 16:36:48 UTC
Created attachment 31459 [details]
screenshot 3
Comment 4 Jean-François Fortin Tam 2009-11-24 16:37:21 UTC
Created attachment 31460 [details]
screenshot 4 (by johanbr)
Comment 5 Carlos Garcia Campos 2009-11-25 02:49:21 UTC
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. 
Comment 6 Jean-François Fortin Tam 2009-11-25 07:23:21 UTC
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.
Comment 7 Jean-François Fortin Tam 2009-11-25 07:24:38 UTC
Created attachment 31472 [details]
screenshot 5 - vs acroread
Comment 8 Jean-François Fortin Tam 2009-11-25 07:25:11 UTC
Created attachment 31473 [details]
screenshot 6 - vs acroread
Comment 9 Carlos Garcia Campos 2009-11-25 09:17:02 UTC
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. 
Comment 10 Jean-François Fortin Tam 2009-12-13 06:56:26 UTC
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).
Comment 11 Carlos Garcia Campos 2009-12-14 01:32:51 UTC
hmm, I like the idea, thank you very much for your comments, I'll try to find a solution based on that approach. 
Comment 12 Jonathan Newnham 2010-01-21 00:09:35 UTC
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.
Comment 13 Jean-François Fortin Tam 2010-02-03 05:20:19 UTC
Created attachment 33027 [details]
test case - scanned scientific article
Comment 14 Jean-François Fortin Tam 2010-02-03 05:21:46 UTC
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.
Comment 15 Carlos Garcia Campos 2010-02-03 05:29:03 UTC
(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. 
Comment 16 Jeremy Burton 2010-02-17 07:42:47 UTC
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.
Comment 17 Søren Sandmann Pedersen 2010-02-24 16:58:02 UTC
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.
Comment 18 Carlos Garcia Campos 2010-02-25 01:02:54 UTC
(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. 
Comment 19 Søren Sandmann Pedersen 2010-02-25 02:04:37 UTC
> > 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).
Comment 20 Carlos Garcia Campos 2010-02-25 02:15:02 UTC
(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. 
Comment 21 Ryan May 2010-02-26 09:55:14 UTC
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.
Comment 22 Ryan May 2010-02-26 09:59:53 UTC
Created attachment 33596 [details]
Test-case pdf for graph

PDF containing the graph used for previous screenshot.  The page of interest is 24.
Comment 23 Carlos Garcia Campos 2010-02-28 05:02:19 UTC
I've just applied a patch to git master that should wotk for all the test cases, please test it. 
Comment 24 Ryan May 2010-02-28 09:30:59 UTC
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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.