matplotlib-devel Mailing List for matplotlib (Page 2)

ceil doesn't work for me
I tried
figsize = [np.ceil(x / float(dpi)) for x in (arr.shape[1], arr.shape[0])]
and it fails on my second test when dpi=2 and i=25
result=26x26

Gary


On 9 April 2013 07:03, Michael Droettboom <md...@st...> wrote:

>  On 04/08/2013 02:38 PM, Benjamin Root wrote:
>
>
>
>
> On Sun, Apr 7, 2013 at 4:39 AM, gary ruben <gar...@gm...> wrote:
>
>>   Hi, I haven't looked at this list for a long time, so hi to all the
>> active devs.
>>  I just came across a problem in the image.py imsave() function.
>>
>> Problem:
>> At an ipython --pylab prompt, typing
>>
>> a = rand(29,29)
>> imsave('test.png', a)
>>
>>  incorrectly generates a 28x28 pixel image.
>> This happens for several array sizes (I initially saw it for 226x226).
>>
>> Line 1272 of image.py is
>> figsize = [x / float(dpi) for x in (arr.shape[1], arr.shape[0])]
>>
>> figsize interacts with the bounding box code somehow to create off-by-one
>> results for certain values of array shape.
>>
>>
>> Possible solution:
>> To fix this properly, I think the float cast should be removed and
>> integer-based math should be used, but I thought that since it was rounding
>> down in the cases I saw, a change to the following should fix this:
>>
>> figsize = [(x + 0.5) / float(dpi) for x in (arr.shape[1], arr.shape[0])]
>>
>>  and indeed this seems to work.
>>  To verify this, I ran the following brute-force test of all image sizes
>> up to 1024x1024 at some common dpi values:
>>
>> import matplotlib.pyplot as plt
>> import numpy as np
>> import os
>>
>> for dpi in [75, 100, 150, 300, 600, 1200]:
>>     for i in range(1,1025):
>>         print dpi, i,
>>         im = np.random.random((i,i))
>>         fname = 'test{:03d}.png'.format(i)
>>         plt.imsave(fname, im, dpi=dpi)
>>         im = plt.imread(fname)[:,:,0]
>>         print im.shape
>>         assert im.shape == (i, i)
>>         os.remove(fname)
>>
>>  and everything passed.
>>
>>  For completeness I also explored the dpi-space with these loop ranges
>> and the above loop body:
>>
>> for dpi in range(1, 101):
>>     for i in range(25, 36):
>>         ...
>>
>> and all was still well.
>>
>>
>>  Workaround:
>>  For the moment I've set dpi=1 in my call to imsave which effectively
>> reverts its behaviour to the original imsave code prior to the introduction
>> of the dpi parameter.
>>
>>  I think this testing is rigorous enough to make this change.
>>  If you agree, has anyone got time to change this, or shall I do a pull
>> request when I have time?
>>
>>  thanks,
>>  Gary
>>
>>
>  Good catch on this.  So you are saying that this bug was introduced
> relatively recently with the dpi kwarg?  I would suggest you make a PR so
> that this doesn't get lost (or at the very least file a bug report).  As
> for the fix itself, off the top of my head, wouldn't math.ceil() do what we
> want?  I prefer to be explicit in any intents rather than just simply (x +
> 0.5) / float(dpi).  As for the test, I would wonder if some sort of
> restricted version of that test might not be good to do?  I am thinking
> about 10 different sized plots and we wouldn't even need to have a the
> assert check or file removal test, as the image comparison framework would
> throw an exception when attempting to compare two images of different sizes
> (I think...).
>
>
> I think this bug goes back at least to hash 17192518, by me in May 2010.
> The suggested fix (probably using ceil to be more explicit as you suggest)
> seems right.
>
> As for the test, I think just `imsave` to a buffer, and loading that
> buffer back in with `imread` and asserting the sizes are the same should be
> sufficient.
>
> Mike
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

On 04/08/2013 02:38 PM, Benjamin Root wrote:
>
>
>
> On Sun, Apr 7, 2013 at 4:39 AM, gary ruben <gar...@gm... 
> <mailto:gar...@gm...>> wrote:
>
>     Hi, I haven't looked at this list for a long time, so hi to all
>     the active devs.
>     I just came across a problem in the image.py imsave() function.
>
>     Problem:
>     At an ipython --pylab prompt, typing
>
>     a = rand(29,29)
>     imsave('test.png', a)
>
>     incorrectly generates a 28x28 pixel image.
>     This happens for several array sizes (I initially saw it for 226x226).
>
>     Line 1272 of image.py is
>     figsize = [x / float(dpi) for x in (arr.shape[1], arr.shape[0])]
>
>     figsize interacts with the bounding box code somehow to create
>     off-by-one results for certain values of array shape.
>
>
>     Possible solution:
>     To fix this properly, I think the float cast should be removed and
>     integer-based math should be used, but I thought that since it was
>     rounding down in the cases I saw, a change to the following should
>     fix this:
>
>     figsize = [(x + 0.5) / float(dpi) for x in (arr.shape[1],
>     arr.shape[0])]
>
>     and indeed this seems to work.
>     To verify this, I ran the following brute-force test of all image
>     sizes up to 1024x1024 at some common dpi values:
>
>     import matplotlib.pyplot as plt
>     import numpy as np
>     import os
>
>     for dpi in [75, 100, 150, 300, 600, 1200]:
>         for i in range(1,1025):
>             print dpi, i,
>             im = np.random.random((i,i))
>             fname = 'test{:03d}.png'.format(i)
>             plt.imsave(fname, im, dpi=dpi)
>             im = plt.imread(fname)[:,:,0]
>             print im.shape
>             assert im.shape == (i, i)
>             os.remove(fname)
>
>     and everything passed.
>
>     For completeness I also explored the dpi-space with these loop
>     ranges and the above loop body:
>
>     for dpi in range(1, 101):
>         for i in range(25, 36):
>             ...
>
>     and all was still well.
>
>
>     Workaround:
>     For the moment I've set dpi=1 in my call to imsave which
>     effectively reverts its behaviour to the original imsave code
>     prior to the introduction of the dpi parameter.
>
>     I think this testing is rigorous enough to make this change.
>     If you agree, has anyone got time to change this, or shall I do a
>     pull request when I have time?
>
>     thanks,
>     Gary
>
>
> Good catch on this.  So you are saying that this bug was introduced 
> relatively recently with the dpi kwarg?  I would suggest you make a PR 
> so that this doesn't get lost (or at the very least file a bug 
> report).  As for the fix itself, off the top of my head, wouldn't 
> math.ceil() do what we want?  I prefer to be explicit in any intents 
> rather than just simply (x + 0.5) / float(dpi).  As for the test, I 
> would wonder if some sort of restricted version of that test might not 
> be good to do?  I am thinking about 10 different sized plots and we 
> wouldn't even need to have a the assert check or file removal test, as 
> the image comparison framework would throw an exception when 
> attempting to compare two images of different sizes (I think...).

I think this bug goes back at least to hash 17192518, by me in May 
2010.  The suggested fix (probably using ceil to be more explicit as you 
suggest) seems right.

As for the test, I think just `imsave` to a buffer, and loading that 
buffer back in with `imread` and asserting the sizes are the same should 
be sufficient.

Mike

On Sun, Apr 7, 2013 at 4:39 AM, gary ruben <gar...@gm...> wrote:

> Hi, I haven't looked at this list for a long time, so hi to all the active
> devs.
> I just came across a problem in the image.py imsave() function.
>
> Problem:
> At an ipython --pylab prompt, typing
>
> a = rand(29,29)
> imsave('test.png', a)
>
> incorrectly generates a 28x28 pixel image.
> This happens for several array sizes (I initially saw it for 226x226).
>
> Line 1272 of image.py is
> figsize = [x / float(dpi) for x in (arr.shape[1], arr.shape[0])]
>
> figsize interacts with the bounding box code somehow to create off-by-one
> results for certain values of array shape.
>
>
> Possible solution:
> To fix this properly, I think the float cast should be removed and
> integer-based math should be used, but I thought that since it was rounding
> down in the cases I saw, a change to the following should fix this:
>
> figsize = [(x + 0.5) / float(dpi) for x in (arr.shape[1], arr.shape[0])]
>
> and indeed this seems to work.
> To verify this, I ran the following brute-force test of all image sizes up
> to 1024x1024 at some common dpi values:
>
> import matplotlib.pyplot as plt
> import numpy as np
> import os
>
> for dpi in [75, 100, 150, 300, 600, 1200]:
>     for i in range(1,1025):
>         print dpi, i,
>         im = np.random.random((i,i))
>         fname = 'test{:03d}.png'.format(i)
>         plt.imsave(fname, im, dpi=dpi)
>         im = plt.imread(fname)[:,:,0]
>         print im.shape
>         assert im.shape == (i, i)
>         os.remove(fname)
>
> and everything passed.
>
> For completeness I also explored the dpi-space with these loop ranges and
> the above loop body:
>
> for dpi in range(1, 101):
>     for i in range(25, 36):
>         ...
>
> and all was still well.
>
>
> Workaround:
> For the moment I've set dpi=1 in my call to imsave which effectively
> reverts its behaviour to the original imsave code prior to the introduction
> of the dpi parameter.
>
> I think this testing is rigorous enough to make this change.
> If you agree, has anyone got time to change this, or shall I do a pull
> request when I have time?
>
> thanks,
> Gary
>
>
Good catch on this.  So you are saying that this bug was introduced
relatively recently with the dpi kwarg?  I would suggest you make a PR so
that this doesn't get lost (or at the very least file a bug report).  As
for the fix itself, off the top of my head, wouldn't math.ceil() do what we
want?  I prefer to be explicit in any intents rather than just simply (x +
0.5) / float(dpi).  As for the test, I would wonder if some sort of
restricted version of that test might not be good to do?  I am thinking
about 10 different sized plots and we wouldn't even need to have a the
assert check or file removal test, as the image comparison framework would
throw an exception when attempting to compare two images of different sizes
(I think...).

Cheers!
Ben Root

Hey there,

Just getting to this after a vacation.  I think I was stymied by the 
fact that the Fedora package for pycxx provides a pkg-config file, 
whereas, as you point out, it is not upstream.

I'll put my further comments on the issue.

Cheers,
Mike

On 04/05/2013 11:23 PM, Fernando Perez wrote:
> On Fri, Apr 5, 2013 at 2:51 PM, Julian Taylor
> <jta...@go...> wrote:
>
>> I filed an issue:
>> https://github.com/matplotlib/matplotlib/issues/1884
> Go figure, it was an actual bug! Well, thanks a lot for tracking it down :)
>
> I guess for now I'll just remove pycxx-dev from my system.
> Fortunately I don't need it for anything else.  But it means that
> right now, mpl can't be built on a system with the matplotlib
> build-deps loaded, which is a bummer.
>
> Cheers,
>
> f
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi, I haven't looked at this list for a long time, so hi to all the active
devs.
I just came across a problem in the image.py imsave() function.

Problem:
At an ipython --pylab prompt, typing

a = rand(29,29)
imsave('test.png', a)

incorrectly generates a 28x28 pixel image.
This happens for several array sizes (I initially saw it for 226x226).

Line 1272 of image.py is
figsize = [x / float(dpi) for x in (arr.shape[1], arr.shape[0])]

figsize interacts with the bounding box code somehow to create off-by-one
results for certain values of array shape.


Possible solution:
To fix this properly, I think the float cast should be removed and
integer-based math should be used, but I thought that since it was rounding
down in the cases I saw, a change to the following should fix this:

figsize = [(x + 0.5) / float(dpi) for x in (arr.shape[1], arr.shape[0])]

and indeed this seems to work.
To verify this, I ran the following brute-force test of all image sizes up
to 1024x1024 at some common dpi values:

import matplotlib.pyplot as plt
import numpy as np
import os

for dpi in [75, 100, 150, 300, 600, 1200]:
    for i in range(1,1025):
        print dpi, i,
        im = np.random.random((i,i))
        fname = 'test{:03d}.png'.format(i)
        plt.imsave(fname, im, dpi=dpi)
        im = plt.imread(fname)[:,:,0]
        print im.shape
        assert im.shape == (i, i)
        os.remove(fname)

and everything passed.

For completeness I also explored the dpi-space with these loop ranges and
the above loop body:

for dpi in range(1, 101):
    for i in range(25, 36):
        ...

and all was still well.


Workaround:
For the moment I've set dpi=1 in my call to imsave which effectively
reverts its behaviour to the original imsave code prior to the introduction
of the dpi parameter.

I think this testing is rigorous enough to make this change.
If you agree, has anyone got time to change this, or shall I do a pull
request when I have time?

thanks,
Gary

On Fri, Apr 5, 2013 at 2:51 PM, Julian Taylor
<jta...@go...> wrote:

> I filed an issue:
> https://github.com/matplotlib/matplotlib/issues/1884

Go figure, it was an actual bug! Well, thanks a lot for tracking it down :)

I guess for now I'll just remove pycxx-dev from my system.
Fortunately I don't need it for anything else.  But it means that
right now, mpl can't be built on a system with the matplotlib
build-deps loaded, which is a bummer.

Cheers,

f

On 05.04.2013 23:35, Julian Taylor wrote:
> On 05.04.2013 23:16, Fernando Perez wrote:
>> On Fri, Apr 5, 2013 at 1:49 PM, Julian Taylor
>> <jta...@go...> wrote:
>>
>>> strange, it isn't linked against libpng at all. I can't reproduce that
>>> on my Ubuntu machine with git head.
>>>
>>> Do you still have a buildlog?
>>> Maybe do a new build from a clean folder (and save the log).
>>
>> I just did a fully clean rebuild in a fresh clone, and the same thing
>> happens.  Build log here:
>>
>> http://pastebin.com/eCGbEvKb
>>
>> The only thing that jumpts at me is:
>>
>> Package PyCXX was not found in the pkg-config search path.
>> Perhaps you should add the directory containing `PyCXX.pc'
>> to the PKG_CONFIG_PATH environment variable
>> No package 'PyCXX' found
>>
>> which I don't understand, as pycxx is clearly installed:
>>
>> (master)longs[matplotlib]> apt-cache policy python-cxx
>> python-cxx:
>>   Installed: 6.2.4-1
>>   Candidate: 6.2.4-1
>>   Version table:
>>  *** 6.2.4-1 0
>>         500 http://ubuntu.cs.utah.edu/ubuntu/ quantal/universe amd64 Packages
>>         100 /var/lib/dpkg/status
>>
>>
>> Puzzled...
>>
> 
> 
> actually the presence of the PyCXX package seems to be the problem. If I
> have it installed it fails, if not it works. Looks like some weird bug
> in the build system.
> Why is it looking for a pkg-config file? PyCXX does not provide one.
> 
> I though system PyCXX could not be used because it needed unmerged patches?
> Btw. I could merge the patches into the Debian package if they are
> forwarded to me.
> 

I filed an issue:
https://github.com/matplotlib/matplotlib/issues/1884

On 05.04.2013 23:16, Fernando Perez wrote:
> On Fri, Apr 5, 2013 at 1:49 PM, Julian Taylor
> <jta...@go...> wrote:
> 
>> strange, it isn't linked against libpng at all. I can't reproduce that
>> on my Ubuntu machine with git head.
>>
>> Do you still have a buildlog?
>> Maybe do a new build from a clean folder (and save the log).
> 
> I just did a fully clean rebuild in a fresh clone, and the same thing
> happens.  Build log here:
> 
> http://pastebin.com/eCGbEvKb
> 
> The only thing that jumpts at me is:
> 
> Package PyCXX was not found in the pkg-config search path.
> Perhaps you should add the directory containing `PyCXX.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'PyCXX' found
> 
> which I don't understand, as pycxx is clearly installed:
> 
> (master)longs[matplotlib]> apt-cache policy python-cxx
> python-cxx:
>   Installed: 6.2.4-1
>   Candidate: 6.2.4-1
>   Version table:
>  *** 6.2.4-1 0
>         500 http://ubuntu.cs.utah.edu/ubuntu/ quantal/universe amd64 Packages
>         100 /var/lib/dpkg/status
> 
> 
> Puzzled...
> 


actually the presence of the PyCXX package seems to be the problem. If I
have it installed it fails, if not it works. Looks like some weird bug
in the build system.
Why is it looking for a pkg-config file? PyCXX does not provide one.

I though system PyCXX could not be used because it needed unmerged patches?
Btw. I could merge the patches into the Debian package if they are
forwarded to me.

On Fri, Apr 5, 2013 at 1:49 PM, Julian Taylor
<jta...@go...> wrote:

> strange, it isn't linked against libpng at all. I can't reproduce that
> on my Ubuntu machine with git head.
>
> Do you still have a buildlog?
> Maybe do a new build from a clean folder (and save the log).

I just did a fully clean rebuild in a fresh clone, and the same thing
happens.  Build log here:

http://pastebin.com/eCGbEvKb

The only thing that jumpts at me is:

Package PyCXX was not found in the pkg-config search path.
Perhaps you should add the directory containing `PyCXX.pc'
to the PKG_CONFIG_PATH environment variable
No package 'PyCXX' found

which I don't understand, as pycxx is clearly installed:

(master)longs[matplotlib]> apt-cache policy python-cxx
python-cxx:
  Installed: 6.2.4-1
  Candidate: 6.2.4-1
  Version table:
 *** 6.2.4-1 0
        500 http://ubuntu.cs.utah.edu/ubuntu/ quantal/universe amd64 Packages
        100 /var/lib/dpkg/status


Puzzled...

f

On 05.04.2013 22:32, Fernando Perez wrote:
> On Fri, Apr 5, 2013 at 10:06 AM, Julian Taylor
> <jta...@go...> wrote:
>>
>> whats the output of:
>> ldd
>> /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so
>> apt-cache policy libpng12-dev
>>
>> the system libpng in ubuntu 12.10 does have this symbol defined, maybe
>> you are picking up some other installation.
> 
> Here's what I get:
> 
> longs[~]> ldd /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so
> linux-vdso.so.1 =>  (0x00007fff56dff000)
> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f97ecaeb000)
> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f97ec8d4000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f97ec6b7000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f97ec2f8000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f97ebffb000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f97ed04b000)
> 
> 
> longs[~]> apt-cache policy libpng12-dev
> libpng12-dev:
>   Installed: 1.2.49-1ubuntu1
>   Candidate: 1.2.49-1ubuntu1
>   Version table:
>  *** 1.2.49-1ubuntu1 0
>         500 http://ubuntu.cs.utah.edu/ubuntu/ quantal/main amd64 Packages
>         100 /var/lib/dpkg/status
> 
> 
> Thanks for any insights you may provide...
> 
> f
> 


strange, it isn't linked against libpng at all. I can't reproduce that
on my Ubuntu machine with git head.

Do you still have a buildlog?
Maybe do a new build from a clean folder (and save the log).

On Fri, Apr 5, 2013 at 10:06 AM, Julian Taylor
<jta...@go...> wrote:
>
> whats the output of:
> ldd
> /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so
> apt-cache policy libpng12-dev
>
> the system libpng in ubuntu 12.10 does have this symbol defined, maybe
> you are picking up some other installation.

Here's what I get:

longs[~]> ldd /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so
linux-vdso.so.1 =>  (0x00007fff56dff000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f97ecaeb000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f97ec8d4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f97ec6b7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f97ec2f8000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f97ebffb000)
/lib64/ld-linux-x86-64.so.2 (0x00007f97ed04b000)


longs[~]> apt-cache policy libpng12-dev
libpng12-dev:
  Installed: 1.2.49-1ubuntu1
  Candidate: 1.2.49-1ubuntu1
  Version table:
 *** 1.2.49-1ubuntu1 0
        500 http://ubuntu.cs.utah.edu/ubuntu/ quantal/main amd64 Packages
        100 /var/lib/dpkg/status


Thanks for any insights you may provide...

f

On 05.04.2013 07:37, Fernando Perez wrote:
> Well, I'm using the system libpng, which is what puzzles me: there
> should be no need for me to modify my LD_..., and I haven't done so in
> the past.  I'll have to dig into the build tomorrow to figure out
> exactly what's going on there...
> 

whats the output of:
ldd
/home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so
apt-cache policy libpng12-dev

the system libpng in ubuntu 12.10 does have this symbol defined, maybe
you are picking up some other installation.


> Will report back.
> 
> 
> On Thu, Apr 4, 2013 at 9:24 PM, Damon McDougall
> <dam...@gm... <mailto:dam...@gm...>> wrote:
> 
> 
> 
> 
>     On Thu, Apr 4, 2013 at 10:51 PM, Fernando Perez
>     <fpe...@gm... <mailto:fpe...@gm...>> wrote:
> 
>         Thanks, Damon, for this info.
> 
>         Based on this, I've tested now on another, different system with
>         the same version of linux and can't reproduce it either.  Very
>         odd, but it looks like something is amiss on my end, so let me
>         investigate further before anyone burns further cycles on the issue.
> 
>         Cheers,
> 
>         f
> 
> 
>         On Thu, Apr 4, 2013 at 8:06 PM, Damon McDougall
>         <dam...@gm... <mailto:dam...@gm...>>
>         wrote:
> 
>             On Thu, Apr 4, 2013 at 6:41 PM, Fernando Perez
>             <fpe...@gm... <mailto:fpe...@gm...>> wrote:
> 
>                 Hi folks,
> 
>                 I'm getting the following error from a clean build of
>                 master on an
>                 ubuntu 12.10 machine:
> 
>                 longs[junk]> python -c 'import matplotlib._png'
>                 Traceback (most recent call last):
>                   File "<string>", line 1, in <module>
>                 ImportError:
>                 /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so:
>                 undefined symbol: png_create_read_struct
> 
> 
>                 I hadn't seen anything like this recently, nor can I
>                 find similar
>                 reports, so I'm wondering if anyone knows what's going
>                 on, or if it's
>                 an error on my side.  I can try to bisect it but I
>                 figured I'd ask
>                 first in case it's obvious to someone else...
> 
>                 Cheers,
> 
>                 f
> 
> 
>             Hi Fernando,
> 
>             I can't recreate this on OS X with the current git master
>             branch, which is at 11e7ed.
> 
>             Best wishes,
>             Damon
> 
>             -- 
>             Damon McDougall
>             http://www.damon-is-a-geek.com
>             Institute for Computational Engineering Sciences
>             201 E. 24th St.
>             Stop C0200
>             The University of Texas at Austin
>             Austin, TX 78712-1229
> 
> 
> 
>     Any time, Fernando.
> 
>     Out of curiosity, is the png_create_read_struct a symbol from
>     libpng?  If so, try adding wherever your libpng lives to your
>     LD_LIBRARY_PATH and see what happens.
> 
>     Best wishes,
>     Damon
> 
>     -- 
>     Damon McDougall
>     http://www.damon-is-a-geek.com
>     Institute for Computational Engineering Sciences
>     201 E. 24th St.
>     Stop C0200
>     The University of Texas at Austin
>     Austin, TX 78712-1229
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire 
> the most talented Cisco Certified professionals. Visit the 
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> 
> 
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

I've had problems like this using a git-source matplotlib and macports. 
This usually happens after libpng is upgraded.

Turns out a 'python setup.py install ...' in matplotlib will not solve 
things until you manually delete the contents of the matplotlib build/ 
directory. After which new go at setup.py install will link to the new 
libpng library. 'make clean' will not do this for you (which is probably 
an oversight in the matplotlib Makefile). Don't know if this will help 
for linux.

M

On 4/5/13 1:37 AM, Fernando Perez wrote:
> Well, I'm using the system libpng, which is what puzzles me: there
> should be no need for me to modify my LD_..., and I haven't done so in
> the past.  I'll have to dig into the build tomorrow to figure out
> exactly what's going on there...
>
> Will report back.
>
>
> On Thu, Apr 4, 2013 at 9:24 PM, Damon McDougall
> <dam...@gm... <mailto:dam...@gm...>> wrote:
>
>
>
>
>     On Thu, Apr 4, 2013 at 10:51 PM, Fernando Perez
>     <fpe...@gm... <mailto:fpe...@gm...>> wrote:
>
>         Thanks, Damon, for this info.
>
>         Based on this, I've tested now on another, different system with
>         the same version of linux and can't reproduce it either.  Very
>         odd, but it looks like something is amiss on my end, so let me
>         investigate further before anyone burns further cycles on the issue.
>
>         Cheers,
>
>         f
>
>
>         On Thu, Apr 4, 2013 at 8:06 PM, Damon McDougall
>         <dam...@gm... <mailto:dam...@gm...>>
>         wrote:
>
>             On Thu, Apr 4, 2013 at 6:41 PM, Fernando Perez
>             <fpe...@gm... <mailto:fpe...@gm...>> wrote:
>
>                 Hi folks,
>
>                 I'm getting the following error from a clean build of
>                 master on an
>                 ubuntu 12.10 machine:
>
>                 longs[junk]> python -c 'import matplotlib._png'
>                 Traceback (most recent call last):
>                    File "<string>", line 1, in <module>
>                 ImportError:
>                 /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so:
>                 undefined symbol: png_create_read_struct
>
>
>                 I hadn't seen anything like this recently, nor can I
>                 find similar
>                 reports, so I'm wondering if anyone knows what's going
>                 on, or if it's
>                 an error on my side.  I can try to bisect it but I
>                 figured I'd ask
>                 first in case it's obvious to someone else...
>
>                 Cheers,
>
>                 f
>
>
>             Hi Fernando,
>
>             I can't recreate this on OS X with the current git master
>             branch, which is at 11e7ed.
>
>             Best wishes,
>             Damon
>
>             --
>             Damon McDougall
>             http://www.damon-is-a-geek.com
>             Institute for Computational Engineering Sciences
>             201 E. 24th St.
>             Stop C0200
>             The University of Texas at Austin
>             Austin, TX 78712-1229
>
>
>
>     Any time, Fernando.
>
>     Out of curiosity, is the png_create_read_struct a symbol from
>     libpng?  If so, try adding wherever your libpng lives to your
>     LD_LIBRARY_PATH and see what happens.
>
>     Best wishes,
>     Damon
>
>     --
>     Damon McDougall
>     http://www.damon-is-a-geek.com
>     Institute for Computational Engineering Sciences
>     201 E. 24th St.
>     Stop C0200
>     The University of Texas at Austin
>     Austin, TX 78712-1229
>
>
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Well, I'm using the system libpng, which is what puzzles me: there should
be no need for me to modify my LD_..., and I haven't done so in the past.
 I'll have to dig into the build tomorrow to figure out exactly what's
going on there...

Will report back.


On Thu, Apr 4, 2013 at 9:24 PM, Damon McDougall
<dam...@gm...>wrote:

>
>
>
> On Thu, Apr 4, 2013 at 10:51 PM, Fernando Perez <fpe...@gm...>wrote:
>
>> Thanks, Damon, for this info.
>>
>> Based on this, I've tested now on another, different system with the same
>> version of linux and can't reproduce it either.  Very odd, but it looks
>> like something is amiss on my end, so let me investigate further before
>> anyone burns further cycles on the issue.
>>
>> Cheers,
>>
>> f
>>
>>
>> On Thu, Apr 4, 2013 at 8:06 PM, Damon McDougall <
>> dam...@gm...> wrote:
>>
>>> On Thu, Apr 4, 2013 at 6:41 PM, Fernando Perez <fpe...@gm...>wrote:
>>>
>>>> Hi folks,
>>>>
>>>> I'm getting the following error from a clean build of master on an
>>>> ubuntu 12.10 machine:
>>>>
>>>> longs[junk]> python -c 'import matplotlib._png'
>>>> Traceback (most recent call last):
>>>>   File "<string>", line 1, in <module>
>>>> ImportError:
>>>> /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so:
>>>> undefined symbol: png_create_read_struct
>>>>
>>>>
>>>> I hadn't seen anything like this recently, nor can I find similar
>>>> reports, so I'm wondering if anyone knows what's going on, or if it's
>>>> an error on my side.  I can try to bisect it but I figured I'd ask
>>>> first in case it's obvious to someone else...
>>>>
>>>> Cheers,
>>>>
>>>> f
>>>>
>>>
>>> Hi Fernando,
>>>
>>> I can't recreate this on OS X with the current git master branch, which
>>> is at 11e7ed.
>>>
>>> Best wishes,
>>> Damon
>>>
>>> --
>>> Damon McDougall
>>> http://www.damon-is-a-geek.com
>>> Institute for Computational Engineering Sciences
>>> 201 E. 24th St.
>>> Stop C0200
>>> The University of Texas at Austin
>>> Austin, TX 78712-1229
>>>
>>
>>
> Any time, Fernando.
>
> Out of curiosity, is the png_create_read_struct a symbol from libpng?  If
> so, try adding wherever your libpng lives to your LD_LIBRARY_PATH and see
> what happens.
>
> Best wishes,
> Damon
>
> --
> Damon McDougall
> http://www.damon-is-a-geek.com
> Institute for Computational Engineering Sciences
> 201 E. 24th St.
> Stop C0200
> The University of Texas at Austin
> Austin, TX 78712-1229
>

On Thu, Apr 4, 2013 at 10:51 PM, Fernando Perez <fpe...@gm...>wrote:

> Thanks, Damon, for this info.
>
> Based on this, I've tested now on another, different system with the same
> version of linux and can't reproduce it either.  Very odd, but it looks
> like something is amiss on my end, so let me investigate further before
> anyone burns further cycles on the issue.
>
> Cheers,
>
> f
>
>
> On Thu, Apr 4, 2013 at 8:06 PM, Damon McDougall <dam...@gm...
> > wrote:
>
>> On Thu, Apr 4, 2013 at 6:41 PM, Fernando Perez <fpe...@gm...>wrote:
>>
>>> Hi folks,
>>>
>>> I'm getting the following error from a clean build of master on an
>>> ubuntu 12.10 machine:
>>>
>>> longs[junk]> python -c 'import matplotlib._png'
>>> Traceback (most recent call last):
>>>   File "<string>", line 1, in <module>
>>> ImportError:
>>> /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so:
>>> undefined symbol: png_create_read_struct
>>>
>>>
>>> I hadn't seen anything like this recently, nor can I find similar
>>> reports, so I'm wondering if anyone knows what's going on, or if it's
>>> an error on my side.  I can try to bisect it but I figured I'd ask
>>> first in case it's obvious to someone else...
>>>
>>> Cheers,
>>>
>>> f
>>>
>>
>> Hi Fernando,
>>
>> I can't recreate this on OS X with the current git master branch, which
>> is at 11e7ed.
>>
>> Best wishes,
>> Damon
>>
>> --
>> Damon McDougall
>> http://www.damon-is-a-geek.com
>> Institute for Computational Engineering Sciences
>> 201 E. 24th St.
>> Stop C0200
>> The University of Texas at Austin
>> Austin, TX 78712-1229
>>
>
>
Any time, Fernando.

Out of curiosity, is the png_create_read_struct a symbol from libpng?  If
so, try adding wherever your libpng lives to your LD_LIBRARY_PATH and see
what happens.

Best wishes,
Damon

-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

Thanks, Damon, for this info.

Based on this, I've tested now on another, different system with the same
version of linux and can't reproduce it either.  Very odd, but it looks
like something is amiss on my end, so let me investigate further before
anyone burns further cycles on the issue.

Cheers,

f


On Thu, Apr 4, 2013 at 8:06 PM, Damon McDougall
<dam...@gm...>wrote:

> On Thu, Apr 4, 2013 at 6:41 PM, Fernando Perez <fpe...@gm...>wrote:
>
>> Hi folks,
>>
>> I'm getting the following error from a clean build of master on an
>> ubuntu 12.10 machine:
>>
>> longs[junk]> python -c 'import matplotlib._png'
>> Traceback (most recent call last):
>>   File "<string>", line 1, in <module>
>> ImportError:
>> /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so:
>> undefined symbol: png_create_read_struct
>>
>>
>> I hadn't seen anything like this recently, nor can I find similar
>> reports, so I'm wondering if anyone knows what's going on, or if it's
>> an error on my side.  I can try to bisect it but I figured I'd ask
>> first in case it's obvious to someone else...
>>
>> Cheers,
>>
>> f
>>
>
> Hi Fernando,
>
> I can't recreate this on OS X with the current git master branch, which is
> at 11e7ed.
>
> Best wishes,
> Damon
>
> --
> Damon McDougall
> http://www.damon-is-a-geek.com
> Institute for Computational Engineering Sciences
> 201 E. 24th St.
> Stop C0200
> The University of Texas at Austin
> Austin, TX 78712-1229
>

On Thu, Apr 4, 2013 at 6:41 PM, Fernando Perez <fpe...@gm...> wrote:

> Hi folks,
>
> I'm getting the following error from a clean build of master on an
> ubuntu 12.10 machine:
>
> longs[junk]> python -c 'import matplotlib._png'
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
> ImportError:
> /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so:
> undefined symbol: png_create_read_struct
>
>
> I hadn't seen anything like this recently, nor can I find similar
> reports, so I'm wondering if anyone knows what's going on, or if it's
> an error on my side.  I can try to bisect it but I figured I'd ask
> first in case it's obvious to someone else...
>
> Cheers,
>
> f
>

Hi Fernando,

I can't recreate this on OS X with the current git master branch, which is
at 11e7ed.

Best wishes,
Damon

-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

Hi folks,

I'm getting the following error from a clean build of master on an
ubuntu 12.10 machine:

longs[junk]> python -c 'import matplotlib._png'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so:
undefined symbol: png_create_read_struct


I hadn't seen anything like this recently, nor can I find similar
reports, so I'm wondering if anyone knows what's going on, or if it's
an error on my side.  I can try to bisect it but I figured I'd ask
first in case it's obvious to someone else...

Cheers,

f