Repository navigation
multiple imshow in figure are rendered as single image in svg, causing problems when clipping images #7151
Description
Activity
- changed the title [-]multiple imshow in image are rendered as single image in svg, causing problems when clipping images[/-] [+]multiple imshow in figure are rendered as single image in svg, causing problems when clipping images[/+] on Sep 21, 2016
By default, we composite images for output to vector graphics formats. I
think if you set the rcParam "image.composite_image" to False, you'll get
what you want.On Wed, Sep 21, 2016 at 5:39 AM, Luca notifications@github.com wrote:
I am on matplotlib 1.5.1 (but i suppose this is not related with this
specific version)
This is probably a bug/limit of the svg export engine (maybe known?)when multiple calls to imshow are made in the same figure and then saved
in svg ALL the calls are joined into a single raster instead of having
multiple (e.g. grouped) images in the svg file.This make fail a simple test case like this. We call two times imshow to
position two images in the figure, then we clip the two images with two
different shapes. The problem is that in the svg the two imshow calls are
joined in an unique raster, thus the clips are simply not created at all in
the svg. Exporting each imshow() raster as a separated image in the svg,
each with their clips, would probably solve the problem.
Is it possible or is a known limit?if saved as png:
[image: test]
https://cloud.githubusercontent.com/assets/2051141/18705379/5899d41a-7fee-11e6-98e2-f23301c3ca99.pngand as svg:
[image: test_svg]
https://cloud.githubusercontent.com/assets/2051141/18705418/7c65874a-7fee-11e6-83ec-46ccd41fb464.pngCode for generating these pictures (for a notebook):
%pylab inline
import matplotlibpylab.rcParams['figure.figsize'] = (8, 8)
a = np.random.randn(100,100)
b = np.random.randn(100,100)im1 = imshow(a, extent = [0,1,0,1])
im2 = imshow(b, extent = [1.2,2.2,1.2,2.2])
xlim(0,2.2)
ylim(0,2.2)
from matplotlib.path import Path
verts1 = np.array([[0.5,0.5],[1,0.5],[1,1], [0,0.5], [0.5,0.5]])
path1 = Path(verts1)
path2 = Path(verts1 + np.array([1.1, 1.2]))import matplotlib.patches as patches
patch1 = patches.PathPatch(path1, facecolor=None, alpha=0)
gca().add_patch(patch1)patch2 = patches.PathPatch(path2, facecolor=None, alpha=0)
gca().add_patch(patch2)im1.set_clip_path(patch1)
im2.set_clip_path(patch2)savefig("test.png")
savefig("test.svg")many thanks for the wonderful work 👍
Luca
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#7151, or mute the thread
https://github.com/notifications/unsubscribe-auth/AARy-Fgi73j33fOJka7T32i2BnBygARKks5qsPtrgaJpZM4KCmHm
.cool!
This totally solves the problem!
Thank you a lot, maybe it should be the default behaviour given it causes a different output for svg and png?Many thanks and feel free to close the ticket!
Is this really not a bug? Compositing is an optimization, but it shouldn't break things in alternate formats.
Is this really not a bug? Compositing is an optimization, but it shouldn't break things in alternate formats.
I was wondering about this too.
And this is true not only for svg (tested pdf and it is affected).
- added this to the milestone on Sep 21, 2016
probably should detect if the artist have non-trivial clipping and if so, opt them out of the optimization.
The only place the compositing really helps you if you have many overlapping images, in the OPs case it might have been hurting (independent of the clipping bug!).
Also of note is that there was a significant image infrastructure rewrite, so we should check what happens with 2.x and/or master.
I think it goes way back, but I don't remember whether it was put in by JDH or by Mike.
https://github.com/matplotlib/matplotlib/blame/v0.91.2/lib/matplotlib/axes.py
If you use git blame and look for "composite" you will see that this logic in the draw method is old. It might have been put in because postscript doesn't handle alpha, so if we wanted composited images with alpha, we had to do it ourselves. This is still true, of course. At the time, it would also have been true for some other backends that we no longer support.In my opinion, given changing default behaviours is always risky, better documenting this might be a good starting point. My problem wasn't actually the behaviour of the svg compositing engine, but that I was not able to find the right switch to turn for solving the problem. Even if you google "image.composite_image" you see how much is difficult to get what it does. #2517 btw is the same.
An example in the cookbook or similar with the right keywords, pointing to this and other issues, will definitively help. Or even add better info into the doc (?)
Maybe the info are there but I had difficult times finding them...said that a default option which creates discrepancies between format outputs maybe should be investigated better
Thanks again everybody for this great library 👍
Luca
- modified the milestones: , on May 3, 2017
- modified the milestones: , on Oct 9, 2017
- added a commit that references this issue on Nov 6, 2020
I am on matplotlib 1.5.1 (but i suppose this is not related with this specific version)
This is probably a bug/limit of the svg export engine (maybe known?)
when multiple calls to imshow are made in the same figure and then saved in svg ALL the calls are joined into a single raster instead of having multiple (e.g. grouped) images in the svg file.
This make fail a simple test case like this. We call two times imshow to position two images in the figure, then we clip the two images with two different shapes. The problem is that in the svg the two imshow calls are joined in an unique raster, thus the clips are simply not created at all in the svg. Exporting each imshow() raster as a separated image in the svg, each with their clips, would probably solve the problem.
Is it possible or is a known limit?
if saved as png:
and as svg:
Code for generating these pictures (for a notebook):
many thanks for the wonderful work 👍
Luca