Am 05.06.2019 09:36 schrieb David Hurka:
Evince and Okular have to request pixmaps at some time, and have to
specify
the precise location of the pixmap. Maybe they have different
approaches to
use render_page() (or what wraps it), so the actually specified
location is a
fraction of a pixel off.
Then, render_page() would sample the scanned image at a slightly
different
offset, hitting or missing pixels differently, so the input for
filtering is
different.
Do you mean it like that (arbitrary guessed examples):
page.renderToImage( dpiX, dpiY, 0.1000, 0.1000, width, height, ...); //
looks better
page.renderToImage( dpiX, dpiY, 0.1001, 0.1001, width, height, ...); //
looks worse
At a first glance I don't see subpixel stuff when looking
at how Splash::drawImage fills Splash::bitmap, but I'm
far from understanding it completely.
So, Evince probably uses Cairo, which uses nearest neighbour in the
case of
the screenshot, and Okular probably uses Splash, which apparently does
not
only minification filtering.
Afaikt it's like this:
Qt5 frontend: In Splash::scaleImage, if an image is scaled down relative
to its embedded size, or scaled up by more than 400% it uses bresenham.
Else, if interpolation is explicitly wanted by the PDF image XObject,
or if image is scaled in the range of 100% .. 400%, it uses bilinear
interpolation.
Glib/cairo frontend: CairoOutputDev::getFilterForSurfac has same logic.
It chooses between CAIRO_FILTER_NEAREST (= nearest neighbor)
if scaled down, or scaled up by more than 400%. It use
CAIRO_FILTER_GOOD (= box filter when < 75%, bilinear otherwise) for
explicitly wanted interpolation or when scaled up in the range of 100%
.. 400%.
At least here I’m sure:
With nearest neighbour, the glyph edges are pixel edges. But with
magnification filtering, the pixel edges are widened to neighbouring
rendered
pixels, so the glyph edge becomes wider (smeared).
Guess glyphs are another story again. Both Qt5 and Glib frontend (via
cairo)
use freetype to render glyhps. But render settings may be different,
don't know how they differ.
Cheers, David
After all, I see there's a subtle difference in the images in bug
408222, but
honestly I couldn't even tell what looks better by only staring at it,
and
I would never have noticed a bug-worthy difference on my own.
Shall we proceed there at all? Do we have means to quantify rasterized
image quality?
Cheers Tobias