Re: [matplotlib-devel] MEP10: Modernizing the documentation
Michael Droettboom writes: > > > > Working with the documentation this past week has me a little > frustrated with the state of it. Enough to write a MEP. https://github.com/matplotlib/matplotlib/wiki/Mep10 > In particular, it would be nice to compile a list of concerns about > the docstrings and documentation layout so that we can address as > much as possible in a single pass. Also, let me know if there are > any relevant PRs and Issues. > In particular, I think PR #1032, as it is a large structural > reorganization, my dovetail well with the proposed reorganization of > the docs. > Mike The proposal looks great. I would like to comment on one issue that it touches, and which I found very uncomfortable to work with as a newcomer. I think that matplotlib style of using *args and **kwargs for delegation of arguments is a rather bad practice, which is hard to solve by just updating documentation. It breaks many rules of pep 20: it is implicit, since it is not allowing introspection, it is nested, since it always involves nested calls, it allows for alternative ways to do things, and I also don't think it's anyhow beautiful. Most of the things passed with *args, **kwargs can be done with an added function call, like: points = ax.scatter(data) points.update(*args, **kwargs) What would be the disadvantage of abolishing this practice? Anton -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] svg rasterization dpi patch
Hello,
i made a patch which would allow the svg backend to make
rasterized plots according to the dpi given in savefig.
I wanted this in order to have high-res scatter plots.
As you probably know it is hardcoded to 72 dpi right now.
The idea how to, came from the pdf backend. I mostly
copy pasted some code.
I also added a test for it. Some other tests now fail
the image comparison. It is nothing serious apparently.
Probably roundoff errors. Except interp_nearest_vs_none.
The result of which looks now exactly like the pdf which
it did not before.
Also, two other minor changes which i needed
- Compare_images failed for older numy versions. Simple fix ...
- A numpy.float32 variable got passed to the pdfRepr function in
backend_pdf.py. I changed this function to accept this type, too.
Cheers,
Michael
>From 309c93c2e71a7ef8d70deaf1f4d0c6adc77a0472 Mon Sep 17 00:00:00 2001
From: Michael Welter
Date: Sun, 26 Aug 2012 10:10:46 +0200
Subject: [PATCH 1/2] fixed: compare_images for older numpy versions. added:
backend_pdf allows numpy.float32 in pdfRepr
---
lib/matplotlib/backends/backend_pdf.py |2 +-
lib/matplotlib/testing/compare.py |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/matplotlib/backends/backend_pdf.py
b/lib/matplotlib/backends/backend_pdf.py
index 4cd8308..7acaddd 100644
--- a/lib/matplotlib/backends/backend_pdf.py
+++ b/lib/matplotlib/backends/backend_pdf.py
@@ -139,7 +139,7 @@ def pdfRepr(obj):
# Floats. PDF does not have exponential notation (1.0e-10) so we
# need to use %f with some precision. Perhaps the precision
# should adapt to the magnitude of the number?
-elif isinstance(obj, float):
+elif isinstance(obj, (float, np.float32)):
if not np.isfinite(obj):
raise ValueError("Can only output finite numbers in PDF")
r = ("%.10f" % obj).encode('ascii')
diff --git a/lib/matplotlib/testing/compare.py
b/lib/matplotlib/testing/compare.py
index abd4f4f..8563147 100644
--- a/lib/matplotlib/testing/compare.py
+++ b/lib/matplotlib/testing/compare.py
@@ -308,8 +308,8 @@ def compare_images( expected, actual, tol,
in_decorator=False ):
h1p = expectedImage[:,:,i]
h2p = actualImage[:,:,i]
- h1h = np.histogram(h1p, bins=bins)[0]
- h2h = np.histogram(h2p, bins=bins)[0]
+ h1h = np.histogram(h1p, bins=ns)[0]
+ h2h = np.histogram(h2p, bins=ns)[0]
rms += np.sum(np.power((h1h-h2h), 2))
--
1.7.4.1
>From cb1aa376c8aa0e7d977174b53fd72b7fd6badfb5 Mon Sep 17 00:00:00 2001
From: Michael Welter
Date: Sun, 26 Aug 2012 17:18:08 +0200
Subject: [PATCH 2/2] fix: dpi setting should work now for rasterization in svg
backend
---
lib/matplotlib/backends/backend_svg.py | 33 ---
lib/matplotlib/tests/test_image.py | 27 ++
2 files changed, 48 insertions(+), 12 deletions(-)
diff --git a/lib/matplotlib/backends/backend_svg.py
b/lib/matplotlib/backends/backend_svg.py
index 0b9b7ab..f1c709c 100644
--- a/lib/matplotlib/backends/backend_svg.py
+++ b/lib/matplotlib/backends/backend_svg.py
@@ -244,10 +244,11 @@ class RendererSVG(RendererBase):
FONT_SCALE = 100.0
fontd = maxdict(50)
-def __init__(self, width, height, svgwriter, basename=None):
+def __init__(self, width, height, image_dpi, svgwriter, basename=None):
self.width = width
self.height = height
self.writer = XMLWriter(svgwriter)
+self.image_dpi = image_dpi # the actual dpi we want to rasterize stuff
with
self._groupd = {}
if not rcParams['svg.image_inline']:
@@ -733,6 +734,11 @@ class RendererSVG(RendererBase):
def option_scale_image(self):
return True
+
+def get_image_magnification(self):
+return self.image_dpi/72.0
+
+
def draw_image(self, gc, x, y, im, dx=None, dy=None, transform=None):
attrib = {}
clipid = self._get_clip(gc)
@@ -755,6 +761,17 @@ class RendererSVG(RendererBase):
im.resize(numcols, numrows)
h,w = im.get_size_out()
+
+if dx is None:
+w = 72.0*w/self.image_dpi
+else:
+w = dx
+
+if dy is None:
+h = 72.0*h/self.image_dpi
+else:
+h = dy
+
oid = getattr(im, '_gid', None)
url = getattr(im, '_url', None)
if url is not None:
@@ -1113,25 +1130,17 @@ class FigureCanvasSVG(FigureCanvasBase):
def _print_svg(self, filename, svgwriter, fh_to_close=None, **kwargs):
try:
+image_dpi = kwargs.pop("dpi", 72)
self.figure.set_dpi(72.0)
width, height = self.figure.get_size_inches()
w, h = width*72, height*72
if rcParams['svg.image_noscale']:
-renderer = RendererSVG(w, h, svgwriter, filename)
+renderer = RendererSVG(w, h, image_dpi, svgwriter, filename)
else:
-
Re: [matplotlib-devel] MEP10: Modernizing the documentation
On 08/26/2012 05:33 AM, Anton Akhmerov wrote: > Michael Droettboom writes: > >> >> >> Working with the documentation this past week has me a little >> frustrated with the state of it. Enough to write a MEP. > https://github.com/matplotlib/matplotlib/wiki/Mep10 >> In particular, it would be nice to compile a list of concerns about >> the docstrings and documentation layout so that we can address as >> much as possible in a single pass. Also, let me know if there are >> any relevant PRs and Issues. >> In particular, I think PR #1032, as it is a large structural >> reorganization, my dovetail well with the proposed reorganization of >> the docs. >> Mike > The proposal looks great. I would like to comment on one issue that it > touches, > and which I found very uncomfortable to work with as a newcomer. I think that > matplotlib style of using *args and **kwargs for delegation of arguments is a > rather bad practice, which is hard to solve by just updating documentation. It > breaks many rules of pep 20: it is implicit, since it is not allowing > introspection, it is nested, since it always involves nested calls, it allows > for alternative ways to do things, and I also don't think it's anyhow > beautiful. > Most of the things passed with *args, **kwargs can be done with an added > function call, like: > > points = ax.scatter(data) > points.update(*args, **kwargs) > > What would be the disadvantage of abolishing this practice? > I understand the comments about the difficulty of introspection. The reason it works the way it does is so that additional parameters can be added to the artist layer without needing to update every single plotting function. A real world example of this is when hatching was added -- that feature only had to be added in one place and most artists were able to use it. In that sense, I think this approach is very beautiful in terms of code maintainability and extensibility. I'm willing to consider this if there's a better suggestion, but I think pushing what is currently a single function call for the user in to two is not going to fly. An alternative might be to have "style" objects that are passed to the plotting functions, and these style objects could grow new features over time. But that's going to break a lot of backward compatibility, of course. Mike -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Feature freeze progress
As of now, we have 14 issues on the 1.2.x milestone, plus 6 issues on the 1.2.x known bugs milestone. Since there's still a lot of work to be done on these before the rc1, I'm thinking I will continue to hold off on creating a 1.2.x branch. (Creating the branch would mean all of the pending PRs would have to be merged both to master and then manually pulled back to 1.2.x -- totally doable, or course, but an extra step.) Once we're down to only a handful, that might be a good time to create the branch. Are there any objections to continuing to hold off? The downside is we can't continue to merge non 1.2.x "blue sky" PRs in the meantime. Mike -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] svg rasterization dpi patch
On 2012/08/26 5:50 AM, Michael Welter wrote: > Hello, > > i made a patch which would allow the svg backend to make > rasterized plots according to the dpi given in savefig. > I wanted this in order to have high-res scatter plots. > As you probably know it is hardcoded to 72 dpi right now. > The idea how to, came from the pdf backend. I mostly > copy pasted some code. > > I also added a test for it. Some other tests now fail > the image comparison. It is nothing serious apparently. > Probably roundoff errors. Except interp_nearest_vs_none. > The result of which looks now exactly like the pdf which > it did not before. > > Also, two other minor changes which i needed > > - Compare_images failed for older numy versions. Simple fix ... > - A numpy.float32 variable got passed to the pdfRepr function in > backend_pdf.py. I changed this function to accept this type, too. > > > Cheers, > Michael Michael, Thank you, this sounds good. Although we can deal with it as a patch if necessary, it would be greatly preferable to see it as a github PR: http://matplotlib.sourceforge.net/devel/gitwash/git_development.html#git-development Are you willing to give that a try? Eric -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
