matplotlib-users

[Matplotlib-users] Bug in colorbar()

[Jeffrey S. <jef...@gm...>]

I am trying to make a plot with a colorbar that has a reduced axis over
which the colorbar is executed.

This is set via passing in a norm to contourf:
        logNorm = colors.Normalize(vmax=0,vmin=-100)
        surf = ax.contourf(X,Y,logZ, map_scale, cmap=cm.jet, norm=logNorm)

The output of this will have the colorbar extend to the full range of the
data and not limited by the norm set:

cbar = fig.colorbar(surf, shrink=0.70, aspect=36, fraction=.15,pad=.03)

so I assumed modifying by setting the norm like this would do the trick:

cbar = fig.colorbar(surf, shrink=0.70, aspect=36, fraction=.15,pad=.03,
norm=logNorm)

This isn't what happens. norm has no effect. The norm is recognized but not
passed to ColorbarBase is my guess from doing this instead to get the
desired effect:

        axcb, _ = mpl.colorbar.make_axes_gridspec(ax, shrink=0.7)
        cbar = mpl.colorbar.ColorbarBase(axcb, cmap=cm.jet, norm=logNorm)



Is this a bug or any reason why the norm is not passed through if specified
in colorbar??

Re: [Matplotlib-users] Bug in colorbar()

[Eric F. <ef...@ha...>]

On 2012/07/26 7:52 PM, Jeffrey Spencer wrote:
> I am trying to make a plot with a colorbar that has a reduced axis over
> which the colorbar is executed.
>
> This is set via passing in a norm to contourf:
>          logNorm = colors.Normalize(vmax=0,vmin=-100)
>          surf = ax.contourf(X,Y,logZ, map_scale, cmap=cm.jet, norm=logNorm)
>
> The output of this will have the colorbar extend to the full range of
> the data and not limited by the norm set:
>
> cbar = fig.colorbar(surf, shrink=0.70, aspect=36, fraction=.15,pad=.03)
>
> so I assumed modifying by setting the norm like this would do the trick:
>
> cbar = fig.colorbar(surf, shrink=0.70, aspect=36, fraction=.15,pad=.03,
> norm=logNorm)
>
> This isn't what happens. norm has no effect. The norm is recognized but
> not passed to ColorbarBase is my guess from doing this instead to get
> the desired effect:
>
>          axcb, _ = mpl.colorbar.make_axes_gridspec(ax, shrink=0.7)
>          cbar = mpl.colorbar.ColorbarBase(axcb, cmap=cm.jet, norm=logNorm)
>
>
>
> Is this a bug or any reason why the norm is not passed through if
> specified in colorbar??

Yes, there is a reason why it is not passed through; both the cmap and 
the norm are taken from the mappable, so that the colorbar will actually 
match the mappable.  There may be a bug, but it is not immediately 
obvious to me.  Please provide a complete, minimal, self-contained 
example that illustrates the problem, and specify what version of mpl 
you are using.

Eric

Re: [Matplotlib-users] Bug in colorbar()

[Jeffrey S. <jef...@gm...>]

 I am using 1.2.X and here is a minimalist example to see what happens:

Link to figure of output:
https://dl.dropbox.com/u/13534143/example.png


Example:
import numpy as np
import matplotlib as mpl
X, Y = np.meshgrid(arange(20),arange(20))
Z = np.arange(20*20)
Z = Z.reshape(20,20)
logNorm = mpl.colors.Normalize(vmin=0,vmax=200)
fig = mpl.pyplot.figure(10)
ax = fig.add_subplot(111)
surf = ax.contourf(X,Y,Z, 100, cmap=matplotlib.cm.jet, norm = logNorm)
cbar = fig.colorbar(surf, shrink=0.70, norm=logNorm)
show()
draw()

On Fri, Jul 27, 2012 at 5:00 PM, Eric Firing <ef...@ha...> wrote:

> On 2012/07/26 7:52 PM, Jeffrey Spencer wrote:
> > I am trying to make a plot with a colorbar that has a reduced axis over
> > which the colorbar is executed.
> >
> > This is set via passing in a norm to contourf:
> >          logNorm = colors.Normalize(vmax=0,vmin=-100)
> >          surf = ax.contourf(X,Y,logZ, map_scale, cmap=cm.jet,
> norm=logNorm)
> >
> > The output of this will have the colorbar extend to the full range of
> > the data and not limited by the norm set:
> >
> > cbar = fig.colorbar(surf, shrink=0.70, aspect=36, fraction=.15,pad=.03)
> >
> > so I assumed modifying by setting the norm like this would do the trick:
> >
> > cbar = fig.colorbar(surf, shrink=0.70, aspect=36, fraction=.15,pad=.03,
> > norm=logNorm)
> >
> > This isn't what happens. norm has no effect. The norm is recognized but
> > not passed to ColorbarBase is my guess from doing this instead to get
> > the desired effect:
> >
> >          axcb, _ = mpl.colorbar.make_axes_gridspec(ax, shrink=0.7)
> >          cbar = mpl.colorbar.ColorbarBase(axcb, cmap=cm.jet,
> norm=logNorm)
> >
> >
> >
> > Is this a bug or any reason why the norm is not passed through if
> > specified in colorbar??
>
> Yes, there is a reason why it is not passed through; both the cmap and
> the norm are taken from the mappable, so that the colorbar will actually
> match the mappable.  There may be a bug, but it is not immediately
> obvious to me.  Please provide a complete, minimal, self-contained
> example that illustrates the problem, and specify what version of mpl
> you are using.
>
> Eric
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Re: [Matplotlib-users] Bug in colorbar()

[Jeffrey S. <jef...@gm...>]

Further after doing a little digging the code in
matplotlib.colorbar.Colorbar looks correct to me but doesn't work correctly.

It essentially ignores the norm value because always sets the norm to the
norm for the contour plot (eg. mappable.norm) which this is the same norm
with vmin and vmax values I want to use anyway. It seems as though somehow
instead it uses the vmin and vmax not from the norm but from the actual
data.

So from the code below it would use vmin and vmax from the mappable object
(eg. surf)  which are (-152,0). It won't use surf.norm vmin and vmax values
which are desired (-100,0). I couldn't find where this mistake occurs
because looked right to me from prodding around but let me know.
____________________________________________
Jeff Spencer
Department of Electrical and Electronic Engineering
The University of Melbourne
jef...@gm...


On Fri, Jul 27, 2012 at 3:52 PM, Jeffrey Spencer <jef...@gm...>wrote:

> I am trying to make a plot with a colorbar that has a reduced axis over
> which the colorbar is executed.
>
> This is set via passing in a norm to contourf:
>         logNorm = colors.Normalize(vmax=0,vmin=-100)
>         surf = ax.contourf(X,Y,logZ, map_scale, cmap=cm.jet, norm=logNorm)
>
> The output of this will have the colorbar extend to the full range of the
> data and not limited by the norm set:
>
> cbar = fig.colorbar(surf, shrink=0.70, aspect=36, fraction=.15,pad=.03)
>
> so I assumed modifying by setting the norm like this would do the trick:
>
> cbar = fig.colorbar(surf, shrink=0.70, aspect=36, fraction=.15,pad=.03,
> norm=logNorm)
>
> This isn't what happens. norm has no effect. The norm is recognized but
> not passed to ColorbarBase is my guess from doing this instead to get the
> desired effect:
>
>         axcb, _ = mpl.colorbar.make_axes_gridspec(ax, shrink=0.7)
>         cbar = mpl.colorbar.ColorbarBase(axcb, cmap=cm.jet, norm=logNorm)
>
>
>
> Is this a bug or any reason why the norm is not passed through if
> specified in colorbar??
>

Re: [Matplotlib-users] Bug in colorbar()

[Eric F. <ef...@ha...>]

On 2012/07/26 9:20 PM, Jeffrey Spencer wrote:
> import numpy as np
> import matplotlib as mpl
> X, Y = np.meshgrid(arange(20),arange(20))
> Z = np.arange(20*20)
> Z = Z.reshape(20,20)
> logNorm = mpl.colors.Normalize(vmin=0,vmax=200)
> fig = mpl.pyplot.figure(10)
> ax = fig.add_subplot(111)
> surf = ax.contourf(X,Y,Z, 100, cmap=matplotlib.cm.jet, norm = logNorm)
> cbar = fig.colorbar(surf, shrink=0.70, norm=logNorm)
> show()


OK, the basic problem here is that you are specifying 100 levels, which 
are being auto-selected to cover the actual data range; and the colorbar 
is doing what it is supposed to do, which is show the levels you 
actually have.  Try leaving out the norm, and just specify the levels to 
cover what you want, more like this:

surf = ax.contourf(X, Y, Z, np.arange(0, 200.1, 2), cmap=mpl.cm.jet, 
extend='both')
cbar = fig.colorbar(surf, shrink=0.7)

If you actually do want a log norm, you can pass that in to contourf and 
it will be passed on to colorbar; but most likely you should still 
specify the levels you want as an array, and not specify vmin and vmax 
in the norm.  If you want log scaling, it may work better to simply plot 
the log of Z, and use the colorbar label to indicate that this is what 
you are doing.

Note that with a recent change, you can use the set_under and set_over 
methods of the cmap to specify arbitrary colors, or no color, for the 
extended regions; or you can leave out the "extend" kwarg and not color 
the regions outside the range of your contour levels.

In general, contourf is most appropriate when there is a moderate number 
of levels, well under 100; if you want that many gradations, then you 
might do better with pcolormesh or ax.pcolorfast or imshow.  For those 
image-like methods, it is appropriate to use vmin and vmax, either 
directly, or in a norm.

Eric

Re: [Matplotlib-users] Bug in colorbar()

[Eric F. <ef...@ha...>]

On 2012/07/26 10:26 PM, Jeffrey Spencer wrote:
> Thanks, that is all good info to know. I change my data to log and
> normalize it so the logNorm is just linear actually so specifying only
> levels is fine. I'll let you know if that doesn't work properly for some
> reason.
>
> Ok, yeah I looked at pcolormesh quickly and can't remember why I chose
> originally when I wrote this to go with contourf but I use to only do
> like 10 levels. I think it might be because use a log yaxis and think it
> used to be a bit funky or couldn't get it working properly but seemed
> fine now.
>
> No, I don't want to modify the ticks but the black lines around that
> like how they are removed on the major axis in this example:
> https://dl.dropbox.com/u/13534143/example1.png
> I want to remove the black lines also around the colorbar. Not the tick
> marks. Does that make sense?

cbar.outline.set_color('none')
or
cbar.outline.set_visible(False)

>
> One more quick question out of curiosity noticing from saving plots to
> .pdf from contourf and pcolormesh vs specgram. Specgram seems to output
> the lines and text as vector graphics. Then imbeds the image. When
> outputting from pcolormesh or contourf this isn't the case. It tries to
> write the lines or something else weird happens. Can you output to .pdf
> from these and make the lines and text be vectors. Then the image output
> as an image in the pdf like in specgram. Or is there a setting to do
> this and specify the .dpi of the image in the .pdf.

Lines and text are output to pdf exactly the same by specgram, 
pcolormesh, and contourf.  The difference should be only in the image 
part of the plot, which is rasterized for a specgram image and for the 
"quadmesh" produced by pcolormesh, but is a set of patches (vector 
specification, not rasterized) for contourf.  Are you seeing results 
that are inconsistent with this expectation?

Eric

>
> Thanks a lot,
> Jeff
>
> On Fri, Jul 27, 2012 at 5:51 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
>     On 2012/07/26 9:20 PM, Jeffrey Spencer wrote:
>
>         import numpy as np
>         import matplotlib as mpl
>         X, Y = np.meshgrid(arange(20),arange(__20))
>         Z = np.arange(20*20)
>         Z = Z.reshape(20,20)
>         logNorm = mpl.colors.Normalize(vmin=0,__vmax=200)
>         fig = mpl.pyplot.figure(10)
>         ax = fig.add_subplot(111)
>         surf = ax.contourf(X,Y,Z, 100, cmap=matplotlib.cm.jet, norm =
>         logNorm)
>         cbar = fig.colorbar(surf, shrink=0.70, norm=logNorm)
>         show()
>
>
>
>     OK, the basic problem here is that you are specifying 100 levels,
>     which are being auto-selected to cover the actual data range; and
>     the colorbar is doing what it is supposed to do, which is show the
>     levels you actually have.  Try leaving out the norm, and just
>     specify the levels to cover what you want, more like this:
>
>     surf = ax.contourf(X, Y, Z, np.arange(0, 200.1, 2), cmap=mpl.cm.jet,
>     extend='both')
>     cbar = fig.colorbar(surf, shrink=0.7)
>
>     If you actually do want a log norm, you can pass that in to contourf
>     and it will be passed on to colorbar; but most likely you should
>     still specify the levels you want as an array, and not specify vmin
>     and vmax in the norm.  If you want log scaling, it may work better
>     to simply plot the log of Z, and use the colorbar label to indicate
>     that this is what you are doing.
>
>     Note that with a recent change, you can use the set_under and
>     set_over methods of the cmap to specify arbitrary colors, or no
>     color, for the extended regions; or you can leave out the "extend"
>     kwarg and not color the regions outside the range of your contour
>     levels.
>
>     In general, contourf is most appropriate when there is a moderate
>     number of levels, well under 100; if you want that many gradations,
>     then you might do better with pcolormesh or ax.pcolorfast or imshow.
>       For those image-like methods, it is appropriate to use vmin and
>     vmax, either directly, or in a norm.
>
>     Eric
>
>

Re: [Matplotlib-users] Bug in colorbar()

[Jeffrey S. <jef...@gm...>]

I figured out you can pass in the rasterized keyword to all of those to
change the rasterization in the output.

Also the docs say for pcolormesh it defaults to the backend if not set.
Therefore, in the case of a vector based it would output vectors if not set
to rasterize.

Haven't tested but curious. Lets say I want to output at 600dpi but I
display images interactively at 100dpi. Does it always rasterize the image
to the higher dpi? I had noticed this didn't seem to occur in specgram but
figured because the specgram is a relatively low resolution image that
outputing at 600dpi doesn't do anything because original image is already a
low resolution. I would expect the other modes do do this where the image
isn't already output and have to rasterize the image when saving like
pcolormesh and contour plots.

Cheers,
Jeff

On Sat, Jul 28, 2012 at 1:43 PM, Jeffrey Spencer <jef...@gm...>wrote:

> Yes, specgram rasterizes and contourf is definately a vector specification
> which isn't optimal for 100 levels.
>
> I would switch to pcolormesh but the output file can't be rasterizing the
> image. It outputs a huge file in .pdf (40X bigger than equivalent .png) and
> it looks like it is vector based not rasterized.
>
>
> Basically, If you output specgram or imshow in .pdf or .png the file sizes
> are relatively comparable with .pdf, .eps, .svg being slightly larger due
> to embedding the picture.
>
> If I output in pcolor, pcolormesh, contourf (with more than 100 levels)
> the file sizes are huge for .pdf, .eps, .svg which I'm assuming because
> vector based output. It also looks like vector based output because can see
> the lines it draws for contours. Could this possibly be a selection for
> these outputs to force raster based processing or is that not easy.
>
>
> On Sat, Jul 28, 2012 at 3:26 AM, Eric Firing <ef...@ha...> wrote:
>
>> On 2012/07/26 10:26 PM, Jeffrey Spencer wrote:
>>
>>> Thanks, that is all good info to know. I change my data to log and
>>> normalize it so the logNorm is just linear actually so specifying only
>>> levels is fine. I'll let you know if that doesn't work properly for some
>>> reason.
>>>
>>> Ok, yeah I looked at pcolormesh quickly and can't remember why I chose
>>> originally when I wrote this to go with contourf but I use to only do
>>> like 10 levels. I think it might be because use a log yaxis and think it
>>> used to be a bit funky or couldn't get it working properly but seemed
>>> fine now.
>>>
>>> No, I don't want to modify the ticks but the black lines around that
>>> like how they are removed on the major axis in this example:
>>> https://dl.dropbox.com/u/**13534143/example1.png<https://dl.dropbox.com/u/13534143/example1.png>
>>> I want to remove the black lines also around the colorbar. Not the tick
>>> marks. Does that make sense?
>>>
>>
>> cbar.outline.set_color('none')
>> or
>> cbar.outline.set_visible(**False)
>>
>>
>>
>>> One more quick question out of curiosity noticing from saving plots to
>>> .pdf from contourf and pcolormesh vs specgram. Specgram seems to output
>>> the lines and text as vector graphics. Then imbeds the image. When
>>> outputting from pcolormesh or contourf this isn't the case. It tries to
>>> write the lines or something else weird happens. Can you output to .pdf
>>> from these and make the lines and text be vectors. Then the image output
>>> as an image in the pdf like in specgram. Or is there a setting to do
>>> this and specify the .dpi of the image in the .pdf.
>>>
>>
>> Lines and text are output to pdf exactly the same by specgram,
>> pcolormesh, and contourf.  The difference should be only in the image part
>> of the plot, which is rasterized for a specgram image and for the
>> "quadmesh" produced by pcolormesh, but is a set of patches (vector
>> specification, not rasterized) for contourf.  Are you seeing results that
>> are inconsistent with this expectation?
>>
>> Eric
>>
>>
>>> Thanks a lot,
>>> Jeff
>>>
>>> On Fri, Jul 27, 2012 at 5:51 PM, Eric Firing <ef...@ha...
>>> <mailto:ef...@ha...>> wrote:
>>>
>>>     On 2012/07/26 9:20 PM, Jeffrey Spencer wrote:
>>>
>>>         import numpy as np
>>>         import matplotlib as mpl
>>>         X, Y = np.meshgrid(arange(20),arange(**__20))
>>>
>>>         Z = np.arange(20*20)
>>>         Z = Z.reshape(20,20)
>>>         logNorm = mpl.colors.Normalize(vmin=0,__**vmax=200)
>>>
>>>         fig = mpl.pyplot.figure(10)
>>>         ax = fig.add_subplot(111)
>>>         surf = ax.contourf(X,Y,Z, 100, cmap=matplotlib.cm.jet, norm =
>>>         logNorm)
>>>         cbar = fig.colorbar(surf, shrink=0.70, norm=logNorm)
>>>         show()
>>>
>>>
>>>
>>>     OK, the basic problem here is that you are specifying 100 levels,
>>>     which are being auto-selected to cover the actual data range; and
>>>     the colorbar is doing what it is supposed to do, which is show the
>>>     levels you actually have.  Try leaving out the norm, and just
>>>     specify the levels to cover what you want, more like this:
>>>
>>>     surf = ax.contourf(X, Y, Z, np.arange(0, 200.1, 2), cmap=mpl.cm.jet,
>>>     extend='both')
>>>     cbar = fig.colorbar(surf, shrink=0.7)
>>>
>>>     If you actually do want a log norm, you can pass that in to contourf
>>>     and it will be passed on to colorbar; but most likely you should
>>>     still specify the levels you want as an array, and not specify vmin
>>>     and vmax in the norm.  If you want log scaling, it may work better
>>>     to simply plot the log of Z, and use the colorbar label to indicate
>>>     that this is what you are doing.
>>>
>>>     Note that with a recent change, you can use the set_under and
>>>     set_over methods of the cmap to specify arbitrary colors, or no
>>>     color, for the extended regions; or you can leave out the "extend"
>>>     kwarg and not color the regions outside the range of your contour
>>>     levels.
>>>
>>>     In general, contourf is most appropriate when there is a moderate
>>>     number of levels, well under 100; if you want that many gradations,
>>>     then you might do better with pcolormesh or ax.pcolorfast or imshow.
>>>       For those image-like methods, it is appropriate to use vmin and
>>>     vmax, either directly, or in a norm.
>>>
>>>     Eric
>>>
>>>
>>>
>>
>

Re: [Matplotlib-users] Bug in colorbar()

[Jeffrey S. <jef...@gm...>]

Think I figured out an actual bug in the function: colors.Normalize().

The behavior states that if vmin or vmax is passed in as None it should
take the minimum or maximum value respectively.

If only one value is passed into the function, both values are overwritten
to the min and max instead of just the one that is not passed in. So the
only case where it sets the limits is if both vmin and vmax are passed to
the function. Is this the desired behavior because from the docstring it
seems this is incorrect.

Cheers,
Jeff



On Sat, Jul 28, 2012 at 2:15 PM, Jeffrey Spencer <jef...@gm...>wrote:

> I figured out you can pass in the rasterized keyword to all of those to
> change the rasterization in the output.
>
> Also the docs say for pcolormesh it defaults to the backend if not set.
> Therefore, in the case of a vector based it would output vectors if not set
> to rasterize.
>
> Haven't tested but curious. Lets say I want to output at 600dpi but I
> display images interactively at 100dpi. Does it always rasterize the image
> to the higher dpi? I had noticed this didn't seem to occur in specgram but
> figured because the specgram is a relatively low resolution image that
> outputing at 600dpi doesn't do anything because original image is already a
> low resolution. I would expect the other modes do do this where the image
> isn't already output and have to rasterize the image when saving like
> pcolormesh and contour plots.
>
> Cheers,
> Jeff
>
>
> On Sat, Jul 28, 2012 at 1:43 PM, Jeffrey Spencer <jef...@gm...>wrote:
>
>> Yes, specgram rasterizes and contourf is definately a vector
>> specification which isn't optimal for 100 levels.
>>
>> I would switch to pcolormesh but the output file can't be rasterizing the
>> image. It outputs a huge file in .pdf (40X bigger than equivalent .png) and
>> it looks like it is vector based not rasterized.
>>
>>
>> Basically, If you output specgram or imshow in .pdf or .png the file
>> sizes are relatively comparable with .pdf, .eps, .svg being slightly larger
>> due to embedding the picture.
>>
>> If I output in pcolor, pcolormesh, contourf (with more than 100 levels)
>> the file sizes are huge for .pdf, .eps, .svg which I'm assuming because
>> vector based output. It also looks like vector based output because can see
>> the lines it draws for contours. Could this possibly be a selection for
>> these outputs to force raster based processing or is that not easy.
>>
>>
>> On Sat, Jul 28, 2012 at 3:26 AM, Eric Firing <ef...@ha...> wrote:
>>
>>> On 2012/07/26 10:26 PM, Jeffrey Spencer wrote:
>>>
>>>> Thanks, that is all good info to know. I change my data to log and
>>>> normalize it so the logNorm is just linear actually so specifying only
>>>> levels is fine. I'll let you know if that doesn't work properly for some
>>>> reason.
>>>>
>>>> Ok, yeah I looked at pcolormesh quickly and can't remember why I chose
>>>> originally when I wrote this to go with contourf but I use to only do
>>>> like 10 levels. I think it might be because use a log yaxis and think it
>>>> used to be a bit funky or couldn't get it working properly but seemed
>>>> fine now.
>>>>
>>>> No, I don't want to modify the ticks but the black lines around that
>>>> like how they are removed on the major axis in this example:
>>>> https://dl.dropbox.com/u/**13534143/example1.png<https://dl.dropbox.com/u/13534143/example1.png>
>>>> I want to remove the black lines also around the colorbar. Not the tick
>>>> marks. Does that make sense?
>>>>
>>>
>>> cbar.outline.set_color('none')
>>> or
>>> cbar.outline.set_visible(**False)
>>>
>>>
>>>
>>>> One more quick question out of curiosity noticing from saving plots to
>>>> .pdf from contourf and pcolormesh vs specgram. Specgram seems to output
>>>> the lines and text as vector graphics. Then imbeds the image. When
>>>> outputting from pcolormesh or contourf this isn't the case. It tries to
>>>> write the lines or something else weird happens. Can you output to .pdf
>>>> from these and make the lines and text be vectors. Then the image output
>>>> as an image in the pdf like in specgram. Or is there a setting to do
>>>> this and specify the .dpi of the image in the .pdf.
>>>>
>>>
>>> Lines and text are output to pdf exactly the same by specgram,
>>> pcolormesh, and contourf.  The difference should be only in the image part
>>> of the plot, which is rasterized for a specgram image and for the
>>> "quadmesh" produced by pcolormesh, but is a set of patches (vector
>>> specification, not rasterized) for contourf.  Are you seeing results that
>>> are inconsistent with this expectation?
>>>
>>> Eric
>>>
>>>
>>>> Thanks a lot,
>>>> Jeff
>>>>
>>>> On Fri, Jul 27, 2012 at 5:51 PM, Eric Firing <ef...@ha...
>>>> <mailto:ef...@ha...>> wrote:
>>>>
>>>>     On 2012/07/26 9:20 PM, Jeffrey Spencer wrote:
>>>>
>>>>         import numpy as np
>>>>         import matplotlib as mpl
>>>>         X, Y = np.meshgrid(arange(20),arange(**__20))
>>>>
>>>>         Z = np.arange(20*20)
>>>>         Z = Z.reshape(20,20)
>>>>         logNorm = mpl.colors.Normalize(vmin=0,__**vmax=200)
>>>>
>>>>         fig = mpl.pyplot.figure(10)
>>>>         ax = fig.add_subplot(111)
>>>>         surf = ax.contourf(X,Y,Z, 100, cmap=matplotlib.cm.jet, norm =
>>>>         logNorm)
>>>>         cbar = fig.colorbar(surf, shrink=0.70, norm=logNorm)
>>>>         show()
>>>>
>>>>
>>>>
>>>>     OK, the basic problem here is that you are specifying 100 levels,
>>>>     which are being auto-selected to cover the actual data range; and
>>>>     the colorbar is doing what it is supposed to do, which is show the
>>>>     levels you actually have.  Try leaving out the norm, and just
>>>>     specify the levels to cover what you want, more like this:
>>>>
>>>>     surf = ax.contourf(X, Y, Z, np.arange(0, 200.1, 2), cmap=mpl.cm.jet,
>>>>     extend='both')
>>>>     cbar = fig.colorbar(surf, shrink=0.7)
>>>>
>>>>     If you actually do want a log norm, you can pass that in to contourf
>>>>     and it will be passed on to colorbar; but most likely you should
>>>>     still specify the levels you want as an array, and not specify vmin
>>>>     and vmax in the norm.  If you want log scaling, it may work better
>>>>     to simply plot the log of Z, and use the colorbar label to indicate
>>>>     that this is what you are doing.
>>>>
>>>>     Note that with a recent change, you can use the set_under and
>>>>     set_over methods of the cmap to specify arbitrary colors, or no
>>>>     color, for the extended regions; or you can leave out the "extend"
>>>>     kwarg and not color the regions outside the range of your contour
>>>>     levels.
>>>>
>>>>     In general, contourf is most appropriate when there is a moderate
>>>>     number of levels, well under 100; if you want that many gradations,
>>>>     then you might do better with pcolormesh or ax.pcolorfast or imshow.
>>>>       For those image-like methods, it is appropriate to use vmin and
>>>>     vmax, either directly, or in a norm.
>>>>
>>>>     Eric
>>>>
>>>>
>>>>
>>>
>>
>

Re: [Matplotlib-users] Bug in colorbar()

[Eric F. <ef...@ha...>]

On 2012/07/28 10:17 PM, Jeffrey Spencer wrote:
> Think I figured out an actual bug in the function: colors.Normalize().
>
> The behavior states that if vmin or vmax is passed in as None it should
> take the minimum or maximum value respectively.
>
> If only one value is passed into the function, both values are
> overwritten to the min and max instead of just the one that is not
> passed in. So the only case where it sets the limits is if both vmin and
> vmax are passed to the function. Is this the desired behavior because
> from the docstring it seems this is incorrect.
>
> Cheers,
> Jeff
>
>

Jeff,

I don't see it, so you need to provide an actual example.  Here is what 
happens (in ipython --pylab) when I try to reproduce what it sounds like 
you are describing:

In [2]: norm = Normalize(vmax=10)

In [3]: norm([-10, 10, 20])
Out[3]:
masked_array(data = [ 0.   1.   1.5],
              mask = False,
        fill_value = 1e+20)


In [4]: norm.vmin
Out[4]: -10.0

In [5]: norm.vmax
Out[5]: 10

This behavior is as described in the docstring.

The one potentially confusing aspect that I see at the moment is that 
the Normalize class does not distinguish between explicit vmin, vmax, 
and the values that it calculates via its autoscale_None method when 
called.  As soon as a None is replaced by an actual value, whether by 
being set explicitly or by autoscaling, the replacement is permanent. 
Perhaps this should be made explicit in the docstring.  The docstrings 
could be re-arranged to clarify the roles of the class initializer and 
its __call__ method.

Eric

Re: [Matplotlib-users] Bug in colorbar()

[Jeffrey S. <jef...@gm...>]

Eric,

Normalize appears to be working correctly and as you stated above but when
passed into contourf appears to have inconsistent results not following the
docstring by allowing the value to change.

Quick examples:

X, Y = meshgrid(arange(20),arange(20))
Z = arange(20*20)
Z = Z.reshape(20,20)
norm = colors.Normalize(vmin=200,vmax=None)
print norm.vmin
fig = figure(10)
ax = fig.add_subplot(111)
surf = ax.contourf(X,Y,Z, 100, cmap=matplotlib.cm.jet, norm = norm)

This vmin has no effect where if you pass in:

X, Y = meshgrid(arange(20),arange(20))
Z = arange(20*20)
Z = Z.reshape(20,20)
norm = colors.Normalize(vmin=200,vmax=Z.max())
print norm.vmin
fig = figure(10)
ax = fig.add_subplot(111)
surf = ax.contourf(X,Y,Z, 100, cmap=matplotlib.cm.jet, norm = norm)

it has the desired effect.

Let me know if this is correct or I'm missing something here.

Cheers,
Jeff

On Mon, Jul 30, 2012 at 12:32 AM, Eric Firing <ef...@ha...> wrote:

> On 2012/07/28 10:17 PM, Jeffrey Spencer wrote:
>
>> Think I figured out an actual bug in the function: colors.Normalize().
>>
>> The behavior states that if vmin or vmax is passed in as None it should
>> take the minimum or maximum value respectively.
>>
>> If only one value is passed into the function, both values are
>> overwritten to the min and max instead of just the one that is not
>> passed in. So the only case where it sets the limits is if both vmin and
>> vmax are passed to the function. Is this the desired behavior because
>> from the docstring it seems this is incorrect.
>>
>> Cheers,
>> Jeff
>>
>>
>>
> Jeff,
>
> I don't see it, so you need to provide an actual example.  Here is what
> happens (in ipython --pylab) when I try to reproduce what it sounds like
> you are describing:
>
> In [2]: norm = Normalize(vmax=10)
>
> In [3]: norm([-10, 10, 20])
> Out[3]:
> masked_array(data = [ 0.   1.   1.5],
>              mask = False,
>        fill_value = 1e+20)
>
>
> In [4]: norm.vmin
> Out[4]: -10.0
>
> In [5]: norm.vmax
> Out[5]: 10
>
> This behavior is as described in the docstring.
>
> The one potentially confusing aspect that I see at the moment is that the
> Normalize class does not distinguish between explicit vmin, vmax, and the
> values that it calculates via its autoscale_None method when called.  As
> soon as a None is replaced by an actual value, whether by being set
> explicitly or by autoscaling, the replacement is permanent. Perhaps this
> should be made explicit in the docstring.  The docstrings could be
> re-arranged to clarify the roles of the class initializer and its __call__
> method.
>
> Eric
>
>

Re: [Matplotlib-users] Bug in colorbar()

[Eric F. <ef...@ha...>]

On 2012/07/29 5:13 AM, Jeffrey Spencer wrote:
> Eric,
>
> Normalize appears to be working correctly and as you stated above but
> when passed into contourf appears to have inconsistent results not
> following the docstring by allowing the value to change.
>
> Quick examples:
>
> X, Y = meshgrid(arange(20),arange(20))
> Z = arange(20*20)
> Z = Z.reshape(20,20)
> norm = colors.Normalize(vmin=200,vmax=None)
> print norm.vmin
> fig = figure(10)
> ax = fig.add_subplot(111)
> surf = ax.contourf(X,Y,Z, 100, cmap=matplotlib.cm.jet, norm = norm)
>
> This vmin has no effect where if you pass in:
>
> X, Y = meshgrid(arange(20),arange(20))
> Z = arange(20*20)
> Z = Z.reshape(20,20)
> norm = colors.Normalize(vmin=200,vmax=Z.max())
> print norm.vmin
> fig = figure(10)
> ax = fig.add_subplot(111)
> surf = ax.contourf(X,Y,Z, 100, cmap=matplotlib.cm.jet, norm = norm)
>
> it has the desired effect.
>
> Let me know if this is correct or I'm missing something here.
>
> Cheers,
> Jeff

You are correct.  Contour and contourf are respecting vmin, vmax that 
have been set in the norm only if both have been set, so that it is 
fully scaled.  I think that changing this to respect a single preset 
vmin or vmax would be reasonable.

Eric

Re: [Matplotlib-users] Bug in colorbar()

[Jeffrey S. <jef...@gm...>]

I'd agree as then it would work as pcolormesh or imshow does which when
passed in the same norm will only set vmin or vmax that wasn't previously
set.

Assume this would be a really easy fix but I can have a look at submitting
a patch if someone else isn't going to do so just let me know.

Cheers,
Jeff

On Mon, Jul 30, 2012 at 2:31 AM, Eric Firing <ef...@ha...> wrote:

> On 2012/07/29 5:13 AM, Jeffrey Spencer wrote:
>
>> Eric,
>>
>> Normalize appears to be working correctly and as you stated above but
>> when passed into contourf appears to have inconsistent results not
>> following the docstring by allowing the value to change.
>>
>> Quick examples:
>>
>> X, Y = meshgrid(arange(20),arange(20)**)
>> Z = arange(20*20)
>> Z = Z.reshape(20,20)
>> norm = colors.Normalize(vmin=200,**vmax=None)
>> print norm.vmin
>> fig = figure(10)
>> ax = fig.add_subplot(111)
>> surf = ax.contourf(X,Y,Z, 100, cmap=matplotlib.cm.jet, norm = norm)
>>
>> This vmin has no effect where if you pass in:
>>
>> X, Y = meshgrid(arange(20),arange(20)**)
>> Z = arange(20*20)
>> Z = Z.reshape(20,20)
>> norm = colors.Normalize(vmin=200,**vmax=Z.max())
>> print norm.vmin
>> fig = figure(10)
>> ax = fig.add_subplot(111)
>> surf = ax.contourf(X,Y,Z, 100, cmap=matplotlib.cm.jet, norm = norm)
>>
>> it has the desired effect.
>>
>> Let me know if this is correct or I'm missing something here.
>>
>> Cheers,
>> Jeff
>>
>
> You are correct.  Contour and contourf are respecting vmin, vmax that have
> been set in the norm only if both have been set, so that it is fully
> scaled.  I think that changing this to respect a single preset vmin or vmax
> would be reasonable.
>
> Eric
>
>

Re: [Matplotlib-users] Bug in colorbar()

[Eric F. <ef...@ha...>]

On 2012/07/30 1:17 AM, Jeffrey Spencer wrote:
> I'd agree as then it would work as pcolormesh or imshow does which when
> passed in the same norm will only set vmin or vmax that wasn't
> previously set.
>
> Assume this would be a really easy fix but I can have a look at
> submitting a patch if someone else isn't going to do so just let me know.

I will take care of it, thanks.

Eric

>
> Cheers,
> Jeff
>
> On Mon, Jul 30, 2012 at 2:31 AM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
>     On 2012/07/29 5:13 AM, Jeffrey Spencer wrote:
>
>         Eric,
>
>         Normalize appears to be working correctly and as you stated
>         above but
>         when passed into contourf appears to have inconsistent results not
>         following the docstring by allowing the value to change.
>
>         Quick examples:
>
>         X, Y = meshgrid(arange(20),arange(20)__)
>         Z = arange(20*20)
>         Z = Z.reshape(20,20)
>         norm = colors.Normalize(vmin=200,__vmax=None)
>         print norm.vmin
>         fig = figure(10)
>         ax = fig.add_subplot(111)
>         surf = ax.contourf(X,Y,Z, 100, cmap=matplotlib.cm.jet, norm = norm)
>
>         This vmin has no effect where if you pass in:
>
>         X, Y = meshgrid(arange(20),arange(20)__)
>         Z = arange(20*20)
>         Z = Z.reshape(20,20)
>         norm = colors.Normalize(vmin=200,__vmax=Z.max())
>         print norm.vmin
>         fig = figure(10)
>         ax = fig.add_subplot(111)
>         surf = ax.contourf(X,Y,Z, 100, cmap=matplotlib.cm.jet, norm = norm)
>
>         it has the desired effect.
>
>         Let me know if this is correct or I'm missing something here.
>
>         Cheers,
>         Jeff
>
>
>     You are correct.  Contour and contourf are respecting vmin, vmax
>     that have been set in the norm only if both have been set, so that
>     it is fully scaled.  I think that changing this to respect a single
>     preset vmin or vmax would be reasonable.
>
>     Eric
>
>