[Poppler-bugs] [Bug 68360] Add option to manually disable bilinear filtering

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=68360

--- Comment #16 from Charles Hyder <dr.hyder at gmail.com> ---
Meanwhile, let me elaborate a little on the topic of scaling. Here's a pic:

http://i.stack.imgur.com/JMpbI.png

-- this is just some pic I found on the web which is good for illustrating what
I want to say. Let's say that the image we're trying to display is a raster
image and in this pic it's the edgy b/w thing. Let's also assume that we want
to render it at a low resolution so that the pixel on the screen (or any other
device) is much larger than the pixel on of the image - let's say the pale gray
squares on the pic are the screen pixels. What are different modes of
rendering?
In what follows, I will basically retell this:

http://netpbm.sourceforge.net/doc/pamscale.html

-- Discrete Sampling: find the geometric center of each screen pixel and see,
within which of the image pixels this center falls, then render the (big)
screen pixel with the color of the thus found center image pixel.

-- Pixel Mixing: for each big screen pixel find the average intensity as
follows:

Intensity of the screen pixel = { (Sum over all image pixels that are inside
the screen pixel, even those that are partially inside) OF (intensity of the
image pixel) X (area of the image pixel that is inside the screen pixel) } /
(area of the screen pixel)

This formula, actually, works for any scale factor (i.e., linear size of the
screen pixel divided by the linear size of the image pixel). It produces
greyscale images when the scale factor is not integer (assuming we render a
bitonal image), but produces bitonal images for integer scale factors.

To quote the netpbm authors, "This method tends to replicate what the human eye
does as it moves closer to or further away from an image. It also tends to
replicate what the human eye sees, when far enough away to make the
pixelization disappear, if an image is not made of pixels and simply stretches
or shrinks. " 

In other words, this is the most natural method for scaling and thus the one
that, I think, should be used by default.

Again, this method will produce a bitonal image when a raster bitonal image at
resolution D embedded in PDF is rendered with resolution N x D, where N is
integer, and will produce a greyscale image otherwise.

N.B. The discussion of scaling above is equally applicable to color images. I'm
using bitonal example since it's easier to illustrate points with it. 

Interestingly, this "pixel mixing" logic can be applied to rendering vector
graphics as well. Obviously, it will almost always produce greyscale images
even when rendering black vector graphics (say, black fonts). Now, THIS is
where some people would like to have a choice: let's say we have a hybrid page
with black vector fonts and raster graphics. When using pixel mixing the fonts
will always produce greyscale. I would assume that there are users, myself
included, who would sometimes need the black fonts rendered as black, with no
filtering, i.e. using the "discrete sampling", as defined above. In fact, this
already is an option in pdftoppm: -aaVector. I can only guess that the new code
that you're referring to (the that is not executed in the rendering of my
example) is the one that renders vector graphics. There, in fact, several
methods can be used, see the netpbm page I gave link to, specifically the
"resampling" section. The reason to cosider something beyond the pixel mixing
is that "resampling" may produce anti-aliased results that appear sharper. But
again, this may be made an option.

Anyhow, it seems to me still that there's some bug. That is, I tend to think
that raster graphics is still rendered using pixel mixing, as it has always
been in the early versions of Poppler/Xpdf. What I think is causing unneeded
smoothing at scale=1 is some bug in the geometry calculations. This is a
slippery part, in fact: if we render a 300dpi image at, say, 301dpi then we'd
get greyscale with pixel mixing. Now, one can easily get 301dpi out of 300dpi
by a rounding error somewhere. Also, at scale=1 one has screen pixel size =
image pixel size. This means one may fit the two grids so that each image pixel
fits perfectly inside a screen pixel. That is, one may, but one may translate
one of the grids by 1/2 pixel as well and end up with intensity averaging. In
my experience with the Xpdf this never ever happened. Somehow, the guys who
wrote it were really trying to align the two grids, it seems ) Seriously,
however, the only sensible approach - given the fact that the position of an
image on the screen is arbitrary - probably was to check and see if the scale =
integer and switch off pixel mapping in those cases.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler-bugs/attachments/20130828/8a29b3cb/attachment.html>