matplotlib-users Mailing List for matplotlib (Page 17)

Hello,
So maybe a couple of images can help.
Using the code


#!/usr/bin/env python
"""
See pcolor_demo2 for a much faster way of generating pcolor plots
"""
from __future__ import division
from pylab import *

def func3(x,y):
   return (1- x/2 + x**5 + y**3)*exp(-x**2-y**2)


def func4(x,y):
   theta=arcsin(y)
   return cos(theta)


# make these smaller to increase the resolution
dx, dy = 0.05, 0.05

x = arange(-1.0, 1.0, dx)
y = arange(-1.0, 1.0, dy)
X,Y = meshgrid(x, y)

Z = func4(X, Y)

print "Z is, ", Z

ax = subplot(111)
im = imshow(Z, cmap=cm.jet)
#im.set_interpolation('nearest')
#im.set_interpolation('bicubic')
im.set_interpolation('bilinear')
#ax.set_image_extent(-3, 3, -3, 3)

show()

I can get the attached image.png, but what I am really after is
image2.png (the same quantity plotted on a circular domain!). How can
I achieve that (without using scissors on an existing image?).
This is what I meant from start.
Cheers

Lorenzo




2009/4/3 Jae-Joon Lee <lee...@gm...>:
> I'm afraid that I'm still confused and there seems to be not much
> thing I can help..
>
> You're considering a circle, but you already have your function in a
> cartesian coordinate. I'm not sure why you can't just plot in a
> cartesian coordinate? (in other words, what is wrong with your
> original script?)
>
> There is an "set_image_extent" call in your original script (although
> commented out). Maybe what you're trying to do is simply
>
>  im = imshow(Z, cmap=cm.jet, extent=(-3, 3, -3, 3))
>
> I'm not sure it would be relevant, but if you have your function or
> data in  (r, theta) coordinate, one simple way is just to use the
> polar axes with pcolormesh method.
>
>  n_theta, n_r = 100, 50
>  theta = np.linspace(0, 2*np.pi, n_theta+1)
>  r = np.linspace(0., 1., n_r + 1)
>  data = np.arange(0., n_theta*n_r).reshape(n_r, n_theta)
>  ax=subplot(1,1,1, projection="polar", aspect=1.)
>  ax.pcolormesh(theta, r, data)
>
>
>
> -JJ
>



-- 
Life is what happens to you while you're busy making other plans.

Eric Firing schrieb:
> Gregor Thalhammer wrote:
>> Tobias Wood
>> [...]
> [...]
>> I also noticed you used C++ constructs in your code. I think this is 
>> not recommended.
>
> Gregor,
>
> Would you elaborate, please, to satisfy my curiosity?  The original 
> file is C++, so use of C++ constructs in the patch would seem natural.
>
> Thank you.
>
> Eric
>
You are right. I was assuming the original file is C. Sorry for this 
stupid comment.

Gregor

I want to plot smooth line between data points (Excel like) and I can do it
with with 2 lines:
  a.. Original data points as circles, for instance: plot(x, y, 'bo')
  b.. Spline of these points as line: plot(xnew, ynew, 'b-')
The only problem with this is the legend - I get either 'o' or '---' but not
the required 'o-----o'.

Thanks for any suggestions,





*******************************************************************************************************

This e-mail message may contain confidential,and  privileged information or data that constitute proprietary information of CMT Medical Ltd. Any review or distribution by others is strictly prohibited. If you are not the intended recipient you are hereby notified that any use of this information or data by any other person is absolutely prohibited. If you are not the intended recipient, please delete all copies. Thank You. http://www.cmt.co.il

********************************************************************************************************





 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************

Tobias Wood wrote:
>> Tobias,
>>
>> I would like to apply your patch, but the test in
>> examples/tests/pngsuite fails. If you can submit a new patch where this
>> test passes, and, even better, if a small example 12-bit PNG of yours is
>> added to the test, I will apply it.
>>
>> Apart from that, I would echo Eric's thanks for the patch and
>> explanation.
>>
>> -Andrew
> 
> Hi Andrew and Eric,
> Thanks for the responses. I was unaware of the png test suite. I have
> attached a new diff that passes this test correctly. It originally
> failed because I was not handling greyscale images with an alpha
> channel, but it also brought to light several other issues with my code
> that I have fixed. I have changed the structure of the code
> significantly - the if/else struct has gone and a single loop returns
> the different image matrices. Although this is more concise, it no
> longer informs the user if it hits an unsupported image type.
> 
> Unfortunately I do not have a small test image available, all of ours
> are a minimum of 512x620. However the pngsuite page,
> http://libpng.org/pub/png/pngsuite.html, does have a set of suitable
> images labelled cs*n*.png. These have thrown up an interesting issue -
> to what maximum value should n-bit images be scaled when n is between 8
> and 16? The png spec and test images suggest it should be (2^n - 1).
> This means that higher bit depths give higher precision over the same
> intensity range and the same maximum value. However for my particular
> camera and software this would be wrong, as the CCD has a fixed 12-bit
> dynamic range and the lower png bit depths are only used to save file
> space. Hence at the moment I have set my software to scale to (2^16 - 1)
> for 8 < n < 16, but it follows the png spec for n < 8, so there are two
> contradictory behaviours and I am unsure which is the best approach.
> Personally I would prefer matplotlib to return raw integer values, not
> floats scaled between 0 and 1 and then I can apply the scaling myself,
> but I am aware that this is not particularly user friendly for anyone
> else. imshow() seems to handle integer values fine and correctly scales
> for display, provided that no alpha channel is present.
> 
> Should I post another message to the developer list about this to see
> what people think? I'd very much like to discuss this with someone who
> has a lot more experience of pngs than me.

Tobias,

I went ahead and applied your patch to the svn trunk and the 0.98.5
maintenance branch -- the aspect of having grayscale images come in as
2d arrays brings the functionality inline with the docstring to
imread(), so it qualifies as a bug fix. The rest is a nice feature
addition (the ability to read high dynamic range PNGs) that I think is
unlikely to break anything.

As for your questions, I think they can be addressed later. (I hope you
maintain your interest in this subject.) In particular, it would be good
to get Michael Droetboom's responses on this -- he's the resident PNG
expert. In terms of the 8 < n < 16 bit PNG issue, if they are to be
stored as integers, they will have to be stored in 16 bits, thus there
are two reasonable ways to do it -- left shifted and right shifted.
There are arguments for both. Thus, my opinion is that adding keyword
arguments to imread() that would modify the current behavior
appropriately would be the best solution. In other words, something like
 return_as_integer=False, integer_shift='left' would be the defaults.

Next time you submit patches, I do think it would be best to submit to
the mpl-dev email list.

Anyhow, thanks for the patch!

-Andrew

Gregor Thalhammer wrote:
> Tobias Wood
> [...]
[...]
> I also noticed you used C++ constructs in your code. I think this is not 
> recommended.

Gregor,

Would you elaborate, please, to satisfy my curiosity?  The original file 
is C++, so use of C++ constructs in the patch would seem natural.

Thank you.

Eric

Tobias Wood
[...]
> These have thrown up an interesting issue - to what maximum value 
> should n-bit images be scaled when n is between 8 and 16? The png spec 
> and test images suggest it should be (2^n - 1). This means that higher 
> bit depths give higher precision over the same intensity range and the 
> same maximum value. However for my particular camera and software this 
> would be wrong, as the CCD has a fixed 12-bit dynamic range and the 
> lower png bit depths are only used to save file space. Hence at the 
> moment I have set my software to scale to (2^16 - 1) for 8 < n < 16, 
> but it follows the png spec for n < 8, so there are two contradictory 
> behaviours and I am unsure which is the best approach. Personally I 
> would prefer matplotlib to return raw integer values, not floats 
> scaled between 0 and 1 and then I can apply the scaling myself, but I 
> am aware that this is not particularly user friendly for anyone else. 
> imshow() seems to handle integer values fine and correctly scales for 
> display, provided that no alpha channel is present.
In the past I worked on a similar problem, saving and loading images 
from a 14bit monochrome CCD camera to a PNG file. The PNG specification 
gives precise recommondations how to handle such a case: for saving an 
n-bit image which is not directly supported by the PNG specs the image 
needs to be scaled up to one of the supported bit depths, i.e. 1,2,4,8 
or 16. The original bit depth should be stored in the sBIT chunk to 
recover the original data. Explicitely, a 12 bit image needs to be 
scaled by a factor (2^16 - 1)/(2^12-1).
The approach I have chosen is: I have png_save_image(filename, img, 
significant_bits) that behaves as specified in the specs, i.e., 14bit 
images are scaled up to 16bit. For loading an image I use img, metadata 
= png_load_image(filename) that returns the downscaled image  as an 
integer array and a dict containing some metadata (which includes the 
original bit depth). I also noticed that neither pnglib, PIL nor matlab 
perform this downscaling. With this approach the loaded image data is 
identical to the original raw image. For further processing I typically 
normalize the image to the range 0 to 1.0, using the bit depth 
information. A float array is sufficiently precise, also for 16bit 
images. For your enhancements to imread, introducing a new keyword 
'normalized' would allow to switch between both these possibilies.As I 
understand I have essentially chosen the same approach like you, at 
least for bitdepths > 8. I didn't get the point what is different for 
bitdepth s<=8.

Another remark to your first posting: I didn't experience a problem with 
PIL to load 16bit PNG grayscale images.
I also noticed you used C++ constructs in your code. I think this is not 
recommended.

Gregor

On Sat, Apr 4, 2009 at 06:37, C M <cmp...@gm...> wrote:
> I am pretty happy with the default for how dates ticks
> are updated with zooming the plot with the navigation
> toolbar...until it gets down to the level of hours.
>
> Hours are by default displayed in a format like:
> "23:00:00 UTC".  How can I get it to display it in a
> more common way, such as "11:00 pm", or better,
> "11 pm, 3/15"?

something like:

# init figures
fig = figure()
ax = fig.add_subplot(111)
# plot the lines
ax.plot_date(...)
# x data (dates) formatter
ax.xaxis.set_major_formatter( DateFormatter('PUT YOUR FORMAT HERE') )

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

> Tobias,
>
> I would like to apply your patch, but the test in
> examples/tests/pngsuite fails. If you can submit a new patch where this
> test passes, and, even better, if a small example 12-bit PNG of yours is
> added to the test, I will apply it.
>
> Apart from that, I would echo Eric's thanks for the patch and  
> explanation.
>
> -Andrew

Hi Andrew and Eric,
Thanks for the responses. I was unaware of the png test suite. I have  
attached a new diff that passes this test correctly. It originally failed  
because I was not handling greyscale images with an alpha channel, but it  
also brought to light several other issues with my code that I have fixed.  
I have changed the structure of the code significantly - the if/else  
struct has gone and a single loop returns the different image matrices.  
Although this is more concise, it no longer informs the user if it hits an  
unsupported image type.

Unfortunately I do not have a small test image available, all of ours are  
a minimum of 512x620. However the pngsuite page,  
http://libpng.org/pub/png/pngsuite.html, does have a set of suitable  
images labelled cs*n*.png. These have thrown up an interesting issue - to  
what maximum value should n-bit images be scaled when n is between 8 and  
16? The png spec and test images suggest it should be (2^n - 1). This  
means that higher bit depths give higher precision over the same intensity  
range and the same maximum value. However for my particular camera and  
software this would be wrong, as the CCD has a fixed 12-bit dynamic range  
and the lower png bit depths are only used to save file space. Hence at  
the moment I have set my software to scale to (2^16 - 1) for 8 < n < 16,  
but it follows the png spec for n < 8, so there are two contradictory  
behaviours and I am unsure which is the best approach. Personally I would  
prefer matplotlib to return raw integer values, not floats scaled between  
0 and 1 and then I can apply the scaling myself, but I am aware that this  
is not particularly user friendly for anyone else. imshow() seems to  
handle integer values fine and correctly scales for display, provided that  
no alpha channel is present.

Should I post another message to the developer list about this to see what  
people think? I'd very much like to discuss this with someone who has a  
lot more experience of pngs than me.

Thanks,
Tobias

Careful, "reply" doesn't send your note to the list.

I just looked on the MPl download page in source forge. It looks like 
there are binary eggs there for Windows. You should be able to install 
those in your virtualenv and have it all just work. Just make sure you 
use the right copy of easy_install

-Chris

R. Haynie wrote:
> Christopher Barker wrote:
>> R. Haynie wrote:
>>   
>>> I am using VirtualEnv to have multiple virtual environments that have
>>> their own site-packages folder.  So each environment is its own sandbox.
>>>     
>> another reason why core python really needs to have an "official" 
>> versioning system - either something like virtualenv, or (my 
>> preference), package versioning built in.
>>
>> Anyway, in the mean time, two ideas to try:
>>
>> 1) "easxy_install matplotlib" run with the easy_install in your virtual 
>> env -- hopefully, it will install a binary Windows egg -- does one exist?
>>
>>   
> Tried this towards the end of 2008 a few times, did not fair well at all
> in Windows.
> 
>> 2) try manually moving the matplotlib package from the system 
>> site-packages to your virtualenv.
>>
>> Ok, this is what I tried today:
>>   
> Uninstalled any python package I had installed with a windows installer,
> uninstalled all of python, and cleared the cache folder, deleted
> python25 folder.
> Installed python 2.5 with windows installer.
> Took note of what was in site-packages.
> Ran NumPy windows installer, and moved all new files and folders out of
> Site-Packages.  Moved them to a folder I named c:\site-packages_NumPy.
> Did the same for MatPlotLib windows installer.  Moved them to a folder I
> named c:\site-packages_MatPlotLib.
> Got real anal here and uninstalled numpy and matplotlib using the
> windows uninstallers.  Then uninstalled Python and cleared the cache
> folder and deleted python25.
> 
> Now this is where I thought I could go and make some nice virtual
> environments and have some safe sandboxes.  But of course not.
> Installed python, easy_install, virtualenv, pywin32.
> Created new virtual environment and activated it.  Copied the files from
> the numpy and matplotlib site-packages folders into the new virtual
> environment site-packages folder.
> Tryed a simple plot, and got an error that pylab module did not exist.
> So, I figured that the windows installers did more than met the eye. 
> They probably install some DLLs etc.
> I then installed numpy and matplotlib using the windows installers.
> Tried my plot test from within the virtual environment and it worked.
> 
> I created a new virtual environment, installed nothing, tried the plot
> test from within that environment and the test worked.  It should not
> have worked.
> 
> Looks like I can only have 1 numpy and 1 matplotlib on a windows box at
> a time, virtual environments or not.
> 
> 
>> Let us know how it works out...
>>
>>   
> I sure hope someone reads this and finds something glaringly wrong with
> my process.
> 


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Thomas Robitaille wrote:
> Hi,
> 
> I've found that the match_original=True option in PatchCollection  
> causes matplotlib to crash. I have submitted two bug reports:
> 
> https://sourceforge.net/tracker/?func=detail&aid=2732455&group_id=80706&atid=560720
> https://sourceforge.net/tracker/?func=detail&aid=2723527&group_id=80706&atid=560720

Both are now fixed in the 0.98.5 maintenance branch and in the trunk.

Eric

Thomas Robitaille wrote:
> Hi,
> 
> I've found that the match_original=True option in PatchCollection  
> causes matplotlib to crash. I have submitted two bug reports:
> 
> https://sourceforge.net/tracker/?func=detail&aid=2732455&group_id=80706&atid=560720
> https://sourceforge.net/tracker/?func=detail&aid=2723527&group_id=80706&atid=560720
> 
> I was wondering whether these are problems that other people have  
> encountered too? (description in the bug reports)

Maybe not, but they are certainly bugs.  I have fixed the first and am 
looking at the new one, so I hope both will be resolved shortly.

Eric

> 
> Thanks,
> 
> Thomas
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Cohen-Tanugi Johann wrote:
> indeed, I obviously just got entangled in my own debugging. I do manage 
> to get it to do what I want now.
> 
> sorry for the fuss,
> Johann

No problem at all.  I'm glad things are working for you.

Eric

indeed, I obviously just got entangled in my own debugging. I do manage 
to get it to do what I want now.

sorry for the fuss,
Johann

Eric Firing wrote:
> Cohen-Tanugi Johann wrote:
>> ok, maybe it is in scale.py :)
>> And what I see there confirms my initial fears : the log scale 
>> transform applies a log to the argument, which is incorrect for an 
>> error..... So first of all, another transform needs to be created so 
>> that erry is transformed into erry/y/log(base) where base was 10 in 
>> my example.
>
> Johann,
>
> I don't understand your objection here.  It seems to me that an 
> errorbar  should always be in the same units, and on the same scale, 
> as the point to which it applies.  Therefore when switching from 
> linear to log scales, one simply plots the same data and error ranges 
> on a log scale instead of a linear scale.  This is what mpl does.  If 
> what you want is for the error to be proportional to the value of the 
> point, then you need to specify the error bounds so that they have 
> that property.  For estimation of a power spectrum, for example, this 
> is often the case; the error bars are some fraction (depending on the 
> equivalent number of degrees of freedom) of the spectral level at each 
> frequency, so on a log plot they will have equal length.  It is not 
> the job of the errorbar function to figure that out, however.
>
> If I am misunderstanding, then please provide a very simple concrete 
> example that will make your point clear.
>
>>
>> past midnight here.... I will see tomorrow if I find time to try out 
>> a patch (not the easiest entry point for starting developer's 
>> activities in MPL I am afraid....)
>
> I have just committed a change (trunk r7023) that allows non-positive 
> numbers to be clipped to a small positive value.  To illustrate its 
> use with an errorbar, I added the example provided by Matthias to 
> examples/pylab_examples/log_demo.py, as a 4th subplot.
>
> Eric
>>
>> Johann

Hi,

I've found that the match_original=True option in PatchCollection  
causes matplotlib to crash. I have submitted two bug reports:

https://sourceforge.net/tracker/?func=detail&aid=2732455&group_id=80706&atid=560720
https://sourceforge.net/tracker/?func=detail&aid=2723527&group_id=80706&atid=560720

I was wondering whether these are problems that other people have  
encountered too? (description in the bug reports)

Thanks,

Thomas

hi Eric, then I misunderstood what the code does.... I thought it was 
transforming the data. In any case, my second figure in my previous post 
is wrong because the code should read:
plt.errorbar(cE,corrE*fluxes, yerr=corrE*unc_fluxes)
instead of
plt.errorbar(cE,corrE*fluxes, yerr=unc_fluxes)

and indeed this seems to behave correctly, so I guess I got completely 
confused while trying to understand what was happening. I will check out 
your patch and start from the beginning.

thanks a lot and sorry,
Johann

Eric Firing wrote:
> Cohen-Tanugi Johann wrote:
>> ok, maybe it is in scale.py :)
>> And what I see there confirms my initial fears : the log scale 
>> transform applies a log to the argument, which is incorrect for an 
>> error..... So first of all, another transform needs to be created so 
>> that erry is transformed into erry/y/log(base) where base was 10 in 
>> my example.
>
> Johann,
>
> I don't understand your objection here.  It seems to me that an 
> errorbar  should always be in the same units, and on the same scale, 
> as the point to which it applies.  Therefore when switching from 
> linear to log scales, one simply plots the same data and error ranges 
> on a log scale instead of a linear scale.  This is what mpl does.  If 
> what you want is for the error to be proportional to the value of the 
> point, then you need to specify the error bounds so that they have 
> that property.  For estimation of a power spectrum, for example, this 
> is often the case; the error bars are some fraction (depending on the 
> equivalent number of degrees of freedom) of the spectral level at each 
> frequency, so on a log plot they will have equal length.  It is not 
> the job of the errorbar function to figure that out, however.
>
> If I am misunderstanding, then please provide a very simple concrete 
> example that will make your point clear.
>
>>
>> past midnight here.... I will see tomorrow if I find time to try out 
>> a patch (not the easiest entry point for starting developer's 
>> activities in MPL I am afraid....)
>
> I have just committed a change (trunk r7023) that allows non-positive 
> numbers to be clipped to a small positive value.  To illustrate its 
> use with an errorbar, I added the example provided by Matthias to 
> examples/pylab_examples/log_demo.py, as a 4th subplot.
>
> Eric
>>
>> Johann

Cohen-Tanugi Johann wrote:
> ok, maybe it is in scale.py :)
> And what I see there confirms my initial fears : the log scale transform 
> applies a log to the argument, which is incorrect for an error..... So 
> first of all, another transform needs to be created so that erry is 
> transformed into erry/y/log(base) where base was 10 in my example.

Johann,

I don't understand your objection here.  It seems to me that an errorbar 
  should always be in the same units, and on the same scale, as the 
point to which it applies.  Therefore when switching from linear to log 
scales, one simply plots the same data and error ranges on a log scale 
instead of a linear scale.  This is what mpl does.  If what you want is 
for the error to be proportional to the value of the point, then you 
need to specify the error bounds so that they have that property.  For 
estimation of a power spectrum, for example, this is often the case; the 
error bars are some fraction (depending on the equivalent number of 
degrees of freedom) of the spectral level at each frequency, so on a log 
plot they will have equal length.  It is not the job of the errorbar 
function to figure that out, however.

If I am misunderstanding, then please provide a very simple concrete 
example that will make your point clear.

> 
> past midnight here.... I will see tomorrow if I find time to try out a 
> patch (not the easiest entry point for starting developer's activities 
> in MPL I am afraid....)

I have just committed a change (trunk r7023) that allows non-positive 
numbers to be clipped to a small positive value.  To illustrate its use 
with an errorbar, I added the example provided by Matthias to 
examples/pylab_examples/log_demo.py, as a 4th subplot.

Eric
> 
> Johann

ok, maybe it is in scale.py :)
And what I see there confirms my initial fears : the log scale transform 
applies a log to the argument, which is incorrect for an error..... So 
first of all, another transform needs to be created so that erry is 
transformed into erry/y/log(base) where base was 10 in my example.

past midnight here.... I will see tomorrow if I find time to try out a 
patch (not the easiest entry point for starting developer's activities 
in MPL I am afraid....)

Johann

Cohen-Tanugi Johann wrote:
> hello,
> for the sake of concreteness, here is an example without any limit 
> issues : the python script is attached and the 2 resulting figures as 
> well. The dirst one is drawn using log directly in the arguments, and 
> correctly transforming the y-errors into y-errors/y-values/log(10).  
> In the second figure, I use the log scaling in x and y. Clearly 
> something goes wrong with plotting the error bars, and the y-scale 
> limits also seem ill chosen....
>
> HTH debugging this. I looked again at the code, but I am decidedly 
> lost as to where the error bar plotting occurs, and where it gets 
> modified by the log scale request.
>
> Johann
>
>
> Cohen-Tanugi Johann wrote:
>> hello..... Anyone? I would very much love to see this fixed, and I am 
>> ready to help out, but I do not know how to browse through the code. 
>> Despite the fact that log(errors) should of course not be used, but 
>> rathter errors/values/log(10), Michael's point still remains : 
>> values- errors in log scale can be negative, so that the artist 
>> should just draw a bar until the lower limit of the vertical bar. I 
>> would say that this is the standard practice.
>> Sorry for my previous email beside the point.
>> Johann
>>
>> Cohen-Tanugi Johann wrote:
>>> I tried to look at the code (axes.py I presume) in order to attempt 
>>> a patch, but it defeated me, I do not have the  instructions to 
>>> navigate through this code :)
>>> Where is the actual transform of the error bars occurring?
>>> thanks,
>>> Johann
>>>
>>> Michael Droettboom wrote:
>>>  
>>>> I have to say I don't really have a lot of experience with error 
>>>> bars on log plots -- but the root cause here is that the lower 
>>>> bound of the error bar goes negative, and as we all know, the log 
>>>> of a negative number is undefined.  If you can suggest where the 
>>>> lower bound should be drawn or provide third-party examples, I'm 
>>>> happy to look into this further and resolve this "surprise".
>>>>
>>>> Mike
>>>>
>>>> Cohen-Tanugi Johann wrote:
>>>>   
>>>>> yes exactly....
>>>>> I should have provided a test case, thanks for following up!
>>>>> Johann
>>>>>
>>>>> Matthias Michler wrote:
>>>>>  
>>>>>     
>>>>>> Hello Johann,
>>>>>>
>>>>>> is the problem you are reporting the one I observe in the 
>>>>>> attached picture? Namely some vertical and horizontal lines are 
>>>>>> missing when using yscale="log". More precisely everything below 
>>>>>> y=1 seems to be missing.
>>>>>>
>>>>>> The picture was generated with the code below and
>>>>>> matplotlib.__version__ = '0.98.6svn'
>>>>>> matplotlib.__revision__ = '$Revision: 6887 $'
>>>>>>
>>>>>> best regards Matthias
>>>>>>
>>>>>> ###############################
>>>>>> import numpy as np
>>>>>> import matplotlib.pyplot as plt
>>>>>>
>>>>>> plt.subplot(111, xscale="log", yscale="log")
>>>>>> x = 10.0**np.linspace(0.0, 2.0, 20)
>>>>>> y = x**2.0
>>>>>> plt.errorbar(x, y, xerr=0.1*x, yerr=5.0+0.75*y)
>>>>>> plt.show()
>>>>>> ################################
>>>>>> On Friday 27 March 2009 16:12:12 Cohen-Tanugi Johann wrote:
>>>>>>            
>>>>>>> Hello, what is the best way to get log log plots with error bars? I
>>>>>>> tried putting log10() everywhere but as I was afraid results 
>>>>>>> look ugly....
>>>>>>> thanks,
>>>>>>> johann
>>>>>>>    
>>>>>>> ------------------------------------------------------------------------ 
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------ 
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------ 
>>>>>>>
>>>>>>>     
>>>>>>> ------------------------------------------------------------------------ 
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Matplotlib-users mailing list
>>>>>>> Mat...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>>>                     
>>>>> ------------------------------------------------------------------------------ 
>>>>>
>>>>> _______________________________________________
>>>>> Matplotlib-users mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>         
>>>
>>> ------------------------------------------------------------------------------ 
>>>
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>   
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

hello,
for the sake of concreteness, here is an example without any limit 
issues : the python script is attached and the 2 resulting figures as 
well. The dirst one is drawn using log directly in the arguments, and 
correctly transforming the y-errors into y-errors/y-values/log(10).  In 
the second figure, I use the log scaling in x and y. Clearly something 
goes wrong with plotting the error bars, and the y-scale limits also 
seem ill chosen....

HTH debugging this. I looked again at the code, but I am decidedly lost 
as to where the error bar plotting occurs, and where it gets modified by 
the log scale request.

Johann


Cohen-Tanugi Johann wrote:
> hello..... Anyone? I would very much love to see this fixed, and I am 
> ready to help out, but I do not know how to browse through the code. 
> Despite the fact that log(errors) should of course not be used, but 
> rathter errors/values/log(10), Michael's point still remains : values- 
> errors in log scale can be negative, so that the artist should just 
> draw a bar until the lower limit of the vertical bar. I would say that 
> this is the standard practice.
> Sorry for my previous email beside the point.
> Johann
>
> Cohen-Tanugi Johann wrote:
>> I tried to look at the code (axes.py I presume) in order to attempt a 
>> patch, but it defeated me, I do not have the  instructions to 
>> navigate through this code :)
>> Where is the actual transform of the error bars occurring?
>> thanks,
>> Johann
>>
>> Michael Droettboom wrote:
>>  
>>> I have to say I don't really have a lot of experience with error 
>>> bars on log plots -- but the root cause here is that the lower bound 
>>> of the error bar goes negative, and as we all know, the log of a 
>>> negative number is undefined.  If you can suggest where the lower 
>>> bound should be drawn or provide third-party examples, I'm happy to 
>>> look into this further and resolve this "surprise".
>>>
>>> Mike
>>>
>>> Cohen-Tanugi Johann wrote:
>>>    
>>>> yes exactly....
>>>> I should have provided a test case, thanks for following up!
>>>> Johann
>>>>
>>>> Matthias Michler wrote:
>>>>  
>>>>      
>>>>> Hello Johann,
>>>>>
>>>>> is the problem you are reporting the one I observe in the attached 
>>>>> picture? Namely some vertical and horizontal lines are missing 
>>>>> when using yscale="log". More precisely everything below y=1 seems 
>>>>> to be missing.
>>>>>
>>>>> The picture was generated with the code below and
>>>>> matplotlib.__version__ = '0.98.6svn'
>>>>> matplotlib.__revision__ = '$Revision: 6887 $'
>>>>>
>>>>> best regards Matthias
>>>>>
>>>>> ###############################
>>>>> import numpy as np
>>>>> import matplotlib.pyplot as plt
>>>>>
>>>>> plt.subplot(111, xscale="log", yscale="log")
>>>>> x = 10.0**np.linspace(0.0, 2.0, 20)
>>>>> y = x**2.0
>>>>> plt.errorbar(x, y, xerr=0.1*x, yerr=5.0+0.75*y)
>>>>> plt.show()
>>>>> ################################
>>>>> On Friday 27 March 2009 16:12:12 Cohen-Tanugi Johann wrote:
>>>>>             
>>>>>> Hello, what is the best way to get log log plots with error bars? I
>>>>>> tried putting log10() everywhere but as I was afraid results look 
>>>>>> ugly....
>>>>>> thanks,
>>>>>> johann
>>>>>>    
>>>>>> ------------------------------------------------------------------------ 
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------ 
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------ 
>>>>>>
>>>>>>     
>>>>>> ------------------------------------------------------------------------ 
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Matplotlib-users mailing list
>>>>>> Mat...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>>                     
>>>> ------------------------------------------------------------------------------ 
>>>>
>>>> _______________________________________________
>>>> Matplotlib-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>         
>>
>> ------------------------------------------------------------------------------ 
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>   

Eric Firing wrote:
> Tobias Wood wrote:
>> Hi everyone,
>> After getting fed severely fed up with Matlab in recent months I 
>> downloaded Python, Numpy and Matplotlib to try out as an alternative. So 
>> far I'm pleasantly impressed, even if building from source on Mac OS X 
>> is an experience ;) However, I have discovered a couple of problems with 
>> Matplotlib's imread() function and, shall we say, 'esoteric' PNG files. 
>> My research group uses a 12-bit CCD controlled through Labview to 
>> capture high dynamic range image stacks. Often there are ~30 images in a 
>> single data set. These get read into Matlab in one go for processing as 
>> a stack. I tried converting my code over to Python but, after digging 
>> through the _png.cpp source file found the following that are problems 
>> from my point of view:
>>
>> 1) All .png files in imread() are converted to 4-plane RGBA files 
>> regardless of original format. I would prefer greyscale images to return 
>> a single plane.
>> 2) 16-bit PNGs are stripped to 8 bit, losing any extra precision.
>> 3) The significant bits option in the PNG header was not being checked. 
>> Our camera software will automatically save the PNGs at the maximum 
>> bit-depth required to cover the dynamic range in the image, and can sum 
>> images before saving, so pixels can be anywhere from 6- to 16-bits (at 
>> least those are the values I have observed whilst using the camera).
>>
>> I have attached the results of an svn diff after I made an attempt at 
>> correcting these issues. This is the first time I have contributed to an 
>> open source project, so am not sure of the etiquette here. Also, I have 
>> only had Python and Matplotlib for a fortnight so am still unfamiliar 
>> with them and haven't programmed with libpng before so I apologise in 
>> advance if there any stupid mistakes in my code. I am aware that 
>> imread() is a pretty important function in Matplotlib and hence any 
>> changes I suggest would need comprehensive testing. In brief, I made the 
>> following changes:
> 
> Tobias,
> 
> Thank you very much for the patch and the careful explanation.  I'm not 
> the right person to review it, but I expect someone familiar with libpng 
> use in mpl will do so soon.  Mike D. would be a candidate, but I think 
> he will be unavailable for several days.  If you have not gotten any 
> feedback within a week, *please* ping us with a reminder.  If it comes 
> to that, you could do it by forwarding your original message to 
> matplotlib-devel.

Tobias,

I would like to apply your patch, but the test in
examples/tests/pngsuite fails. If you can submit a new patch where this
test passes, and, even better, if a small example 12-bit PNG of yours is
added to the test, I will apply it.

Apart from that, I would echo Eric's thanks for the patch and explanation.

-Andrew

Tobias Wood wrote:
> Hi everyone,
> After getting fed severely fed up with Matlab in recent months I 
> downloaded Python, Numpy and Matplotlib to try out as an alternative. So 
> far I'm pleasantly impressed, even if building from source on Mac OS X 
> is an experience ;) However, I have discovered a couple of problems with 
> Matplotlib's imread() function and, shall we say, 'esoteric' PNG files. 
> My research group uses a 12-bit CCD controlled through Labview to 
> capture high dynamic range image stacks. Often there are ~30 images in a 
> single data set. These get read into Matlab in one go for processing as 
> a stack. I tried converting my code over to Python but, after digging 
> through the _png.cpp source file found the following that are problems 
> from my point of view:
> 
> 1) All .png files in imread() are converted to 4-plane RGBA files 
> regardless of original format. I would prefer greyscale images to return 
> a single plane.
> 2) 16-bit PNGs are stripped to 8 bit, losing any extra precision.
> 3) The significant bits option in the PNG header was not being checked. 
> Our camera software will automatically save the PNGs at the maximum 
> bit-depth required to cover the dynamic range in the image, and can sum 
> images before saving, so pixels can be anywhere from 6- to 16-bits (at 
> least those are the values I have observed whilst using the camera).
> 
> I have attached the results of an svn diff after I made an attempt at 
> correcting these issues. This is the first time I have contributed to an 
> open source project, so am not sure of the etiquette here. Also, I have 
> only had Python and Matplotlib for a fortnight so am still unfamiliar 
> with them and haven't programmed with libpng before so I apologise in 
> advance if there any stupid mistakes in my code. I am aware that 
> imread() is a pretty important function in Matplotlib and hence any 
> changes I suggest would need comprehensive testing. In brief, I made the 
> following changes:

Tobias,

Thank you very much for the patch and the careful explanation.  I'm not 
the right person to review it, but I expect someone familiar with libpng 
use in mpl will do so soon.  Mike D. would be a candidate, but I think 
he will be unavailable for several days.  If you have not gotten any 
feedback within a week, *please* ping us with a reminder.  If it comes 
to that, you could do it by forwarding your original message to 
matplotlib-devel.

Eric

> 
> 1) Removed the libpng 16- to 8-bit strip command
> 2) Added in the libpng calls to cope with variable bit-depth and 
> converting 16-bit pngs from big-endian to little-endian
> 3) Added a large if/else if stucture at the end to return different 
> PyArrays depending on the input data. RGBA images are 4 plane, RGB 3 
> plane and greyscale 1 plane. Numbers within these are still floats 
> scaled between 0 and 1, except 16-bit images which are doubles (Are 
> floats preferable to doubles?). The scaling factor is worked out from 
> the significant bits struct.
> 
> There are still a couple of issues with this code, mainly that I have 
> only tested it with PNGs I have lying to hand, all of which display 
> correctly with imshow() and I have not made much attempt at supporting 
> 1,2 and 4 bit pngs. I'm personally not a big fan of large if/else ifs 
> but in this case thought it was the clearest way to return the different 
> types.
> 
> I would finally like to point out that no software I have used so far 
> has been able to read the images produced by this camera completely 
> correctly. PIL interprets the variable bit-depth images as binary (?!), 
> and we had to write a wrapper round the Matlab imread() function using 
> iminfo() as Matlab ignores the significant bits setting as well.
> 
> Oh, almost forgot, I'm compiling on Mac OS X 10.5, Python 2.6.1 
> (r261:67515) and the latest Numpy and Matplotlib SVN checkouts.
> 
> Kind regards,
> Tobias Wood

Hi everyone,
After getting fed severely fed up with Matlab in recent months I  
downloaded Python, Numpy and Matplotlib to try out as an alternative. So  
far I'm pleasantly impressed, even if building from source on Mac OS X is  
an experience ;) However, I have discovered a couple of problems with  
Matplotlib's imread() function and, shall we say, 'esoteric' PNG files. My  
research group uses a 12-bit CCD controlled through Labview to capture  
high dynamic range image stacks. Often there are ~30 images in a single  
data set. These get read into Matlab in one go for processing as a stack.  
I tried converting my code over to Python but, after digging through the  
_png.cpp source file found the following that are problems from my point  
of view:

1) All .png files in imread() are converted to 4-plane RGBA files  
regardless of original format. I would prefer greyscale images to return a  
single plane.
2) 16-bit PNGs are stripped to 8 bit, losing any extra precision.
3) The significant bits option in the PNG header was not being checked.  
Our camera software will automatically save the PNGs at the maximum  
bit-depth required to cover the dynamic range in the image, and can sum  
images before saving, so pixels can be anywhere from 6- to 16-bits (at  
least those are the values I have observed whilst using the camera).

I have attached the results of an svn diff after I made an attempt at  
correcting these issues. This is the first time I have contributed to an  
open source project, so am not sure of the etiquette here. Also, I have  
only had Python and Matplotlib for a fortnight so am still unfamiliar with  
them and haven't programmed with libpng before so I apologise in advance  
if there any stupid mistakes in my code. I am aware that imread() is a  
pretty important function in Matplotlib and hence any changes I suggest  
would need comprehensive testing. In brief, I made the following changes:

1) Removed the libpng 16- to 8-bit strip command
2) Added in the libpng calls to cope with variable bit-depth and  
converting 16-bit pngs from big-endian to little-endian
3) Added a large if/else if stucture at the end to return different  
PyArrays depending on the input data. RGBA images are 4 plane, RGB 3 plane  
and greyscale 1 plane. Numbers within these are still floats scaled  
between 0 and 1, except 16-bit images which are doubles (Are floats  
preferable to doubles?). The scaling factor is worked out from the  
significant bits struct.

There are still a couple of issues with this code, mainly that I have only  
tested it with PNGs I have lying to hand, all of which display correctly  
with imshow() and I have not made much attempt at supporting 1,2 and 4 bit  
pngs. I'm personally not a big fan of large if/else ifs but in this case  
thought it was the clearest way to return the different types.

I would finally like to point out that no software I have used so far has  
been able to read the images produced by this camera completely correctly.  
PIL interprets the variable bit-depth images as binary (?!), and we had to  
write a wrapper round the Matlab imread() function using iminfo() as  
Matlab ignores the significant bits setting as well.

Oh, almost forgot, I'm compiling on Mac OS X 10.5, Python 2.6.1  
(r261:67515) and the latest Numpy and Matplotlib SVN checkouts.

Kind regards,
Tobias Wood

I am pretty happy with the default for how dates ticks
are updated with zooming the plot with the navigation
toolbar...until it gets down to the level of hours.

Hours are by default displayed in a format like:
"23:00:00 UTC".  How can I get it to display it in a
more common way, such as "11:00 pm", or better,
"11 pm, 3/15"?

Everything else should stay the same.

Thanks,
Che

Hello everyone. I have a problem about the PS backend and the Draw Event.

I read the "Automatically make room for tick labels" section 
<http://matplotlib.sourceforge.net/faq/howto_faq.html#automatically-make-room-for-tick-labels> 
in the matplotlib Howto page. It is very useful to my project, and I 
would like to adopt it. I wrote a test program as follows:

> #!/usr/bin/env python
>
> import matplotlib
> matplotlib.use("PS")
>
> import pylab
>
> def on_draw(event):
>     fig = pylab.gcf()
>     cur_bottom = fig.subplotpars.bottom
>
>     if cur_bottom != 0.2:
>         fig.subplots_adjust(bottom=0.2)
>         fig.canvas.draw()
>
>     print("moved bottom")
>
> pylab.xlabel("x axis\nlabel\nis\nlong")
> pylab.gcf().canvas.mpl_connect('draw_event', on_draw)
> #pylab.subplots_adjust(bottom=0.2)
>
> pylab.savefig("test.eps")
which just lifts the bottom to 0.2. If I execute this program, "moved 
bottom" is displayed just once, but the figure is actually not moved. If 
I simple uncomment the line after mpl_connect, figure is lifted. 
However, if I change the backend from "PS" to "Agg" and generate 
"test.png" instead, "moved bottom" is displayed twice, and figure is moved.

So I think when using Agg to generate png image, the canvas draw() 
invokes the Draw Event again and shows the second "moved bottom". This 
makes sense. My question is, when using PS backend,
why does not the subplots_adjust work in on_draw()? And why does not the 
canvas draw() invokes the Draw Event? Is this is an known issue?

I cannot switch my backend to Agg, because Agg does not produce hatch, 
which is essential to my images.

Thanks in advance for you help!

It looks like you're all heading down the right path.  I'm happy to help 
(as the original author of the transforms code), but I'm going to be 
generally unavailable until Thursday or Friday of next week.

Cheers,
Mike

Eric Firing wrote:
> Cohen-Tanugi Johann wrote:
>> I tried to look at the code (axes.py I presume) in order to attempt a 
>> patch, but it defeated me, I do not have the  instructions to 
>> navigate through this code :)
>> Where is the actual transform of the error bars occurring?
>
> I think it is in the draw (or recache) method of the artists.
>
> The right way to handle this problem is not obvious to me.  Maybe with 
> a variant of the log scale that clips instead of masking invalid 
> points. And maybe instead of making a whole set of such variants, the 
> behavior--masking versus clipping, and the clip level if the 
> latter--should be handled by an rcParam.
>
> Eric
>
>> thanks,
>> Johann
>>
>> Michael Droettboom wrote:
>>> I have to say I don't really have a lot of experience with error 
>>> bars on log plots -- but the root cause here is that the lower bound 
>>> of the error bar goes negative, and as we all know, the log of a 
>>> negative number is undefined.  If you can suggest where the lower 
>>> bound should be drawn or provide third-party examples, I'm happy to 
>>> look into this further and resolve this "surprise".
>>>
>>> Mike
>>>
>>> Cohen-Tanugi Johann wrote:
>>>> yes exactly....
>>>> I should have provided a test case, thanks for following up!
>>>> Johann
>>>>
>>>> Matthias Michler wrote:
>>>>  
>>>>> Hello Johann,
>>>>>
>>>>> is the problem you are reporting the one I observe in the attached 
>>>>> picture? Namely some vertical and horizontal lines are missing 
>>>>> when using yscale="log". More precisely everything below y=1 seems 
>>>>> to be missing.
>>>>>
>>>>> The picture was generated with the code below and
>>>>> matplotlib.__version__ = '0.98.6svn'
>>>>> matplotlib.__revision__ = '$Revision: 6887 $'
>>>>>
>>>>> best regards Matthias
>>>>>
>>>>> ###############################
>>>>> import numpy as np
>>>>> import matplotlib.pyplot as plt
>>>>>
>>>>> plt.subplot(111, xscale="log", yscale="log")
>>>>> x = 10.0**np.linspace(0.0, 2.0, 20)
>>>>> y = x**2.0
>>>>> plt.errorbar(x, y, xerr=0.1*x, yerr=5.0+0.75*y)
>>>>> plt.show()
>>>>> ################################
>>>>> On Friday 27 March 2009 16:12:12 Cohen-Tanugi Johann wrote:
>>>>>     
>>>>>> Hello, what is the best way to get log log plots with error bars? I
>>>>>> tried putting log10() everywhere but as I was afraid results look 
>>>>>> ugly....
>>>>>> thanks,
>>>>>> johann

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

> image.set_clim(vmin=10)

This works great - thanks!

Thomas