matplotlib-users Mailing List for matplotlib

On Aug 2, 2005, at 5:30 PM, Danny Shevitz wrote:
> But... your last idea is superb. Why not a different way of doing it? 
> How about instead of a lookup table, I just
> write a colormap that has three user defined functions. Then I could 
> do the thresholding exactly. It seems like
> it would be pretty easy to do. I had originally thought colormaps were 
> needed because graphics drivers had finite resolutions
> so you couldn't put up too many colors. So, if I were to create a 
> "functionColormap" instead of a "linearSegmentedColormap"
> with millions of points in the image is there a danger I would run out 
> of colors or is there some internal rounding or truncation
> to prevent this? If there is no problem, then a new colormap subclass 
> is definately the way to go. I assume it would be slower, but
> I'm not sure it matters.
>
> D
>
Yes, I'm thinking some sort of functional, rather than table lookup, 
version would be useful. The table lookup is fast, but has its 
limitations for this kind of problem. I'll think a bit about it too. 
This kind of request comes up regularly (in one form or another) that 
it deserves some sort of solution.

Perry

>You are right. The problem is that a lookup table is quantized, and the 
>thresholds/intensities are floats.
>In my particular case, what I'm looking at is an image representing 
>arrival times. The problem is that
>the rounded down quantization gives me a peek into the future, which I 
>don't want. The way I am suggesting
>with the ceiling suffers from exactly the same problem, as you mention. If 
>you were looking at lower thresholds
>instead of upper thresholds then the ceiling would fail. That is why I was 
>suggesting a switch for both behaviors.
>Since this is so obscure hardly anyone would use it or even need to know 
>about it.
>
>But... your last idea is superb. Why not a different way of doing it? How 
>about instead of a lookup table, I just
>write a colormap that has three user defined functions. Then I could do 
>the thresholding exactly. It seems like
>it would be pretty easy to do. I had originally thought colormaps were 
>needed because graphics drivers had finite resolutions
>so you couldn't put up too many colors. So, if I were to create a 
>"functionColormap" instead of a "linearSegmentedColormap"
>with millions of points in the image is there a danger I would run out of 
>colors or is there some internal rounding or truncation
>to prevent this? If there is no problem, then a new colormap subclass is 
>definately the way to go. I assume it would be slower, but
>I'm not sure it matters.
>
>D



>>>Danny
>>Isn't the essence of the problem the fact that the thresholds are 
>>specified as floats and the lookup table is quantized by its nature? (And 
>>that the current design allows for arbitrary N.) Whatever value you 
>>specify for a threshold (unless it it 0 or 1) won't necessarily 
>>correspond to a clean boundary between the quantized values (however you 
>>choose to define the boundary: floor, midpoint, or ceiling). Isn't it 
>>possible that your ceiling version has the same problem the other way 
>>(some values that are actually less now show up above the threshold)?
>>
>>I'm wondering if some other approach isn't needed. But before going into 
>>more thought about that I'd like to clarify your usage.
>>
>>Perry Greenfield

On Aug 1, 2005, at 1:07 PM, Danny Shevitz wrote:

> Howdy all,
>
> I have a very obscure (and minor) colormapping issue which I would 
> like to discuss. I am writing a workaround and the question is whether 
> or not this is worth changing the base matplotlib distribution. The 
> issue applies to any code that uses colormapping such as matshow or 
> imshow. I am going to write the change and it is up to the user 
> community whether anyone else in the world cares about this.
>
> In color.py::LinearSegmentedColormap.__call__
> The code that determines the colormap value in the look up table is
>
>         xa = (xa *(self.N-1)).astype(Int)
>         rgba = zeros(xa.shape+(4,), Float)
>         rgba[...,0] = take(self._red_lut, xa)
>         rgba[...,1] = take(self._green_lut, xa)
>         rgba[...,2] = take(self._blue_lut, xa)
>
> I am using colormaps for thresholding data. If the normalized image 
> value is less than some threshold I plot one color, if it is above 
> that threshold, I plot a second color. All images produced this way 
> are two colors. This is just what I do, but the issue is always there 
> for thresholding.
>
> Here's the issue. The code line xa = (xa *(self.N-1)).astype(Int) 
> simply truncates the data, in essence taking the floor of xa, the 
> reason why this matters is that value always get rounded down, so 
> intensities above the threshold all get mapped to the threshold value. 
> The error is small and dependent only on the quantization of the 
> colormap, normally N=256. Nonetheless, there are times, like when the 
> threshold is 0 that the rounded down values are visible and should not 
> be.
>
> The best way to make thresholds get rid of this problem is to use the 
> ceiling function. So the code would read
>         xa = ceil(xa *(self.N-1)).astype(Int)
>
> Then intensities are rounded up, which is safe for thresholding. Note 
> that the original code is not wrong. There  are circumstance when it 
> does the correct thing, even with thresholding. The new line also 
> takes (not much) longer because of the ceil function.
>
> There is a fudge involving only user code, which would be to negate 
> the image data and reverse the colormap, but that is not particularly 
> pretty.
>
> My personal suggestion is to include a flag in the declaration of the 
> colormap:
>
>     def __init__(self, name, segmentdata, N=256, ceiling=False):
> 	self.ceiling = ceiling
>
> then in the __call__ routine:
>
> 	if self.ceiling:
> 	        xa = ceil(xa *(self.N-1)).astype(Int)
> 	else:
> 	        xa = (xa *(self.N-1)).astype(Int)
>
> Let me know what you think.
>
> Danny
>
Isn't the essence of the problem the fact that the thresholds are 
specified as floats and the lookup table is quantized by its nature? 
(And that the current design allows for arbitrary N.) Whatever value 
you specify for a threshold (unless it it 0 or 1) won't necessarily 
correspond to a clean boundary between the quantized values (however 
you choose to define the boundary: floor, midpoint, or ceiling). Isn't 
it possible that your ceiling version has the same problem the other 
way (some values that are actually less now show up above the 
threshold)?

I'm wondering if some other approach isn't needed. But before going 
into more thought about that I'd like to clarify your usage.

Perry Greenfield

>>>>> "John" == John Mariska <ma...@nr...> writes:

Hi John,  I'm CC-ing this response to the matplotlib users list

    John> Dear John, I'm a long-time IDL user who is growing
    John> increasingly attached to matplotlib.  One thing is quite a

On the subject of IDL, if you haven't seen it already, you may be
interested in the IDL cheatsheet for ipython/numerix/matplotlib users
in the appendix of this tutorial
http://www.scipy.org/wikis/topical_software/Tutorial


    John> bother, however, when it comes to preparing publication
    John> quality plots.  When the font size is increased to the size
    John> needed for the shrinkage that a publication quality plot
    John> typically undergoes, the bottom y-axis tick numbering often
    John> either hits or is too close to the first x-axis tick label.
    John> IDL takes care of this by having the bottom y-axis tick
    John> label baseline aligned to the bottom of the plot box, and
    John> the top y-axis tick label aligned so that the top of the
    John> numbers barely rise above the top of the plot box.  The
    John> remaining tick labels are aligned on the tick location.  Is
    John> something like this possible in matplotlib?

This FAQ has some relevant info:
http://matplotlib.sourceforge.net/faq.html#TEXTOVERLAP, which I'll
supplement here.

You can manually set the vertical position of the xicklabels and the
horizontal position of the yticklabels with relative ease.  These
positions are in "axes coordinates" where 0,0 is the bottom left of
the Axes rectangle and 1,1 is the top right.  So you need negative
numbers to position the xticklabels below the axes and yticklabels to
the left.  In pylab, you can set the text properties of the
xticklabels by passing keyword arguments to the "xticks" function 

  xticks(fontsize=20, y=-0.05)

Ditto for the yticks

  yticks(fontsize=20, x=-0.05)

If you are using the matplotlib API, you can first get a list of the
tick labels and then apply setp to them

  from matplotlib.artist import setp
  setp( ax.get_xticklabels(), fontsize=20, y=-0.05)


JDH

On Tuesday 02 August 2005 04:44 am, Alex Rada wrote:
> Hi,
>
> I'm trying to use tex characters on axes label. In particular I want to
> use $\widetilde{xxx}$ command, but I obtain the following error:
>
> matplotlib.pyparsing.ParseException: Found unexpected token, "{" (at
> char 10), (line:1, col:11)
>
> What can I do to avoid this error?

You are using the mathtext module, not TeX, which has partial support for TeX 
characters. See http://matplotlib.sourceforge.net/matplotlib.mathtext.html 
for details.

If you have LaTeX installed, you can set text.usetex = True in your rc 
settings and then LaTeX will be used instead of the mathtext module. See 
http://www.scipy.org/wikis/topical_software/UsingTex for details. 

Unfortunately, there are problems on the windows platform that need to be 
worked out.


-- 

Darren

Hi,

I'm trying to use tex characters on axes label. In particular I want to 
use $\widetilde{xxx}$ command, but I obtain the following error:

matplotlib.pyparsing.ParseException: Found unexpected token, "{" (at 
char 10), (line:1, col:11)

What can I do to avoid this error?

Thanks,

Alex.