matplotlib-devel Mailing List for matplotlib (Page 514)

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
> 
>     Fernando> mmh, just yesterday I was talking to JDH about this: I
>     Fernando> have the feeling that the right place to implement this
>     Fernando> would be to provide colormaps (the beasts lurking
>     Fernando> underneath colorbars) with an easy way to get reversed
>     Fernando> versions.  I don't think that a hack at the level of the
>     Fernando> colorbar function is the right place, design wise, to do
>     Fernando> this.  But I could be wrong...
> 
> Unless I misunderstand, Nicolas and you want different things.  You
> want a reversed color map (eg for the case of jet, red would map to
> small numbers and blue to large numbers).  Nicolas wants a standard
> colormap but with the colorbar display inverted (red would still map
> to large numbers but for vertical colorbars would be on the bottom and
> for horizontal colorbars would be on the left -- the colorbar tick
> labels would change too).

Ah!  Yes, sorry: I did misunderstand Nicolas, probably because I parsed 
his post through the lens of our discussion too quickly.  Sorry for the 
noise...

I wonder though: if we also get 'reversed' colormaps, is this going to 
be a cause for confusion with the 'reversed' colorbar keyword?  It may 
not be a problem in the end, as long as the two different ideas are 
clearly explained, to prevent others falling into the same trap I did.

f

On Wednesday 01 June 2005 18:38, John Hunter wrote:

> Unless I misunderstand, Nicolas and you want different things.  You
> want a reversed color map (eg for the case of jet, red would map to
> small numbers and blue to large numbers).  Nicolas wants a standard
> colormap but with the colorbar display inverted (red would still map
> to large numbers but for vertical colorbars would be on the bottom and
> for horizontal colorbars would be on the left -- the colorbar tick
> labels would change too).
>
> Or am I misunderstanding?
>
At least you understood correctly what I meant ;-)

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:

    Fernando> mmh, just yesterday I was talking to JDH about this: I
    Fernando> have the feeling that the right place to implement this
    Fernando> would be to provide colormaps (the beasts lurking
    Fernando> underneath colorbars) with an easy way to get reversed
    Fernando> versions.  I don't think that a hack at the level of the
    Fernando> colorbar function is the right place, design wise, to do
    Fernando> this.  But I could be wrong...

Unless I misunderstand, Nicolas and you want different things.  You
want a reversed color map (eg for the case of jet, red would map to
small numbers and blue to large numbers).  Nicolas wants a standard
colormap but with the colorbar display inverted (red would still map
to large numbers but for vertical colorbars would be on the bottom and
for horizontal colorbars would be on the left -- the colorbar tick
labels would change too).

Or am I misunderstanding?

JDH

Nicolas Girard wrote:
> Hi all,
> 
> with most of my contours, upper values are on the left side and lower values 
> on the right side ; to the contrary the colorbar (created with 
> orientation='horizontal') displays colors ranging from the lowest to the 
> highest ; this leads to an unpleasant look. (No, I cannot reverse my whole 
> contours, their orientation is important ;-)
> 
> What I'd find useful is a "reverse" option that would make the colorbar 
> display colors ranging from the highest to the lowest ; and I've tried to 
> hack the figure.py file.

mmh, just yesterday I was talking to JDH about this: I have the feeling 
that the right place to implement this would be to provide colormaps 
(the beasts lurking underneath colorbars) with an easy way to get 
reversed versions.  I don't think that a hack at the level of the 
colorbar function is the right place, design wise, to do this.  But I 
could be wrong...

I've been meaning to make some changes to the colormaps code to fix this 
along with a number of other annoyances it has, but I haven't gotten 
around to it yet.

Best,

f

Hi all,

with most of my contours, upper values are on the left side and lower values 
on the right side ; to the contrary the colorbar (created with 
orientation='horizontal') displays colors ranging from the lowest to the 
highest ; this leads to an unpleasant look. (No, I cannot reverse my whole 
contours, their orientation is important ;-)

What I'd find useful is a "reverse" option that would make the colorbar 
display colors ranging from the highest to the lowest ; and I've tried to 
hack the figure.py file.

You'll find the attached patch as a result. apart from fixing a pair of typos 
in the docstring, it allows *colors* of the colorbars to be reversed, but not 
its ticks :-/ 

Then I'm afraid this patch is all but useful... but perhaps it helps getting 
the idea. I'd glad if this feature could be added to the colorbar...

Thanks for reading,

Cheers,
Nicolas

>>>>> "Nicholas" == Nicholas Young <su...@su...> writes:

    Nicholas> Now done in the attached patch, I also added support for
    Nicholas> MxNx3 images; as I suspected these are noticeably slower
    Nicholas> than MxNx4 images but I changed my mind and decided it
    Nicholas> was worth supporting them.

Great, I just committed this to CVS.

Andrew, if you get a minute to update from CVS, can you make sure that
the PIL changes don't cause a problem for your PIL using mpl scripts?

Thanks!
JDH

On Wed, 2005-06-01 at 13:14 +0100, Nicholas Young wrote:
> On Wed, 2005-06-01 at 12:39 +0100, Nicholas Young wrote:
> > On Tue, 2005-05-31 at 10:28 -0500, John Hunter wrote:
> > > >>>>> "Nicholas" == Nicholas Young <su...@su...> writes:
> > > I have mixed feelings about making this a separate class / separate
> > > function.  The current axes imshow / image.AxesImage is already
> > > overloaded (handling MxN, MxNx3, MxNx3, _image.Image and PIL images.
> > > What is the logic of making a special functions/classes case for MxNx4
> > > with directshow.  On the one hand, I appreciate the desire to simplify
> > > the code by pulling it into separate classes and functions.  On the
> > > other hand, I wonder if it will confuse users to have one separate
> > > function for UInt8 images and another for everything else.  Another
> > > worry I have about the separate DirectImage class is that it copies
> > > much of the image resize functionality from AxesImage, including the
> > > broken handling of aspect='preserve'.  This too argues for keeping as
> > > much functionality in AxesImage as possible, testing for A.typecode()
> > > where appropriate.  What do you think?
> 
> Sorry to reply to my own message but I realised just after sending it
> that it didn't make any sense (as MxNx4 images aren't normalised
> anyway).  I now realise that it makes sense to assume that an MxNx4
> UInt8 image will contain pixel data as John suggested and I'll rewrite
> my code to implement this.
> 
> It also occurred  to me that it would make sense to change the PIL code
> to avoid the UInt8 -> Float -> UInt transition.  I'll try implementing
> this after making the alterations John suggested.

Now done in the attached patch, I also added support for MxNx3 images;
as I suspected these are noticeably slower than MxNx4 images but I
changed my mind and decided it was worth supporting them.

I changed the PIL image output to output from PIL RGBX (alpha is 255) or
RGBA images only when converting to a string and then array.  This will
use more memory but, as the conversion to RGBA is done no more than once
and by PIL code (which is probably optimised), should be the fastest
option.  I changed the conversion code to always attempt to convert to
RGBA whenever an unsupported format is given and to raise an error on
catching a ValueError (rather than before trying the conversion); this
adds support for several image types.  I'd also suggest changing the
error raised here to a ValueError rather than a SystemError (as the
error is due to an unsupported value) but haven't in case others are
catching the SystemError.

Additionally I changed the docstring for the imshow function to state
that floating point MxNx3 and MxNx4 arrays aren't normalised (this was
the original source of my earlier confusion).

Nick

On Wed, 2005-06-01 at 12:39 +0100, Nicholas Young wrote:
> On Tue, 2005-05-31 at 10:28 -0500, John Hunter wrote:
> > >>>>> "Nicholas" == Nicholas Young <su...@su...> writes:
> > I have mixed feelings about making this a separate class / separate
> > function.  The current axes imshow / image.AxesImage is already
> > overloaded (handling MxN, MxNx3, MxNx3, _image.Image and PIL images.
> > What is the logic of making a special functions/classes case for MxNx4
> > with directshow.  On the one hand, I appreciate the desire to simplify
> > the code by pulling it into separate classes and functions.  On the
> > other hand, I wonder if it will confuse users to have one separate
> > function for UInt8 images and another for everything else.  Another
> > worry I have about the separate DirectImage class is that it copies
> > much of the image resize functionality from AxesImage, including the
> > broken handling of aspect='preserve'.  This too argues for keeping as
> > much functionality in AxesImage as possible, testing for A.typecode()
> > where appropriate.  What do you think?
> 
> I'm happy for it be be called from imshow but I can't think of a syntax
> to do so which isn't going to be confusing.  The existing variations to
> imshow are all based upon the type of the input image and this won't
> work here - the case of someone who wants to plot a MxNx4 UInt8 array
> and have the values it contains normalised being the problem.  Another
> keyword parameter could be added which only takes effect in this case; I
> thought this likely to confuse but if you prefer it I'm happy.

Sorry to reply to my own message but I realised just after sending it
that it didn't make any sense (as MxNx4 images aren't normalised
anyway).  I now realise that it makes sense to assume that an MxNx4
UInt8 image will contain pixel data as John suggested and I'll rewrite
my code to implement this.

It also occurred  to me that it would make sense to change the PIL code
to avoid the UInt8 -> Float -> UInt transition.  I'll try implementing
this after making the alterations John suggested.

Nick

On Tue, 2005-05-31 at 10:28 -0500, John Hunter wrote:
> >>>>> "Nicholas" == Nicholas Young <su...@su...> writes:
> I have mixed feelings about making this a separate class / separate
> function.  The current axes imshow / image.AxesImage is already
> overloaded (handling MxN, MxNx3, MxNx3, _image.Image and PIL images.
> What is the logic of making a special functions/classes case for MxNx4
> with directshow.  On the one hand, I appreciate the desire to simplify
> the code by pulling it into separate classes and functions.  On the
> other hand, I wonder if it will confuse users to have one separate
> function for UInt8 images and another for everything else.  Another
> worry I have about the separate DirectImage class is that it copies
> much of the image resize functionality from AxesImage, including the
> broken handling of aspect='preserve'.  This too argues for keeping as
> much functionality in AxesImage as possible, testing for A.typecode()
> where appropriate.  What do you think?

I'm happy for it be be called from imshow but I can't think of a syntax
to do so which isn't going to be confusing.  The existing variations to
imshow are all based upon the type of the input image and this won't
work here - the case of someone who wants to plot a MxNx4 UInt8 array
and have the values it contains normalised being the problem.  Another
keyword parameter could be added which only takes effect in this case; I
thought this likely to confuse but if you prefer it I'm happy.

Nick

>>>>> "Nicholas" == Nicholas Young <su...@su...> writes:

    Nicholas> I think it's partly in there in a non-functional form,
    Nicholas> the patch I've attached removes it and adds a new
    Nicholas> function to the Axes class called directshow.  This
    Nicholas> accepts the same syntax as imshow (where relevant)
    Nicholas> rather than adding options to imshow; I chose to do this
    Nicholas> as my old syntax for passing through imshow wasn't that
    Nicholas> easy to understand didn't makes the different
    Nicholas> functionality clear.  This function calls a class call
    Nicholas> DirectImage which inherits from AxesImage.

I have mixed feelings about making this a separate class / separate
function.  The current axes imshow / image.AxesImage is already
overloaded (handling MxN, MxNx3, MxNx3, _image.Image and PIL images.
What is the logic of making a special functions/classes case for MxNx4
with directshow.  On the one hand, I appreciate the desire to simplify
the code by pulling it into separate classes and functions.  On the
other hand, I wonder if it will confuse users to have one separate
function for UInt8 images and another for everything else.  Another
worry I have about the separate DirectImage class is that it copies
much of the image resize functionality from AxesImage, including the
broken handling of aspect='preserve'.  This too argues for keeping as
much functionality in AxesImage as possible, testing for A.typecode()
where appropriate.  What do you think?

Also, note the matplotlib CVS has added several new image
interpolation methods.  Some of these need the parameters

  filternorm=1,
  filterrad=4.0

as described in the imshow docstring.  Since directimage exposes the
interpolation method, shouldn't it also expose these new params.

    Nicholas> I've also rewritten my c++ image object creation
    Nicholas> function called frombyte to take an unsigned byte array
    Nicholas> as input rather than a buffer.  By using the
    Nicholas> std::memcopy function rather than a loop for copying the
    Nicholas> speed advantage of passing data in as a buffer
    Nicholas> disappears and using arrays is generally more intuitive.
    Nicholas> The function still only takes x*y*4 arrays as input at
    Nicholas> the moment as the processor time decrease from not using
    Nicholas> loops to copy is fairly significant.

Looks good to me.  I'll hold off on applying these changes until I
hear from you on the issues above.

Thanks!
JDH

>>>>> "Daishi" == Daishi Harada <da...@eg...> writes:

    Daishi> Hi John, I've uploaded some new files to sourceforge.

    Daishi> On May 26, 2005, at 7:34 PM, John Hunter wrote:
    >> My only suggestions are: 1) move the dash text class to the
    >> text module rather than the axis module (where it seems to
    >> belong since it is a general purpose connector between a text
    >> instance and a point), and

    Daishi> Done. I also slightly modified axes.py to facilitate
    Daishi> providing your suggestion 2).

I've added the changes to CVS text.py revision: 1.27

Thanks again!
JDH

Jeff,

> Eric:  Thanks - contour indeed now seems to work perfectly with masked 
> arrays, but I still have problems with contourf (see attached 
> ortho_test.png).  Unfortunately, neither of your suggested workarounds 
> help, the first makes no difference and the second makes it much worse.
> -Jeff

It is not working in your basemap/examples/contour_demo.py, either, so 
this does not seem to be exclusively a masked array support problem. I 
hope I can figure it out.

Eric

I sent this message sometime on Friday but as it doesn't seem to have made it to the sourceforge list yet I'm assuming it's not going to and trying again.

On Thu, 2005-05-26 at 21:15 -0500, John Hunter wrote:
> >>>>> "Nicholas" == Nicholas Young <su...@su...> writes:
> 
>     Nicholas> Hi, I made a suggestion for improving imshow performance
>     Nicholas> for plotting an image already in byte string form a
>     Nicholas> while ago; some of the results are currently in CVS.  I
>     Nicholas> seems that other changes made to CVS at the same time or
>     Nicholas> since mean that the floating point buffer source code is
>     Nicholas> now much faster and I'd suggest taking anything sourced
>     Nicholas> from my code back out.
> 
> Maybe that explains why I was never able to get the same performance
> benefits you were seeing....  But I was able to get 1.5x - 2.5x faster
> with your patch, which is pretty damned good.  And the memory
> benefit of your patch could be substantial as well.  Why pull it?

When I first tried the new CVS code (other than my own) I was rather
rushed trying to get a paper finished and tested with too small an image
and thus saw too small a speedup for it to be worth it.  I'm also using
non-contiguous arrays which make the relative speed increase smaller.  I
also didn't think the interface was particularly user friendly.

I'm now sure why my code was faster (a mixture of data copying using
optimised functions and no need do floating point to integer conversion)
and have written some new code which is slightly faster than the old and
has a nicer interface (patch to CVS attached).

> What are your latest profiling numbers?

Profiling with my latest version and comparing to CVS I get:
Running with 1024x1024:
Starting array:
  Array set up: resident stack size:  37408, size:  12571
  Tests done: resident stack size:  41536, size:  13596
  Elapsed: 7.674
Starting byte:
  Byte set up: resident stack size:  12876, size:   6429
  Tests done: resident stack size:  12880, size:   6428
  Elapsed: 0.521
Fractional improvement: 13.724


Running with 2048x2048:
Starting array:
  Array set up: resident stack size: 143956, size:  39197
  Tests done: resident stack size: 156252, size:  42269
  Elapsed: 29.577
Starting byte:
  Byte set up: resident stack size:  37464, size:  12573
  Tests done: resident stack size:  37464, size:  12572
  Elapsed: 2.098
Fractional improvement: 13.100


Running with 4096x4096:
Starting array:
  Array set up: resident stack size: 561756, size: 143646
  Tests done: resident stack size: 609388, size: 155963
  Elapsed: 127.401
Starting byte:
  Byte set up: resident stack size:  66376, size:  37178
  Tests done: resident stack size: 132280, size:  37177
  Elapsed: 8.526
Fractional improvement: 13.943


> Your patch came in just at the time I was leaving for Paris for a
> meeting, after which I experienced a rather nasty total hard drive
> failure that set me back in my mpl maintenance.  I am not sure I am
> ready to give up on the ideas you introduced....  Can you remind me --
> did I manage to incorporate all of the matplotlib.axes and
> matplotlib.image patches I needed to take advantage of your patches to
> the _image extension code?

I think it's partly in there in a non-functional form, the patch I've
attached removes it and adds a new function to the Axes class called
directshow.  This accepts the same syntax as imshow (where relevant)
rather than adding options to imshow; I chose to do this as my old
syntax for passing through imshow wasn't that easy to understand didn't
makes the different functionality clear.  This function calls a class
call DirectImage which inherits from AxesImage.

I've also rewritten my c++ image object creation function called
frombyte to take an unsigned byte array as input rather than a buffer.
By using the std::memcopy function rather than a loop for copying the
speed advantage of passing data in as a buffer disappears and using
arrays is generally more intuitive.  The function still only takes x*y*4
arrays as input at the moment as the processor time decrease from not
using loops to copy is fairly significant.

Nick

Eric Firing wrote:

> John,
>
> The attached diff contains a bugfix for the masking problem that Jeff 
> found:
>
> diff -Naur cntr.c_as_sent cntr.c > cntr_bugfix.diff
>
> where cntr.c_as_sent is the old version, cntr.c is the corrected version.
>
> I was simply not transferring the information correctly from the mask 
> to the "reg" array that cntr.c uses; I was setting a value, and then 
> accidentally overwriting it with what should have been an initialization.
>
> With this patch, masked arrays should be handled no better and no 
> worse than before the change from gcntr.c to cntr.c; as far as I know, 
> masking works perfectly for line contours, and it works correctly for 
> filled contours under many but not all circumstances.  I tried two 
> workarounds for the latter problem:
>
> 1) in line 1359 of cntr.c, change the nchunk variable from 30 to a 
> much smaller value.
>     long nchunk = 30; /* hardwired for now */
> This causes the generation of many small polygons, so it may slow 
> things down quite a bit, and it causes the boundaries to look a little 
> glitchy on the screen (gtkagg); but I haven't done timing tests, and I 
> haven't tried other backends.
>
> 2) change the end of ContourSupport._contour_args(), in contour.py:
>
>         self.ax.set_xlim((ma.minimum(x), ma.maximum(x)))
>         self.ax.set_ylim((ma.minimum(y), ma.maximum(y)))
>         # Workaround for cntr.c bug wrt masked interior regions:
>         #if filled:
>         #    z = ma.masked_array(z.filled(-1e38))
>         # It's not clear this is any better than the original bug.
>         return (x, y, z, lev)
>
> The workaround is to uncomment the "if filled:" block.  This method 
> also  works, but can leave some artifacts around the boundary of the 
> bad region.
>
> I am not recommending that either of these workarounds be added to 
> CVS, but if some individual runs into major trouble because of the 
> bug, then either of these methods could be used as a stopgap on an 
> individual basis.
>
> Eric
>

Eric:  Thanks - contour indeed now seems to work perfectly with masked 
arrays, but I still have problems with contourf (see attached 
ortho_test.png).  Unfortunately, neither of your suggested workarounds 
help, the first makes no difference and the second makes it much worse. 

-Jeff

-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/CDC1        FAX   : (303)497-6449
325 Broadway                Web   : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

John,

The attached diff contains a bugfix for the masking problem that Jeff found:

diff -Naur cntr.c_as_sent cntr.c > cntr_bugfix.diff

where cntr.c_as_sent is the old version, cntr.c is the corrected version.

I was simply not transferring the information correctly from the mask to 
the "reg" array that cntr.c uses; I was setting a value, and then 
accidentally overwriting it with what should have been an initialization.

With this patch, masked arrays should be handled no better and no worse 
than before the change from gcntr.c to cntr.c; as far as I know, masking 
works perfectly for line contours, and it works correctly for filled 
contours under many but not all circumstances.  I tried two workarounds 
for the latter problem:

1) in line 1359 of cntr.c, change the nchunk variable from 30 to a much 
smaller value.
     long nchunk = 30; /* hardwired for now */
This causes the generation of many small polygons, so it may slow things 
down quite a bit, and it causes the boundaries to look a little glitchy 
on the screen (gtkagg); but I haven't done timing tests, and I haven't 
tried other backends.

2) change the end of ContourSupport._contour_args(), in contour.py:

         self.ax.set_xlim((ma.minimum(x), ma.maximum(x)))
         self.ax.set_ylim((ma.minimum(y), ma.maximum(y)))
         # Workaround for cntr.c bug wrt masked interior regions:
         #if filled:
         #    z = ma.masked_array(z.filled(-1e38))
         # It's not clear this is any better than the original bug.
         return (x, y, z, lev)

The workaround is to uncomment the "if filled:" block.  This method also 
  works, but can leave some artifacts around the boundary of the bad region.

I am not recommending that either of these workarounds be added to CVS, 
but if some individual runs into major trouble because of the bug, then 
either of these methods could be used as a stopgap on an individual basis.

Eric

John Hunter wrote:
>>>>>>"Jeff" == Jeff Whitaker <js...@fa...> writes:
> 
> 
>     Jeff> The basemap toolkit relies on the 'badmask' parameter in
>     Jeff> contour/contourf to mask out areas outside the desired map
>     Jeff> projection region in matplotlib 0.80.  It works quite
>     Jeff> well. Unfortunately, the new masked array support in CVS
>     Jeff> doesn't (I get all kinds of weird artifacts, especially for
>     Jeff> contourf but also for contour).  Can the old badmask
>     Jeff> functionality be added back in for 0.81, at least
>     Jeff> temporarily until the masked array support stabilizes?
> 
> I don't have anything to add to this, I'm just replying so I can CC
> Eric Firing, who added the masked array support to contour, because I
> don't know if he is on the devel list.
> 
> JDH

John, Jeff,

Yes, I am on the matplotlib-devel list.

Coincidentally, while walking in to work yesterday, a possible 
workaround for the long-standing contourf mask bug occurred to me.  In 
the process of testing it, I found that masking was not working as 
expected for either contour or contourf.  I had done a little testing 
before sending in cntr.c and related changes, but obviously I missed the 
problem then.  The cause should be quite simple and localized. I think I 
can track it down and come up with a clean fix, so that at worst only 
the original contourf bug remains (and maybe the workaround for that 
will, indeed, work).  Please allow me a little time to work on this.

Eric

John Hunter wrote:
>>>>>>"Jeff" == Jeff Whitaker <js...@fa...> writes:
> 
> 
>     Jeff> The basemap toolkit relies on the 'badmask' parameter in
>     Jeff> contour/contourf to mask out areas outside the desired map
>     Jeff> projection region in matplotlib 0.80.  It works quite
>     Jeff> well. Unfortunately, the new masked array support in CVS
>     Jeff> doesn't (I get all kinds of weird artifacts, especially for
>     Jeff> contourf but also for contour).  Can the old badmask
>     Jeff> functionality be added back in for 0.81, at least
>     Jeff> temporarily until the masked array support stabilizes?
> 
> I don't have anything to add to this, I'm just replying so I can CC
> Eric Firing, who added the masked array support to contour, because I
> don't know if he is on the devel list.
> 
> JDH

>>>>> "Jeff" == Jeff Whitaker <js...@fa...> writes:

    Jeff> The basemap toolkit relies on the 'badmask' parameter in
    Jeff> contour/contourf to mask out areas outside the desired map
    Jeff> projection region in matplotlib 0.80.  It works quite
    Jeff> well. Unfortunately, the new masked array support in CVS
    Jeff> doesn't (I get all kinds of weird artifacts, especially for
    Jeff> contourf but also for contour).  Can the old badmask
    Jeff> functionality be added back in for 0.81, at least
    Jeff> temporarily until the masked array support stabilizes?

I don't have anything to add to this, I'm just replying so I can CC
Eric Firing, who added the masked array support to contour, because I
don't know if he is on the devel list.

JDH

The basemap toolkit relies on the 'badmask' parameter in 
contour/contourf to mask out areas outside the desired map projection 
region in matplotlib 0.80.   It works quite well. Unfortunately, the new 
masked array support in CVS doesn't (I get all kinds of weird artifacts, 
especially for contourf but also for contour).  Can the old badmask 
functionality be added back in for 0.81, at least temporarily until the 
masked array support stabilizes?

-Jeff

-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/CDC1        FAX   : (303)497-6449
325 Broadway                Web   : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

Hi John,

I've uploaded some new files to sourceforge.

On May 26, 2005, at 7:34 PM, John Hunter wrote:
> My only suggestions
> are: 1) move the dash text class to the text module rather than the 
> axis
> module (where it seems to belong since it is a general purpose
> connector between a text instance and a point), and

Done. I also slightly modified axes.py to facilitate providing
your suggestion 2).

> 2) provide an example
> which uses a generic text instance in addition to the one you provided
> using a tick label text instance.

Please see the new example, which I'm attaching below.
As I note in the script which generated the plot, the various
rotations are meant to show the possibilities, rather than
for visual appeal.

> As for the alignment problems (in agg or ps at least), they may be a
> result of sf bugs #1194018 and #1177396.

I also think the current rendering when separate rotations for
the text and the dash are specified is suboptimal (I show
examples of this in the new example plot), but the current code
satisfies my immediate use case, so I'm hoping that if/as this
extension gets incorporated into the matplotlib codebase,
others will find that improving the current rotation/transformation
logic will be an itch that they want to scratch.

Thx,
d

ps. FWIW, the last letter in my name is an 'i', not an 'a'.
(I edited the CHANGELOG to reflect this)

>>>>> "Daishi" == Daishi Harada <da...@eg...> writes:

    Daishi> Please let me know if there are any modifications to the
    Daishi> patch which would make it a better candidate for
    Daishi> incorporation into the mainline source.

Hey Daishi,

That is certainly a nice patch and a funky example -- well done.

I was very pleased to see that you added this as a general text
feature and not a feature of text ticks only.  My only suggestions
are: 1) move the dash text class to the text module rather than the axis
module (where it seems to belong since it is a general purpose
connector between a text instance and a point), and 2) provide an example
which uses a generic text instance in addition to the one you provided
using a tick label text instance.

Changes are in CVS -- perhaps you can send me a patch against the
latest revision?

As for the alignment problems (in agg or ps at least), they may be a
result of sf bugs #1194018 and #1177396.

Thanks!
JDH

>>>>> "Nicholas" == Nicholas Young <su...@su...> writes:

    Nicholas> Hi, I made a suggestion for improving imshow performance
    Nicholas> for plotting an image already in byte string form a
    Nicholas> while ago; some of the results are currently in CVS.  I
    Nicholas> seems that other changes made to CVS at the same time or
    Nicholas> since mean that the floating point buffer source code is
    Nicholas> now much faster and I'd suggest taking anything sourced
    Nicholas> from my code back out.

Maybe that explains why I was never able to get the same performance
benefits you were seeing....  But I was able to get 1.5x - 2.5x faster
with your patch, which is pretty damned good.  And the memory
benefit of your patch could be substantial as well.  Why pull it?
What are your latest profiling numbers?

Your patch came in just at the time I was leaving for Paris for a
meeting, after which I experienced a rather nasty total hard drive
failure that set me back in my mpl maintenance.  I am not sure I am
ready to give up on the ideas you introduced....  Can you remind me --
did I manage to incorporate all of the matplotlib.axes and
matplotlib.image patches I needed to take advantage of your patches to
the _image extension code?

JDH

Hi,

I've posted a patch on sourceforge that extends tick
labels to allow for a dash of user-specified length
to come between the text label and the actual tick.

I'm attaching an example plot below. (The script
to generate this example is on sourceforge).

The alignment of the dash with the text is less
than ideal in the PNG output, but it appears that
the font-metrics are backend dependent - the
quality of the alignment seems to differ based
on the selected backend.

Please let me know if there are any modifications
to the patch which would make it a better candidate
for incorporation into the mainline source.

Thanks,
d

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> I'm guessing TeX will meet most layout needs. For example,
    Darren> I just discovered the \over command, which will generate
    Darren> fractions in TeX and LaTeX. \frac only works for LaTeX. I
    Darren> will make tex/latex an rc param if you want. Let me know.

frac was the only use case I thought important.  If over can do it I
am fine leaving it as TeX.  We can generalize later if need be.

JDH

On Tuesday 24 May 2005 5:27 pm, you wrote:
> >>>>> "Darren" =3D=3D Darren Dale <dd...@co...> writes:
>
>     Darren> This is expected behavior for PSfrag. You should instead
>     Darren> wrap \includegraphics in either a \resizebox or a
>     Darren> \scalebox to rescale the text with the figure.
>
> Can you do this?

Yes. backend_latex writes this command to the .tex file, hopefully to guide=
=20
users on how to scale their images:

\scalebox{1}{\includegraphics{<myfile.eps>}}

>
>     Darren> It looks like tex_demo.py, without caching, takes about
>     Darren> 30% longer with LaTeX than it does for Tex (3 seconds vs
>     Darren> 2.3 seconds on my computer). So CVS is back to using
>     Darren> TeX. We may want to include a link (or a copy) of this pdf
>     Darren> on the MPL website:
>     Darren> http://www.csit.fsu.edu/~mimi/tex/tex-refcard.pdf, the
>     Darren> source declares it to be freely distributed.
>
> Can tex|latex be an rc param?

I'm guessing TeX will meet most layout needs. For example, I just discovere=
d=20
the \over command, which will generate fractions in TeX and LaTeX. \frac on=
ly=20
works for LaTeX. I will make tex/latex an rc param if you want. Let me know.

Darren

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> This is expected behavior for PSfrag. You should instead
    Darren> wrap \includegraphics in either a \resizebox or a
    Darren> \scalebox to rescale the text with the figure.

Can you do this?

    Darren> It looks like tex_demo.py, without caching, takes about
    Darren> 30% longer with LaTeX than it does for Tex (3 seconds vs
    Darren> 2.3 seconds on my computer). So CVS is back to using
    Darren> TeX. We may want to include a link (or a copy) of this pdf
    Darren> on the MPL website:
    Darren> http://www.csit.fsu.edu/~mimi/tex/tex-refcard.pdf, the
    Darren> source declares it to be freely distributed.

Can tex|latex be an rc param?

JDH