Your comments to [Bug 408222]

[Tobias Deiminger]

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