matplotlib-devel Mailing List for matplotlib

On 8/28/06, Darren Dale <dd...@co...> wrote:
> A while back, I put some effort into rendering an offset ticklabel, which
> allowed the user to do something like
>
> plot(linspace(100000100, 100000200, 100))
>
> and the plot would look like a plot from 0 to 100, with a "+100000100"
> rendered in a new label near the far end of the axis. This doesnt work quite
> as well as it used to, because the axes autoscaling is setting the plot range
> to something like the average plus and minus 6%. I have tried tracing the
> source of this change, but I can't find it. It might be buried in the
> _transforms extension code, and I've never been able to wrap my head around
> mpl's transforms.
> Does anyone know why autoscaling is defaulting to this +-6% range?
I don't know anything about it what happened to the code, but I will
say that +- 6% autoscaling is better than tight bounds for many kinds
of plots. Like a scatter plot. It doesn't look good if some of your
points are right on the axes, with their marker cut in half by the
border. It's always bugged me with Matlab that there was no easy way
to get slightly enlarged bounds on plots, so I'm glad to hear mpl has
added something like that. I'm not sure it should be the default, or
only option though. Some plots are better with tight bounds.
--bb

A while back, I put some effort into rendering an offset ticklabel, which 
allowed the user to do something like
plot(linspace(100000100, 100000200, 100))
and the plot would look like a plot from 0 to 100, with a "+100000100" 
rendered in a new label near the far end of the axis. This doesnt work quite 
as well as it used to, because the axes autoscaling is setting the plot range 
to something like the average plus and minus 6%. I have tried tracing the 
source of this change, but I can't find it. It might be buried in the 
_transforms extension code, and I've never been able to wrap my head around 
mpl's transforms.
Does anyone know why autoscaling is defaulting to this +-6% range? Does it 
have to be this way? I'm trying to improve the scalar formatter (supporting 
engineering notation, cleaning up the code).
Thanks,
Darren

Chris,
Thanks for the cross-post. I'm not sure this approach will help 
speed up the wxAgg accelerator, but I'll put it on the list of things 
to look into. The problem I foresee is that the Agg renderer's RGBA 
data has to be converted to RGB before a wxImage can be created by 
convert_agg2image().
Ken
On Aug 18, 2006, at 6:14 PM, Christopher Barker wrote:
> As a probably final installment in the thread about optimizing the wx
> back-end, here is a post from the wxPython list, in which someone 
> posted
> SWIG code for making a PyBuffer from his data set, then using it to
> create a wx.Image without copying. A similar approach could be used 
> for
> the wxAgg back-end.
>
> -Chris
>
> -------- Original Message --------
> Subject: [wxPython-users] Re: using wxImage in C++ python extension
> Date: 2006年8月18日 16:48:08 +0000 (UTC)
> From: Andrew Murray <and...@st...>
> Reply-To: wxP...@li...
> To: wxp...@li...
> References: <200...@uc...>
> <44E...@al...> <200...@uc...>
> <44E...@no...> <44E...@al...>
> <44E...@no...>
>
> Hi all :)
>
> I've followed the combined advice of Robin and Christopher in using 
> a python
> buffer object to instance a wx.Image in the python wrapper layer. It
> all seems
> to be working - and I don't think there are any 'data copies' going 
> on ;)
>
> To keep my underlying C++ python-free, I introduced the buffer (and
> creation of
> the wx.Image) via my .i Swig file. In case anyone who is reading is
> keen trying
> to solve a similar problem, I've included the code that I added to 
> my .i
> file in
> order to implement the change below. (I'd appreciate any comments 
> regarding
> errors or shortcomings that anyone spots in my implementation.)
>
> Sorry I didn't reply to the thread earlier. A combination of being 
> tied
> up with
> more boring work, moving house and background research into using 
> python
> buffers
> with Swig means that I've only just got this far.
>
> One remaining question I have is: Does the call to wx.EmptyImage 
> that I make
> cause any memory to be allocated? I see from Robin's recent post 
> that in my
> case this call is now redundant (as I will soon be using
> ImageFromBuffer) - but
> I'm curious to know the answer anyway ;)
>
> Thanks for all the help. The more I use wxPython the more I like 
> it...
>
> Andrew ;)
>
>
> /* the RawImage C++ class that we are wrapping offers a method that
> returns a pointer to an internal 'unsigned char' buffer of display
> data. To make the python class generated by SWIG a bit more
> friendly to the rest of our wxPython code we instruct SWIG to make
> two modifications during the wrapping process. First we add a
> method to the C++ class that will return a version of the internal
> display buffer wrapped up as a 'python buffer object' (performing
> this in the C++ wrapper class keeps the wrapped C++ python- 
> free)...
> */
> %extend RawImage {
> 	PyObject* RawImage::getDisplayBuffer(void) {
> 		// return a new 'python buffer object' that intialised using
> 		// the memory address and length of our display buffer...
> 		void* pvBufferData = (void*)self->pcGetDisplayData();
> 		int iBufferSize = self->getDisplayBufferSize();
> 		return PyBuffer_FromMemory(pvBufferData, iBufferSize);
> 	}
> }
> /* ... we also add a method to the python wrapper class that will use
> the buffer offered by our new C++ method to create a wx.Image
> (neither of these methods actually copies the image data)...
> */
> %extend RawImage {
> %pythoncode %{
> def getImage(self):
> # create an unintialised wx.Image of the correct size...
> wximage = wx.EmptyImage(self.getWidth(), self.getHeight(), 
> clear=False)
> # then define the data content of the image...
> wximage.SetDataBuffer(self.getDisplayBuffer())
> return wximage
> %}
> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxP...@li...
> For additional commands, e-mail: wxPython-users- 
> he...@li...
>
>
> -- 
> Christopher Barker, Ph.D.
> Oceanographer
> 		
> NOAA/OR&R/HAZMAT (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chr...@no...
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services, 
> security?
> Get stuff done quickly with pre-integrated technology to make your 
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel