matplotlib-users Mailing List for matplotlib

Sorry, for the repeated emails/noise.

There is in fact an option "closed=False" for not closing the path:

/class /matplotlib.collections.PolyCollection(/verts/, /sizes=None/, 
/closed=True/, /**kwargs/)

However, "closed=False" has no effect.

Steve.

Setting the y-values of the start and end points to zero, (x[0],0.0) and
(x[-1],0.0), forces the return baseline path to be "well defined" at y=0,
allowing it to be overlain with a second line of a neutral colour.

However, this baseline also wipes a through adjacent slice data.


= FAIL.


Steve.


On 21/11/12 08:38, Stephen Gibson wrote:
> Unfortunately, as you state, "edgecolors='none'"  also wipes the
> (x,y) data line.
>
> I tried adding an additional "erase" zero line, with "edgecolors='none'"
> for each slice, but it seems the return path extends from
> (x[0],y[0])  to (x[-1],y[-1]) via some intermediate point.
>
> An additional blank (x[0], 0.0) to (x[-1], 0.0) does not overlap the 
> baseline.
>
> If I can determine the baseline path (coordinates) this procedure
> may work.
>
> Thanks, for your input.
>
> Steve.
>
> On 21/11/12 04:04, Benjamin Root wrote:
>>
>>
>> On Tue, Nov 20, 2012 at 12:55 AM, Stephen Gibson 
>> <Ste...@an... <mailto:Ste...@an...>> wrote:
>>
>>     I want to plot a series of (x,y) datasets similar to the
>>     polygon plot tutorial example (add_collection3d),
>>     but with a transparent facecolor and no baseline.
>>
>>
>>     Setting alpha=0.0 in the tutorial example (below)
>>     achieves the transparency, but the baseline remains.
>>
>>     Is there a way to remove the baseline?
>>
>>     Tks,
>>
>>     Steve.
>>
>>
>>     from mpl_toolkits.mplot3d import Axes3D
>>     from matplotlib.collections import PolyCollection
>>     from matplotlib.colors import colorConverter
>>     import matplotlib.pyplot as plt
>>     import numpy as np
>>     [cc('w',1.0),cc('w',1.0)
>>     fig = plt.figure()
>>     ax = fig.gca(projection='3d')
>>
>>     cc = lambda arg: colorConverter.to_rgba(arg, alpha=0.0)
>>
>>     xs = np.arange(0, 10, 0.4)
>>     verts = []
>>     zs = [0.0, 1.0, 2.0, 3.0]
>>     for z in zs:
>>          ys = np.random.rand(len(xs))
>>          ys[0], ys[-1] = 0, 0
>>          verts.append(list(zip(xs, ys)))
>>
>>     poly = PolyCollection(verts, facecolors = [cc('r'), cc('g'), cc('b'),
>>                                                 cc('y')])
>>     #poly.set_alpha(0.7)
>>     ax.add_collection3d(poly, zs=zs, zdir='y')
>>
>>     ax.set_xlabel('X')
>>     ax.set_xlim3d(0, 10)
>>     ax.set_ylabel('Y')
>>     ax.set_ylim3d(-1, 4)
>>     ax.set_zlabel('Z')
>>     ax.set_zlim3d(0, 1)
>>
>>
>> You should be able to set "edgecolors='none'" or as the same color as 
>> the facecolors in the constructor for PolyCollection to make it 
>> disappear.  Unfortunately, that would apply to the entire polygon, 
>> and not just the part at the base.
>>
>> Ben Root
>>
>
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Unfortunately, as you state, "edgecolors='none'"  also wipes the
(x,y) data line.

I tried adding an additional "erase" zero line, with "edgecolors='none'"
for each slice, but it seems the return path extends from
(x[0],y[0])  to (x[-1],y[-1]) via some intermediate point.

An additional blank (x[0], 0.0) to (x[-1], 0.0) does not overlap the 
baseline.

If I can determine the baseline path (coordinates) this procedure
may work.

Thanks, for your input.

Steve.

On 21/11/12 04:04, Benjamin Root wrote:
>
>
> On Tue, Nov 20, 2012 at 12:55 AM, Stephen Gibson 
> <Ste...@an... <mailto:Ste...@an...>> wrote:
>
>     I want to plot a series of (x,y) datasets similar to the
>     polygon plot tutorial example (add_collection3d),
>     but with a transparent facecolor and no baseline.
>
>
>     Setting alpha=0.0 in the tutorial example (below)
>     achieves the transparency, but the baseline remains.
>
>     Is there a way to remove the baseline?
>
>     Tks,
>
>     Steve.
>
>
>     from mpl_toolkits.mplot3d import Axes3D
>     from matplotlib.collections import PolyCollection
>     from matplotlib.colors import colorConverter
>     import matplotlib.pyplot as plt
>     import numpy as np
>
>     fig = plt.figure()
>     ax = fig.gca(projection='3d')
>
>     cc = lambda arg: colorConverter.to_rgba(arg, alpha=0.0)
>
>     xs = np.arange(0, 10, 0.4)
>     verts = []
>     zs = [0.0, 1.0, 2.0, 3.0]
>     for z in zs:
>          ys = np.random.rand(len(xs))
>          ys[0], ys[-1] = 0, 0
>          verts.append(list(zip(xs, ys)))
>
>     poly = PolyCollection(verts, facecolors = [cc('r'), cc('g'), cc('b'),
>                                                 cc('y')])
>     #poly.set_alpha(0.7)
>     ax.add_collection3d(poly, zs=zs, zdir='y')
>
>     ax.set_xlabel('X')
>     ax.set_xlim3d(0, 10)
>     ax.set_ylabel('Y')
>     ax.set_ylim3d(-1, 4)
>     ax.set_zlabel('Z')
>     ax.set_zlim3d(0, 1)
>
>
> You should be able to set "edgecolors='none'" or as the same color as 
> the facecolors in the constructor for PolyCollection to make it 
> disappear.  Unfortunately, that would apply to the entire polygon, and 
> not just the part at the base.
>
> Ben Root
>

On Tue, Nov 20, 2012 at 12:55 AM, Stephen Gibson
<Ste...@an...>wrote:

> I want to plot a series of (x,y) datasets similar to the
> polygon plot tutorial example (add_collection3d),
> but with a transparent facecolor and no baseline.
>
>
> Setting alpha=0.0 in the tutorial example (below)
> achieves the transparency, but the baseline remains.
>
> Is there a way to remove the baseline?
>
> Tks,
>
> Steve.
>
>
> from mpl_toolkits.mplot3d import Axes3D
> from matplotlib.collections import PolyCollection
> from matplotlib.colors import colorConverter
> import matplotlib.pyplot as plt
> import numpy as np
>
> fig = plt.figure()
> ax = fig.gca(projection='3d')
>
> cc = lambda arg: colorConverter.to_rgba(arg, alpha=0.0)
>
> xs = np.arange(0, 10, 0.4)
> verts = []
> zs = [0.0, 1.0, 2.0, 3.0]
> for z in zs:
>      ys = np.random.rand(len(xs))
>      ys[0], ys[-1] = 0, 0
>      verts.append(list(zip(xs, ys)))
>
> poly = PolyCollection(verts, facecolors = [cc('r'), cc('g'), cc('b'),
>                                             cc('y')])
> #poly.set_alpha(0.7)
> ax.add_collection3d(poly, zs=zs, zdir='y')
>
> ax.set_xlabel('X')
> ax.set_xlim3d(0, 10)
> ax.set_ylabel('Y')
> ax.set_ylim3d(-1, 4)
> ax.set_zlabel('Z')
> ax.set_zlim3d(0, 1)
>
>
You should be able to set "edgecolors='none'" or as the same color as the
facecolors in the constructor for PolyCollection to make it disappear.
Unfortunately, that would apply to the entire polygon, and not just the
part at the base.

Ben Root

python setup.py install won't cause that issue.

Also, easy_install doesn't cause the same issue.  OTOH, I'm not sure what
easy_install does in the case of deps.  If you use pip install --user it
will try (and fail) to remove old versions of deps from system.  I don't
know what easy_install does in this case.

I have also had issues where python setup.py install will install
everything into /usr/lib, while fedora packaging will try to install
arch-dep parts under e.g., /usr/lib64.  I have many times wound up with 2
versions of things that way.


On Tue, Nov 20, 2012 at 7:04 AM, Mathew Topper <mat...@ed...>wrote:

>  Neal, thanks for the warning. I found the thread of your discussion here
> actually:
>
> http://lists.fedoraproject.org/pipermail/devel/2012-February/162496.html
>
> It's very interesting. My feeling would be that a PyPI fedora repository
> would make the most sense - much like the current Fedora TexLive2012
> testing repository - but obviously this is no small job.
>
> "python setup.py install" doesn't have similar issues, I take it?
>
> Mat
>
>
> On 20/11/12 11:40, Neal Becker wrote:
>
> The problem is that pip packages something as a dir where easy_install
> packages as a file, or vice-versa.  Then when you update, cpio will fail
> (doesn't know how to replace a dir with a file, or vice-versa).  Next, the
> entire installation will abort!!!!  Leaving you with a mess.
>
>  I understand it's possible to manually then fix this mess using (some
> obscure) yum incantations, but I don't recall what.  Usually at this point
> I wipe the disc.
>
>  This has happened to me multiple times on multiple machines, and was
> discussed at some length on fedora-dev list maybe 1 year ago.  The basic
> message was that I shouldn't use pip to install into the system dirs.  But
> even using pip --user is not answer, because pip will see that e.g.,
> matplotlib wants a newer version of pytz, and will attempt to remove the
> system pytz (and fail and abort).
>
>  The only reliable approach is virtualenv.  Not really very satisfactory.
>
>
> On Tue, Nov 20, 2012 at 6:02 AM, Mathew Topper <mat...@ed...>wrote:
>
>>  Hi Neal,
>>
>> Is that due to conflicting package versions? I haven't suffered any
>> particular issues like this yet, but it seems to me that pip would be
>> improved if it interacted better with the environment it was in. How hard
>> would it be to get pip to interact with yum and apt, for instance, to get
>> valid binaries and/or devel files?
>>
>> I can't help thinking that Latex packaging is very similar, in that linux
>> distributions often struggle to keep up, which I guess is why TexLive
>> started.
>>
>> And then to complicate matters further, our sys admin said he didn't like
>> pip as he would rather generate RPMs, in order that there is not a lot of
>> work to do for system rebuilds in our labs. I found pypi2rpm, but that
>> looks pretty bleeding edge and I think I'm getting out of my depth as a
>> humble scientist.
>>
>> Mat
>>
>> On 19/11/12 12:59, Neal Becker wrote:
>>
>> Mathew Topper wrote:
>>
>>
>>  Hi,
>>
>> I'm interested to know why the pip package manager is not more widely
>> supported for installation of python packages like matplotlib?
>> Matplotlib seems to be particularly slowly updated in the Fedora
>> repositories, for example, so I often find that a source installation is
>> necessary. I know this isn't especially difficult for the experienced
>> user, but surely using something like pip would make this process for
>> accessible for all users of python packages, particularly those that do
>> not receive much attention from the big distribution maintainers? Yet,
>> pip doesn't get a mention on the installation documentation of
>> matplotlib or many other python packs.
>>
>> I would love to hear anyone's thoughts on this matter.
>>
>> Many Thanks,
>>
>> Mat
>>
>>  It is dangerous to use pip on fedora, it may result in your next attempt to
>> update the system failing horribly.
>>
>> If you use it, try to install with --user.  Unfortunately, this often won't work
>> because pip will then complain when attempting to remove a system version of
>> some dep.
>>
>>
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!http://p.sf.net/sfu/zoho_dev2dev_nov
>> _______________________________________________
>> Matplotlib-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>> --
>> Dr. Mathew Topper
>> Institute for Energy Systems
>> School of Engineering
>> The University of Edinburgh
>> Faraday Building
>> The King’s Buildings
>> Edinburgh EH9 3JL
>> Tel: +44 (0)131 650 5570 <%2B44%20%280%29131%20650%205570>
>> School fax: +44 (0)131 650 6554 <%2B44%20%280%29131%20650%206554>
>> mat...@ed...
>> http://www.see.ed.ac.uk
>>
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>>
>
> --
> Dr. Mathew Topper
> Institute for Energy Systems
> School of Engineering
> The University of Edinburgh
> Faraday Building
> The King’s Buildings
> Edinburgh EH9 3JL
> Tel: +44 (0)131 650 5570
> School fax: +44 (0)131 650 6554
> mat...@ed...
> http://www.see.ed.ac.uk
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

The problem is that pip packages something as a dir where easy_install
packages as a file, or vice-versa.  Then when you update, cpio will fail
(doesn't know how to replace a dir with a file, or vice-versa).  Next, the
entire installation will abort!!!!  Leaving you with a mess.

I understand it's possible to manually then fix this mess using (some
obscure) yum incantations, but I don't recall what.  Usually at this point
I wipe the disc.

This has happened to me multiple times on multiple machines, and was
discussed at some length on fedora-dev list maybe 1 year ago.  The basic
message was that I shouldn't use pip to install into the system dirs.  But
even using pip --user is not answer, because pip will see that e.g.,
matplotlib wants a newer version of pytz, and will attempt to remove the
system pytz (and fail and abort).

The only reliable approach is virtualenv.  Not really very satisfactory.


On Tue, Nov 20, 2012 at 6:02 AM, Mathew Topper <mat...@ed...>wrote:

>  Hi Neal,
>
> Is that due to conflicting package versions? I haven't suffered any
> particular issues like this yet, but it seems to me that pip would be
> improved if it interacted better with the environment it was in. How hard
> would it be to get pip to interact with yum and apt, for instance, to get
> valid binaries and/or devel files?
>
> I can't help thinking that Latex packaging is very similar, in that linux
> distributions often struggle to keep up, which I guess is why TexLive
> started.
>
> And then to complicate matters further, our sys admin said he didn't like
> pip as he would rather generate RPMs, in order that there is not a lot of
> work to do for system rebuilds in our labs. I found pypi2rpm, but that
> looks pretty bleeding edge and I think I'm getting out of my depth as a
> humble scientist.
>
> Mat
>
> On 19/11/12 12:59, Neal Becker wrote:
>
> Mathew Topper wrote:
>
>
>  Hi,
>
> I'm interested to know why the pip package manager is not more widely
> supported for installation of python packages like matplotlib?
> Matplotlib seems to be particularly slowly updated in the Fedora
> repositories, for example, so I often find that a source installation is
> necessary. I know this isn't especially difficult for the experienced
> user, but surely using something like pip would make this process for
> accessible for all users of python packages, particularly those that do
> not receive much attention from the big distribution maintainers? Yet,
> pip doesn't get a mention on the installation documentation of
> matplotlib or many other python packs.
>
> I would love to hear anyone's thoughts on this matter.
>
> Many Thanks,
>
> Mat
>
>  It is dangerous to use pip on fedora, it may result in your next attempt to
> update the system failing horribly.
>
> If you use it, try to install with --user.  Unfortunately, this often won't work
> because pip will then complain when attempting to remove a system version of
> some dep.
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Matplotlib-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
> --
> Dr. Mathew Topper
> Institute for Energy Systems
> School of Engineering
> The University of Edinburgh
> Faraday Building
> The King’s Buildings
> Edinburgh EH9 3JL
> Tel: +44 (0)131 650 5570
> School fax: +44 (0)131 650 6554
> mat...@ed...
> http://www.see.ed.ac.uk
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>

The original question was raised in a mpl ticket:
https://github.com/matplotlib/matplotlib/issues/1513

My original answer there (copied & pasted):

The bbox_inches='tight' option to savefig does some analysis on the artists
visible on your plot and figures out the minimum bounding box needed to fit
all of the artists on the plot. In doing so, *it will reduce the size of
the outputted image, rather than keeping the size and "zooming" in*. A
really simple example to show this (not using basemap):

>>> import matplotlib.pyplot as plt
>>> fig = plt.figure(figsize=(3, 4))
>>> ax = plt.axes([0.4, 0.4, 0.2, 0.2])
>>> ax.plot(range(10))
>>> plt.savefig('figsize_no_tight.png')
>>> plt.savefig('figsize_tight.png', bbox_inches='tight')


$> file figsize_*
figsize_no_tight.png: PNG image data, 300 x 400, 8-bit/color RGBA,
non-interlaced
figsize_tight.png:    PNG image data, 98 x 123, 8-bit/color RGBA, non-interlaced



*Matt has said that he doesn't think this addresses the issue *so anyone
else with any ideas, please chip in!
My suspicion is that what is being described is a combination of
bbox_inches="tight" and a snapping issue relating to the fixed aspect
(snapping here could be literally mpl snapping, or could simply be floating
point problems).

Hope someone else has some ideas about what is going on.

Cheers,

Phil








On 20 November 2012 00:25, <sa...@ns...> wrote:

>
> Hi there,
>
> I've boiled down a problem and while the following my look useless, I need
> to understand why matplotlib is behaving like it is.
>
> Below is code showing my issue.  I don't believe the issue is with the
> "bbox_inches='tight'", if you leave that off, my image is indeed, 800x1400,
> but the last row is a row of transparent pixels(on linux/not mac).  It's
> difficult to see unless you use the imagemagik command display.
>
> The basic problem is that when my data has an aspect ratio very close to
> 1.75, the image gets changed to one with an aspect of 1.74875.
>
> Correct figure info 8x14@100dpi = 800x1400 => 1.75 Aspect Ratio.
> Incorrect figure info => 800x1399 => 1.74875
>
> Data that works aspect ratio: 1.7499999999999998
> Data that fails aspect ratio: 1.7499999999999996
> --->   Srsly?!  -------------------------------^
>
> It would be great if someone could explain to me what's happening if this
> is indeed working as expected.  If it's not, it would be great if someone
> could fix it.
>
> Thanks in advance.
> Matt
>
>
> import matplotlib.pyplot as plt
>
> def create_image():
>     # I want an 800x1400 image (aspect = 1400/800 = 1.75.
>     fig = plt.figure(1, figsize=(8, 14), frameon=False, dpi=100)
>
>     # Use the whole figure and fill with a patch.
>     fig.add_axes([0, 0, 1, 1])
>     ax = plt.gca()
>     limb = ax.axesPatch
>     limb.set_facecolor('#6587ad')
>
>     # Set some bounds with Aspects very close to the desired aspect ratios.
>     x1 = 0.0
>     y1 = 0.0
>     x2 = 16.
>
>     # If you un-comment out this line (and comment the one below). I get
> an image I expect
>     # y2 = 27.999999999999994671   # produces 800 x 1400 image
>     # aspect = 1.7499999999999998 works
>
>     # Use this line and I get and image the wrong size (or with
> transparent pixels.)
>     y2 = 27.999999999999994670   # produces (wrong?) 800 x 1399 image
>     # aspect = 1.7499999999999996 Fails? wat?
>
>     corners = ((x1, y1), (x2, y2))
>     ax.update_datalim(corners)
>     ax.set_xlim((x1, x2))
>     ax.set_ylim((y1, y2))
>
>     ax.set_aspect('equal', anchor='C')
>     ax.set_xticks([])
>     ax.set_yticks([])
>
>     plt.savefig('rectangle.png', pad_inches=0.0, bbox_inches='tight')
>
>     # If you use this below, the file size is correct, but there is a
> single
>     # line transparent pixels along the bottom of the image
>
>     #  plt.savefig('rectangle.png', pad_inches=0.0)
>
>
> if __name__ == '__main__':
>     create_image()
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

I want to plot a series of (x,y) datasets similar to the
polygon plot tutorial example (add_collection3d),
but with a transparent facecolor and no baseline.


Setting alpha=0.0 in the tutorial example (below)
achieves the transparency, but the baseline remains.

Is there a way to remove the baseline?

Tks,

Steve.


from mpl_toolkits.mplot3d import Axes3D
from matplotlib.collections import PolyCollection
from matplotlib.colors import colorConverter
import matplotlib.pyplot as plt
import numpy as np

fig = plt.figure()
ax = fig.gca(projection='3d')

cc = lambda arg: colorConverter.to_rgba(arg, alpha=0.0)

xs = np.arange(0, 10, 0.4)
verts = []
zs = [0.0, 1.0, 2.0, 3.0]
for z in zs:
     ys = np.random.rand(len(xs))
     ys[0], ys[-1] = 0, 0
     verts.append(list(zip(xs, ys)))

poly = PolyCollection(verts, facecolors = [cc('r'), cc('g'), cc('b'),
                                            cc('y')])
#poly.set_alpha(0.7)
ax.add_collection3d(poly, zs=zs, zdir='y')

ax.set_xlabel('X')
ax.set_xlim3d(0, 10)
ax.set_ylabel('Y')
ax.set_ylim3d(-1, 4)
ax.set_zlabel('Z')
ax.set_zlim3d(0, 1)

Hi there, 

I've boiled down a problem and while the following my look useless, I need to understand why matplotlib is behaving like it is.

Below is code showing my issue.  I don't believe the issue is with the "bbox_inches='tight'", if you leave that off, my image is indeed, 800x1400, but the last row is a row of transparent pixels(on linux/not mac).  It's difficult to see unless you use the imagemagik command display.

The basic problem is that when my data has an aspect ratio very close to 1.75, the image gets changed to one with an aspect of 1.74875.

Correct figure info 8x14@100dpi = 800x1400 => 1.75 Aspect Ratio.
Incorrect figure info => 800x1399 => 1.74875

Data that works aspect ratio: 1.7499999999999998
Data that fails aspect ratio: 1.7499999999999996
--->   Srsly?!  -------------------------------^

It would be great if someone could explain to me what's happening if this is indeed working as expected.  If it's not, it would be great if someone could fix it.

Thanks in advance.
Matt


import matplotlib.pyplot as plt

def create_image():
    # I want an 800x1400 image (aspect = 1400/800 = 1.75.
    fig = plt.figure(1, figsize=(8, 14), frameon=False, dpi=100)

    # Use the whole figure and fill with a patch.
    fig.add_axes([0, 0, 1, 1])
    ax = plt.gca()
    limb = ax.axesPatch
    limb.set_facecolor('#6587ad')

    # Set some bounds with Aspects very close to the desired aspect ratios.
    x1 = 0.0
    y1 = 0.0
    x2 = 16.

    # If you un-comment out this line (and comment the one below). I get an image I expect
    # y2 = 27.999999999999994671   # produces 800 x 1400 image
    # aspect = 1.7499999999999998 works

    # Use this line and I get and image the wrong size (or with transparent pixels.)
    y2 = 27.999999999999994670   # produces (wrong?) 800 x 1399 image
    # aspect = 1.7499999999999996 Fails? wat?

    corners = ((x1, y1), (x2, y2))
    ax.update_datalim(corners)
    ax.set_xlim((x1, x2))
    ax.set_ylim((y1, y2))

    ax.set_aspect('equal', anchor='C')
    ax.set_xticks([])
    ax.set_yticks([])

    plt.savefig('rectangle.png', pad_inches=0.0, bbox_inches='tight')

    # If you use this below, the file size is correct, but there is a single
    # line transparent pixels along the bottom of the image

    #  plt.savefig('rectangle.png', pad_inches=0.0)


if __name__ == '__main__':
    create_image()