close#3931 as well.

Might be related to#3057#1441 and#4584

Away from my computer at the moment. Will pushing all of this stuff down
into AGG break things for non-agg backends such as macosx and Cairo?
On Dec 22, 2015 5:19 PM, "Thomas A Caswell"notifications@github.com
wrote:

close#3931#3931 as
well.

Might be related to#3057
#3057#1441
#1441 and#4584
#4584

—
Reply to this email directly or view it on GitHub
#5718 (comment)
.

Away from my computer at the moment. Will pushing all of this stuff down into AGG break things for non-agg backends such as macosx and Cairo?

Our image interpolation is already done using the_image extension, which has always used Agg (but notbackend_agg) for the heavy lifting, for all backends.

The change here (and I admit it's confusing and I wasn't very clear) is that thebackend_agg used to do interpolation as well under certain circumstances (basically when interpolation='none' or there was a skew/rotation) rather than the_image extension. This was quite almost exactly the same code in_image and_backend_agg, except the latter supported rotation/skew. By moving rotation/skew into_image and then removing all image resampling from_backend_agg, the other raster backends (Cairo, OSX) now have the ability to rotate and skew images as well now and are on par with the features in the Agg backend in that regard for the first time.

Ah, that is much clearer! Sometimes I forget the distinction between the
use of agg and backend_agg.
On Dec 23, 2015 11:31 AM, "Michael Droettboom"notifications@github.com
wrote:

Away from my computer at the moment. Will pushing all of this stuff down
into AGG break things for non-agg backends such as macosx and Cairo?

Our image interpolation is already done using the _image extension, which
has always used Agg (but not backend_agg) for the heavy lifting, for all
backends.

The change here (and I admit it's confusing and I wasn't very clear) is
that the backend_agg used to do interpolation as well under certain
circumstances (basically when interpolation='none' of there was a
skew/rotation) rather than the _image extension. This was quite almost
exactly the same code in _image and _backend_agg, except the latter
supported rotation/skew. By moving rotation/skew into _image and then
removing all image resampling from _backend_agg, the other raster
backends (Cairo, OSX) now have the ability to rotate and skew images as
well now and are on par with the features in the Agg backend in that regard
for the first time.

—
Reply to this email directly or view it on GitHub
#5718 (comment)
.

@tacaswell

Might be related to#3057#1441 and#4584

An extra commit has been added here to fix#3057.

This PR fixes#1441 (though by happy accident)

#4584 doesn't hit the image code at all, so this is orthogonal to fixing that.

This is now passing on Travis, has some "What's New" entries, and is ready for final review.

@tacaswell: Thanks to the pointers to related issues. That was helpful for verifying some things outside of the existing test suite.

I'll give the C++ code a thorough read through tomorrow.
On Dec 30, 2015 5:40 PM, "Michael Droettboom"notifications@github.com
wrote:

This is now passing on Travis, has some "What's New" entries, and is ready
for final review.

@tacaswellhttps://github.com/tacaswell: Thanks to the pointers to
related issues. That was helpful for verifying some things outside of the
existing test suite.

—
Reply to this email directly or view it on GitHub
#5718 (comment)
.

master...matplotlib:6659dd704336b7575d8234b83a789531abd721ff

0335602...9097d0a

are links to the diffs excluding the svg files

examples/api/demo_affine_image.py picked up the execute bit for all, was that intentional?

in backend_svg it looks like the alpha value is only applied if the transform is notNone, is that correct?

docstring of class ScalarMappable.to_rgba needs some updating.

L1251 isfigure.py needs to be updated to match the same logic inAxes re if images can be compositied.

Would it be better to usedtype.kind (https://docs.scipy.org/doc/numpy-1.10.0/reference/generated/numpy.dtype.kind.html#numpy.dtype.kind) instead ofissubclass(A.dtype.type, np.floating) ?

I have a some what pathological example where colors not from the color map end up in the final image.

importnumpyasnpimportmatplotlib.pyplotaspltX,Y=np.ogrid[-1000:1000,-1000:100000]R=np.sin((X**2+Y**2)/1000)fig,ax=plt.subplots()ax.imshow(R,cmap='viridis',interpolation='nearest')ax.set_aspect('auto')ax.set_xlim((28860.457192461989,31279.898576044176))ax.set_ylim((1044.2529963498005,906.46842593439703))ax.set_xscale('log')plt.show()

To be fair, this is a couple layers of stacked Moire patterns as out here the grid isway under sampling the underlying function to begin with and then it is being way down sampled.

I also found that the initial draw is faster under the new code, but panning is snappier under the old code.

examples/api/demo_affine_image.py picked up the execute bit for all, was that intentional?

Nope. Will fix. My emacs is set up to helpfully apply the executable bit if there's is#! in the file. One could argue a file with a hashbang without the executable bit is degenerate. Probably best to just remove the hangbang to be consistent with most of the other examples.

in backend_svg it looks like the alpha value is only applied if the transform is not None, is that correct?

Yes. If there is a transform passed, it gets exactly the original data, so the alpha needs to be applied by the renderer. If there is no transform passed, the alpha has already been applied byimage.py. The reason for this is to properly support alpha-blending when images are pre-composited together. This did, however, illuminate one bug in the application of alpha inimage.py and the fact that PDF isn't currently doing this correctly. PS simply doesn't support alpha blending so not much we can do there.

docstring of class ScalarMappable.to_rgba needs some updating.

done.

L1251 is figure.py needs to be updated to match the same logic in Axes re if images can be compositied.

Not sure I follow. Isn't that already the case? Compositing happens if there's

• more than one image
• the backend supports it
• none of the images haveinterpolation == 'none'

It looks like it's the same in both places. (Could be refactored into a shared function, I suppose...)

Would it be better to use dtype.kind (https://docs.scipy.org/doc/numpy-1.10.0/reference/generated/numpy.dtype.kind.html#numpy.dtype.kind) instead of issubclass(A.dtype.type, np.floating) ?

I forgot about that... That's certainly more readable.

an update on my pathological case, if you zoom way in in the png it looks correct, the red is coming from something outside of mpl doing blending in RGB space.

Re L1251 Sorry, I was reading the first half of the diff and that was changed in the second half.

an update on my pathological case, if you zoom way in in the png it looks correct, the red is coming from something outside of mpl doing blending in RGB space.

What do you think that would be? -- "we control all the pixels" all the way down (at least for PNG). As far as I can tell, the "pinky" color is some sort of perceptual trick of the eyes when you have two very contrasting colors of only one pixel right next to each other (and personally, my display is 220dpi, so the pixels are quite small). If I zoom way in on the screenshot in the GIMP and use the eyedropper tool, however, I don't actually see any colors from outside the colormap. All this makes a very good stress test, though.

An optical illusions makes more sense. The display software (web browser / gimp) might be down-sampling to display, but Qt should not be.

If I take a screen shot of this page and zoom in on the (downsized) png gimp does show some red.

If I take a screen shot of this page and zoom in on the (downsized) png gimp does show some red.

I see. As you imply, I don't think there's anything we can do about that. As long as that doesn't happen fromsavefig or a screen shot directly taken from a GUI backend, we're fine.

You can download the image failures from the artifact tab of each not passing appveyor run. They include a nice html file which has the failing tests at the top.

->https://ci.appveyor.com/project/mdboom/matplotlib/build/1.0.832/job/cnc0brawn35inqpw/artifacts

I think this is working again, though Appveyor seems stopped up. Feel free to merge once passing.

Time for#6004...

This "is the test running too slow" test seems a bit finicky. AppVeyor is passing otherwise.

Merged despite the too-slow failure.

backported to v2.x as6595139

\o/