Just curious, at what zorder does the composed image end up at?

It ends up at the zorder of the first image in the list. You can seeFigure.draw orAxes.draw for where that actually happens. It's not perfect (and in fact is sort of a long-standing bug in zorder), but zorder is a mess in general in matplotlib, I don't think we'll fix it at this juncture ;)

maybe draw it at the average zorder? This is the time to break that sort of thing.

Alternatively, I was thinking that we should only composite images at thesame zorder. In the normal case (where the zorder didn't change from the default) that will be the case. In the case of tinkering with zorder, the user will really care about getting it right and we can either (1) create multiple composites for each zorder "grouping" or (2) just turn off compositing if the images are at different zorders.

There has got to be a clearer way to write this, but I am not sure of the numpy indexing rules are when mixing boolean indexes and integer indexes.

Looks identical torgba[:, :, 3][x < 0] = 0. No fancy indexing is required, and it is much faster than using where:

In [9]: xx = np.random.randn(1000, 1000, 4)In [10]: x = xx[:, :, 0]In [12]: timeit xx[:, :, 3][x < 0] = 0100 loops, best of 3: 2.08 ms per loopIn [13]: timeit xx[:, :, 3] = np.where(x < 0, 0, xx[:, :, 3])100 loops, best of 3: 9.65 ms per loop

Thanks -- I'll change that. Those crazy indexing tricks in Numpy always evade me.

Actually, it might make sense to keep it as_image because__all__ isn't used in this file. Therefore, we probably don't want to further pollute the namespace.

eh, people should not be bulk importing fromfigure....right?

Well, then__all__ would never be needed in python, right?

On Wed, Jan 6, 2016 at 1:53 PM, Thomas A Caswellnotifications@github.com
wrote:

In lib/matplotlib/figure.py
#5718 (comment):

@@ -32,7 +32,7 @@

from matplotlib.cbook import Stack, iterable

-from matplotlib import _image
+from matplotlib import image as mimage

eh, people should not be bulk importing from figure....right?

—
Reply to this email directly or view it on GitHub
https://github.com/matplotlib/matplotlib/pull/5718/files#r48993652.

I sometimes have thoughts that__all__ = [] should be added to all python files 😈

" lib/matplotlib/tests/baseline_images/test_backend_svg/noscale.png"
doesn't look right to me.

On Wed, Jan 6, 2016 at 2:11 PM, Thomas A Caswellnotifications@github.com
wrote:

In lib/matplotlib/figure.py
#5718 (comment):

@@ -32,7 +32,7 @@

from matplotlib.cbook import Stack, iterable

-from matplotlib import _image
+from matplotlib import image as mimage

I sometimes have thoughts thatall = [] should be added to all python
files [image: 😈]

—
Reply to this email directly or view it on GitHub
https://github.com/matplotlib/matplotlib/pull/5718/files#r48995898.

I think it's best to use ourmFOO convention here. I thought the import to a private name here was really confusing. We could go through at some point and make__all__ for the major modules with sane stuff, but I think that's a separate task that probably needs its own discussion about backward compatiblity/best practice etc.

" lib/matplotlib/tests/baseline_images/test_backend_svg/noscale.png" doesn't look right to me.

The change is due to the fact that the backend-specificsvg.image-noscale rcParam was removed in favor of the backend-agnosticinterpolation='none' feature and its default in rcParamimage.interpolation. Therefore, in the test, all three backends exhibit theinterpolation == 'none' behavior rather than just SVG. The svg-specific feature was removed because (a) it would require significant additional effort to maintain and (b) it's better to be backend-generic IMHO. I think the SVG-specific feature predates the support for the feature in all relevant backends.