"John Hunter" <jdh2358@...287...> writes:
I'll take a closer look at this later.
Thanks for looking into this Jouni -- please make sure to fix in the
branch and merge to the trunk, as described in
http://matplotlib.sourceforge.net/devel/coding_guide.html#using-svnmerge
I have a patch (attached) that fixes this case but breaks figimage. It
seems to me that the bug is in figimage, but with the current pdf
backend (which forces dpi=72 for all images) it happens to work right.
I'm a little wary of making this change on the maintenance branch
without also fixing figimage, and I don't really know how to fix
figimage.
The bug in the pdf backend is that it forces dpi=72, because in PDF 1.4
there are always 72 points to an inch. (In some later versions the scale
can be changed, but never mind that for now.) This is a problem because
sometimes people want to have their figures at a higher resolution. The
attached patch adds an image_dpi variable to the pdf backend and uses it
like the ps backend does: get_image_magnification() returns
image_dpi/72.0, and the width and height of images are divided by this
magnification factor.
The problem with figimage is that it doesn't use the magnification
factor at all, so when it calls draw_image, the image as drawn by the
backend is scaled wrong. See also the following comment in image.py
(class FigureImage):
2798 nnemec def make_image(self, magnification=1.0):
2904 efiring # had to introduce argument magnification to satisfy the unit test
2904 efiring # figimage_demo.py. I have no idea, how magnification should be used
5883 jdh2358 # within the function. It should be !=1.0 only for non-default DPI<
2904 efiring # settings in the PS backend, as introduced by patch #1562394
2904 efiring # Probably Nicholas Young should look over this code and see, how
2904 efiring # magnification should be handled correctly.
(When I say that this patch "breaks" figimage, I mean that before the
patch the pdf output of figimage_demo.py looks similar to the Agg
output, but after applying the patch it looks different.)
Ideas, anyone?
figdpi.patch (2.25 KB)
···
--
Jouni K. Sepp�nen
I am not sure what figimage should mean for a vector backend so I want
to hear from Perry who motivated the function. When I implemented it
on his original request, I understood it to be a raw pixel dump to the
canvas with no scaling, no interpolation, etc.... What does a pixel
dump to a canvas mean for a vector backend? I think we could define
something that was at least consistent, but we should probably hear
from Perry et al who are presumably using the function.
JDH
···
On Mon, Dec 15, 2008 at 2:21 PM, Jouni K. Seppänen <jks@...397...> wrote:
"John Hunter" <jdh2358@...287...> writes:
I'll take a closer look at this later.
Thanks for looking into this Jouni -- please make sure to fix in the
branch and merge to the trunk, as described in
http://matplotlib.sourceforge.net/devel/coding_guide.html#using-svnmerge
I have a patch (attached) that fixes this case but breaks figimage. It
seems to me that the bug is in figimage, but with the current pdf
backend (which forces dpi=72 for all images) it happens to work right.
I'm a little wary of making this change on the maintenance branch
without also fixing figimage, and I don't really know how to fix
figimage.
The bug in the pdf backend is that it forces dpi=72, because in PDF 1.4
there are always 72 points to an inch. (In some later versions the scale
can be changed, but never mind that for now.) This is a problem because
sometimes people want to have their figures at a higher resolution. The
attached patch adds an image_dpi variable to the pdf backend and uses it
like the ps backend does: get_image_magnification() returns
image_dpi/72.0, and the width and height of images are divided by this
magnification factor.
After sleeping on this overnight, I think the answer here is clear.
figimage is meant to be a pixel dump, so we should just treat a pixel
as a dot. When dpi is increased, the number of dots on the canvas
increases so the figimage should look smaller. I added your patch and
support for magnification to figimage -- the output looks right for
PNG, PDF and EPS -- svg still not. I haven't had a chance to look but
perhaps SVG does not utilize the magnification param. I'll check into
this later.
JDH
···
On Mon, Dec 15, 2008 at 2:44 PM, John Hunter <jdh2358@...287...> wrote:
I am not sure what figimage should mean for a vector backend so I want
to hear from Perry who motivated the function. When I implemented it
on his original request, I understood it to be a raw pixel dump to the
canvas with no scaling, no interpolation, etc.... What does a pixel
dump to a canvas mean for a vector backend? I think we could define
something that was at least consistent, but we should probably hear
from Perry et al who are presumably using the function.