[matplotlib-devel] Include python-enthought-traits when building matplotlib + build patch
Hello guys,
in a joint effort between Debian and Ubuntu on matplotlib packaging,
we were wondering if include the experimental support for
python-enthought-traits.
...
EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
configobj: 4.5.2
enthought.traits: 2.0.5
...
Enthought suite is used a lot in scientific area, so mpl and enth
almost share their users, so have it enabled would be a plus, but we
are mainly interested in generate "no harm", so we'd like to ask you
to confirm that enabling that support won't brake anything (but indeed
provide a valuable asset for users).
Additionally, we have developed a patch for the build process
(attached) that you might be interested in merge in your codebase, in
particular hunk #2 and #3.
Cheers,
Sandro, Benjamin & Jordan
--
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Index: matplotlib-0.98.3/setupext.py
===
--- matplotlib-0.98.3.orig/setupext.py 2008-08-05 17:43:30.063494149 +0200
+++ matplotlib-0.98.3/setupext.py 2008-08-05 17:47:59.774864127 +0200
@@ -47,8 +47,8 @@
basedir = {
'win32' : ['win32_static',],
-'linux2' : ['/usr/local', '/usr'],
-'linux' : ['/usr/local', '/usr',],
+'linux2' : ['/usr'],
+'linux' : ['/usr',],
'cygwin' : ['/usr/local', '/usr',],
'darwin' : ['/sw/lib/freetype2', '/sw/lib/freetype219', '/usr/local',
'/usr', '/sw', '/usr/X11R6'],
@@ -56,8 +56,10 @@
'freebsd5' : ['/usr/local', '/usr'],
'freebsd6' : ['/usr/local', '/usr'],
'sunos5' : [os.getenv('MPLIB_BASE') or '/usr/local',],
-'gnukfreebsd5' : ['/usr/local', '/usr'],
-'gnukfreebsd6' : ['/usr/local', '/usr'],
+'gnukfreebsd5' : ['/usr'],
+'gnukfreebsd6' : ['/usr'],
+'gnukfreebsd7' : ['/usr'],
+'gnukfreebsd8' : ['/usr'],
'aix5' : ['/usr/local'],
}
@@ -977,6 +979,10 @@
tk_inc = os.path.normpath(os.path.join(tk_lib_dir,
'../../include'))
+if not os.path.exists(tk_inc):
+tk_inc = os.path.normpath(os.path.join(tk_lib_dir,
+ '../../../include/tcl' + tk_ver))
+
if not os.path.exists(os.path.join(tk_inc, 'tk.h')):
tk_inc = tcl_inc
@@ -994,10 +1000,10 @@
return tcl_lib, tcl_inc, tk_lib, tk_inc
def hardcoded_tcl_config():
-tcl_inc = "/usr/local/include"
-tk_inc = "/usr/local/include"
-tcl_lib = "/usr/local/lib"
-tk_lib = "/usr/local/lib"
+tcl_inc = "/usr/include/tcl8.4"
+tk_inc = "/usr/include/tcl8.4"
+tcl_lib = "/usr/lib"
+tk_lib = "/usr/lib"
return tcl_lib, tcl_inc, tk_lib, tk_inc
def add_tk_flags(module):
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] clip_on & clip_box in plot()
I think this is a bug created by the conversion from 0.91 to 0.98. I'll look into this and let you know when it has been resolved. Mike Jae-Joon Lee wrote: > Hi, > > The clip_on and clip_box arguments (and maybe clip_path also) in > plot() command seem to have no effect. For example, > > In [29]: p, =plot([1,2,3], clip_on=False) > > In [30]: p.get_clip_on() > Out[30]: True > > > It seems that the line object is created with the given arguments but > gets overwritten later when it is added to the axes (Axes.add_line), > > def add_line(self, line): > ''' > Add a :class:`~matplotlib.lines.Line2D` to the list of plot > lines > ''' > self._set_artist_props(line) > line.set_clip_path(self.patch) > > "line.set_clip_path(self.patch)" update clip_path, clip_box, and clip_on. > > So, isn't it better to do something explicitly when these arguments > are ignored? Maybe to print out some warnings or even raise an > exception, or do not call set_clip_path when clip_* argument is given, > or etc.? > > A slightly related behavior I found unexpected is that set_clip_path() > and set_clip_rect() method also update clip_on. > > Regards, > > -JJ > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] clip_on & clip_box in plot()
This should now be fixed in SVN r6052. Cheers, Mike Jae-Joon Lee wrote: > Hi, > > The clip_on and clip_box arguments (and maybe clip_path also) in > plot() command seem to have no effect. For example, > > In [29]: p, =plot([1,2,3], clip_on=False) > > In [30]: p.get_clip_on() > Out[30]: True > > > It seems that the line object is created with the given arguments but > gets overwritten later when it is added to the axes (Axes.add_line), > > def add_line(self, line): > ''' > Add a :class:`~matplotlib.lines.Line2D` to the list of plot > lines > ''' > self._set_artist_props(line) > line.set_clip_path(self.patch) > > "line.set_clip_path(self.patch)" update clip_path, clip_box, and clip_on. > > So, isn't it better to do something explicitly when these arguments > are ignored? Maybe to print out some warnings or even raise an > exception, or do not call set_clip_path when clip_* argument is given, > or etc.? > > A slightly related behavior I found unexpected is that set_clip_path() > and set_clip_rect() method also update clip_on. > > Regards, > > -JJ > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Include python-enthought-traits when building matplotlib + build patch
On Thu, Aug 28, 2008 at 6:19 AM, Sandro Tosi <[EMAIL PROTECTED]> wrote: > Enthought suite is used a lot in scientific area, so mpl and enth > almost share their users, so have it enabled would be a plus, but we > are mainly interested in generate "no harm", so we'd like to ask you > to confirm that enabling that support won't brake anything (but indeed > provide a valuable asset for users). Well, one thing to make sure of is that you do not install the version of traits that ships with matplotlib, since it will break other enthought packages. My understanding is that one either uses the default rc config or the traits enabled one. Since the latter is experimental and we are not sure if we will eventually adopt it, I would not recommend enabling it in the debian distro. Is this your view Darren? JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Change in linestyle='steps' between 0.91 and 0.98
linestyle='steps' has changed behaviour between 0.91.2 and 0.98.3. The 'step' between two points used to move horizontally and then vertically from the left point neighbouring right point, now it moves vertically then horizontally. Was this change intentional? I hope not, because I've just spent the past hour working out it was the reason for my plotting routines not working properly :-/ Neil - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Change in linestyle='steps' between 0.91 and 0.98
Now I see there are more options in 0.98 - 'steps-pre', 'steps-post', 'steps-mid'. The default should be steps-post for backwards compatibility. In 0.98.3 the default is steps-pre. And sorry for the testy tone of the previous email :) Neil 2008/8/28 Neil Crighton <[EMAIL PROTECTED]>: > linestyle='steps' has changed behaviour between 0.91.2 and 0.98.3. The > 'step' between two points used to move horizontally and then > vertically from the left point neighbouring right point, now it moves > vertically then horizontally. > > Was this change intentional? I hope not, because I've just spent the > past hour working out it was the reason for my plotting routines not > working properly :-/ > > Neil > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] hist patch (r6055)
Hi, I just committed a patch that allows for multiple histogram where each data-set might have a different length (see example histogram_demo_extended.py). I don't think that it breaks any existing code, but I would feel much better if someone could check that ... Manuel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] irregularly spaced grids and imshowm: PATCH for bilinear interp
Hi John, Hi Eric, In case this has slipped under the radar, I repost my patch for bilinear interp in NonUniformImage (including the discussion around it). I think Eric is the most concerned by this, but you were both on holidays when I raised the issue in matplotlib newsgroup. Best regards, Greg. - Thanks a lot for reviewing my patch! I have corrected most of the problems (I think ;-) ) I indeed introduced memory leak, I think it is fixed now, I have also reorganized the code to avoid duplication of the cleanup code. I used an helper function instead of the goto, because this cleanup is needed for normal exit too, so the helper function can come in handy for that. std::vector would have been nice, but I tried to respect the original coding style, maybe this could be changed but I guess the original author should have something to say about it Only thing I did not change is the allocation of acols/arows even when they are not used. It is not difficult to do, but the code will be a little more complex and I think that the extra memory used is not significant: The memory for those mapping structure is doubled (1 float and 1 int vector of size N, instead of a single int vector of size N), but those mapping structures are an order of magnitude smaller than the image buffer of size N*N of 4 char anyway... If one agree that this is to be saved at the (slight) expense of code conciseness/simplicity, I can add this optimisation... Thanks for pointing the error at the left/bottom pixel lines, it is corrected now :-) And I set interpolation to NEAREST by default, so that the behavior of NonUniformImage remains the same as before if the user do not specify otherwise (I forgot to do it in the first patch)... I include the new patch, Best regards, Greg. On Fri, 2008-08-15 at 15:45 -0400, Michael Droettboom wrote: > Thanks for all the work you put into this patch. > > As you say, it would be nice to have a generic framework for this so > that new types of interpolation could be easily added and to be able to > support arbitrary (non-axis-aligned) quadmeshes as well. But that's > even more work -- if we keep waiting for everything we want, we'll never > get it... ;) I agree that Agg probably won't be much help with that. > > There are a couple of comments with the patch as it stands --> > > There seems to be a gap extrapolating over the left and bottom edge (see > attached screenshot from pcolor_nonuniform.py). > > Memory management looks problematic, some of which I think you inherited > from earlier code. For example, arows and acols are never freed. > Personally, I think these temporary buffers should be std::vector's so > they'll be free'd automatically when scope is left. It might also be > nice to move all of the Py_XDECREF's that happen when exceptions are > thrown to either a master try/catch block or an "exit" goto label at the > bottom. The amount of duplication and care required to ensure > everything will be freed by all of the different exit paths is a little > cumbersome. > > Also, acols and arows are only used in BILINEAR interpolation, but they > are allocated always. > > Once these issues are addressed, it would be great to have someone who > *uses* the nonuniform pcolor functionality (Eric Firing?) have a look at > this patch for any regressions etc.. Assuming none, I'll be happy to > commit it (but I won't be around for a week or so). > > Cheers, > Mike > > Grégory Lielens wrote: > > Hi all, > > > > here is a patch which implement bilinear interpolation on irregular grid > > ( i.e. it allows NonUniformImage > > to accept both 'nearest' and 'bilinear' interpoaltion, instead of only > > 'nearest'.) > > > > It is not perfect, given the current architecture of the image module I > > think there is not simple way > > to specify other interpolations (except for 'nearest', all > > interpolations are implemented at the AGG level, not in > > matplotlib itself). > > For the same reason, it is not possible to interpolate before colormap > > lookup instead of after (and this > > is usually where the biggest effect is, when dealing with coarse grid). > > However, I think it is already quite useful and the best one ca do > > without a -very- extensive rewrite > > of the matrix map modules > > > > BTW, I think it also corrects a small bug in the 'nearest' > > interpolation: the last intervals was ignored > > in the CVS version, now it is taken into account. > > > > BOTH nearest and bilinear interpolation do the same for values oustside > > the data grid: they just use boundary values (constant extrapolation). > > I avoided linear extrapolation for 'bilinear', as extrapolation is > > usually dangerous or meaningless (we can go outside the colormap very > > fast)... > > > > I have included a small example showing how both interpolation works > > > > Any remarks, could this be added before the next release? ;-) > > > > > > Greg. > > > > > > >
Re: [matplotlib-devel] Include python-enthought-traits when building matplotlib + build patch
On Thu, Aug 28, 2008 at 08:17:26AM -0500, John Hunter wrote: > On Thu, Aug 28, 2008 at 6:19 AM, Sandro Tosi <[EMAIL PROTECTED]> wrote: > > Enthought suite is used a lot in scientific area, so mpl and enth > > almost share their users, so have it enabled would be a plus, but we > > are mainly interested in generate "no harm", so we'd like to ask you > > to confirm that enabling that support won't brake anything (but indeed > > provide a valuable asset for users). > Well, one thing to make sure of is that you do not install the version > of traits that ships with matplotlib, since it will break other > enthought packages. Debian and Ubuntu are doing the right thing here currently. This is very nice, as it provides a clean upgrade path for traits under Debian derivatives. Gaël - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Change in linestyle='steps' between 0.91 and 0.98
Sorry about that, and thanks for your investigation. It's easy enough to change the default. I think (and it was a while ago, so I may be misremembering) I probably made that change myself in error. (There used to be two completely separate code paths for doing step plots, that I merged into one). Any objections? Is it possible that change was made deliberately (to conform with matlab or gnuplot etc.)? Cheers, Mike Neil Crighton wrote: > Now I see there are more options in 0.98 - 'steps-pre', 'steps-post', > 'steps-mid'. The default should be steps-post for backwards > compatibility. In 0.98.3 the default is steps-pre. And sorry for the > testy tone of the previous email :) > > Neil > > 2008/8/28 Neil Crighton <[EMAIL PROTECTED]>: > >> linestyle='steps' has changed behaviour between 0.91.2 and 0.98.3. The >> 'step' between two points used to move horizontally and then >> vertically from the left point neighbouring right point, now it moves >> vertically then horizontally. >> >> Was this change intentional? I hope not, because I've just spent the >> past hour working out it was the reason for my plotting routines not >> working properly :-/ >> >> Neil >> >> > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] irregularly spaced grids and imshowm: PATCH for bilinear interp
I'm going to again defer the real question of the functionality and interface etc. to Eric and/or John etc., though it seems good in general. I just have a couple of follow on comments related to implementation details below. Grégory Lielens wrote: > std::vector would have been nice, but I tried to respect the original > coding style, maybe this could be changed but I guess the original > author should have something to say about it > I think we want to use std::vector where possible for new code, and convert as we go through old code. Manual malloc/free is just too error prone. (We're forced to do some by interfacing with Python, but it should be kept to a minimum). Maybe this should be added to the coding guidelines? > Only thing I did not change is the allocation of acols/arows even when > they are not used. It is not difficult to do, but the code will be a > little more complex and I think that the extra memory used is not > significant: The memory for those mapping structure is doubled (1 float > and 1 int vector of size N, instead of a single int vector of size N), > but those mapping structures are an order of magnitude smaller than the > image buffer of size N*N of 4 char anyway... > > If one agree that this is to be saved at the (slight) expense of code > conciseness/simplicity, I can add this optimisation... > I don't understand the complexity. Isn't it as simple as moving: acols = reinterpret_cast(PyMem_Malloc(sizeof(float)*cols)); (and the following NULL check) inside of the "if (interpolation == Image::BILINEAR)" block? Heap allocations can be expensive, so it would be great to minimize them. > Thanks for pointing the error at the left/bottom pixel lines, it is > corrected now :-) > Great! > And I set interpolation to NEAREST by default, so that the behavior of > NonUniformImage remains the same as before if the user do not specify > otherwise (I forgot to do it in the first patch)... > Sounds reasonable -- though perhaps we want to be consistent instead with the standard (uniform) images, which default to the "image.interpolation" setting in matplotlibrc. Of course, "image.interpolation" has a bunch of options that nonuniform doesn't currently support... What do others think? Cheers, Mike > > I include the new patch, > > Best regards, > > Greg. > > On Fri, 2008-08-15 at 15:45 -0400, Michael Droettboom wrote: > >> Thanks for all the work you put into this patch. >> >> As you say, it would be nice to have a generic framework for this so >> that new types of interpolation could be easily added and to be able to >> support arbitrary (non-axis-aligned) quadmeshes as well. But that's >> even more work -- if we keep waiting for everything we want, we'll never >> get it... ;) I agree that Agg probably won't be much help with that. >> >> There are a couple of comments with the patch as it stands --> >> >> There seems to be a gap extrapolating over the left and bottom edge (see >> attached screenshot from pcolor_nonuniform.py). >> >> Memory management looks problematic, some of which I think you inherited >> from earlier code. For example, arows and acols are never freed. >> Personally, I think these temporary buffers should be std::vector's so >> they'll be free'd automatically when scope is left. It might also be >> nice to move all of the Py_XDECREF's that happen when exceptions are >> thrown to either a master try/catch block or an "exit" goto label at the >> bottom. The amount of duplication and care required to ensure >> everything will be freed by all of the different exit paths is a little >> cumbersome. >> >> Also, acols and arows are only used in BILINEAR interpolation, but they >> are allocated always. >> >> Once these issues are addressed, it would be great to have someone who >> *uses* the nonuniform pcolor functionality (Eric Firing?) have a look at >> this patch for any regressions etc.. Assuming none, I'll be happy to >> commit it (but I won't be around for a week or so). >> >> Cheers, >> Mike >> >> Grégory Lielens wrote: >> >>> Hi all, >>> >>> here is a patch which implement bilinear interpolation on irregular grid >>> ( i.e. it allows NonUniformImage >>> to accept both 'nearest' and 'bilinear' interpoaltion, instead of only >>> 'nearest'.) >>> >>> It is not perfect, given the current architecture of the image module I >>> think there is not simple way >>> to specify other interpolations (except for 'nearest', all >>> interpolations are implemented at the AGG level, not in >>> matplotlib itself). >>> For the same reason, it is not possible to interpolate before colormap >>> lookup instead of after (and this >>> is usually where the biggest effect is, when dealing with coarse grid). >>> However, I think it is already quite useful and the best one ca do >>> without a -very- extensive rewrite >>> of the matrix map modules >>> >>> BTW, I think it also corrects a small bug in the 'nearest' >>> interpolation
Re: [matplotlib-devel] clip_on & clip_box in plot()
Thanks! It works as I expected. -JJ On Thu, Aug 28, 2008 at 8:43 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > This should now be fixed in SVN r6052. > > Cheers, > Mike > > Jae-Joon Lee wrote: >> >> Hi, >> >> The clip_on and clip_box arguments (and maybe clip_path also) in >> plot() command seem to have no effect. For example, >> >> In [29]: p, =plot([1,2,3], clip_on=False) >> >> In [30]: p.get_clip_on() >> Out[30]: True >> >> >> It seems that the line object is created with the given arguments but >> gets overwritten later when it is added to the axes (Axes.add_line), >> >>def add_line(self, line): >>''' >>Add a :class:`~matplotlib.lines.Line2D` to the list of plot >>lines >>''' >>self._set_artist_props(line) >>line.set_clip_path(self.patch) >> >> "line.set_clip_path(self.patch)" update clip_path, clip_box, and clip_on. >> >> So, isn't it better to do something explicitly when these arguments >> are ignored? Maybe to print out some warnings or even raise an >> exception, or do not call set_clip_path when clip_* argument is given, >> or etc.? >> >> A slightly related behavior I found unexpected is that set_clip_path() >> and set_clip_rect() method also update clip_on. >> >> Regards, >> >> -JJ >> >> - >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> ___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] opengl backend
On RHEL4, I get the following message: This OpenGL does not support framebuffer objects I understand that I'm probably just suffering from a relatively old Mesa/OpenGL stack here. And obviously, just because some older systems won't support this is not a reason to not include it as an optional backend. Can you possibly send a screen shot to the list for those of us who can't see it? Is the quadmesh interpolated? That would be a huge improvement over anything we can do currently. As for developing a full OpenGL backend, note that the process of writing a backend has been greatly simplified as of 0.98.x (there's only about four rendering methods to implement now, with three more optional ones to re-implement for performance reasons). You can start by looking at backend_bases.py. I'm happy to help with any questions you have as you go along, but as I don't have a working pyglet/OpenGL, I can't be of much help for testing. Cheers, Mike Ryan May wrote: > Paul Kienzle wrote: > >> Hi, >> >> There was a recent discussion about opengl and matplotlib in the >> context of matplotlib rendering speeds. >> >> At the scipy sprints we put together a proof of concept renderer >> for quad meshes using the opengl frame buffer object, which we >> then render as a matplotlib image. Once the data is massaged >> to the correct form we were seeing rendering speeds of about >> 10 million quads per second. See below. >> >> Using this technique we can get the advantage of opengl without >> having to write a full backend. Please let me know if you have >> time to contribute to writing a more complete backend. >> > > I know that I (as the other contributer :) ) plan on making this into a > full backend provided: > > 1) The quadmesh code can be shown yield the gains when integrated into > matplotlib more fully > > 2) I find the time (which is a matter of *when*, not if) > > I'm certainly finding thus far that pyglet makes it a lot easier to do a > full backend than some of the other python->opengl methods I'd explored > in the past. > > Ryan > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] irregularly spaced grids and imshowm: PATCH for bilinear interp
Michael Droettboom wrote: > I think we want to use std::vector where possible for new code, and > convert as we go through old code. Manual malloc/free is just too error > prone. (We're forced to do some by interfacing with Python, but it > should be kept to a minimum). My understanding is that this is exactly the issue -- with std::vector and friends you can't both get the data pointer and create a vector with a data pointer, which would be what you'd want to do to interface efficiently with numpy arrays. I've been looking for a way to address this problem, but my C++ is pretty week. maybe smart pointers and/or other boost classes could help. I do have an idea, though. The goal is a set of classes for working with data that are convenient to use with pure C++, but also play with numpy arrays. I imagine a simple vector/array set of classes build on top of a simple object: a reference counted data block. This data block object would simply hold a pointer to a block of data, maybe know how large it is, maybe know what type the data is, and hold a reference count. when that count drops to zero it deletes itself. The vector/array classes built on top of it would use the data block to store their data, and increment/decrement the reference count as need be. This would allow them to share data, have one array that is a subset of another, using the same data block, etc. It should be easy to build numpy arrays from a system like this. Ideally (but I'm not sure how), the data blocks reference counting system could be integrated with Python's, so that when a numpy array was constructed from one, its reference count would be managed by python as well as your C++ code. But maybe that's all just too much work... -Chris -- 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 [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] a patch to have a correct baseline when usetex=True
Hello,
AFAIK, current backends (I only tested agg, pdf, and ps) do not
properly respect the text baseline when text is rendered using TeX.
The get_text_width_height_descent() method in Agg and PS backends
simply return 0 for the descent value. While PDF backend uses the
dviread module to figure out correct descent values, there are cases
this does not work well (e.g. $\frac{1}{2}\pi$).
As an example, the attached figure shows the result for the Agg
backend. In all cases, the texts are placed at (0,0) with
baseline-alignment. Leftmost one is when usetex=False, which has a
correct baseline. The middle one is when usetex=True. It is bottom
aligned, which is not intended. The rightmost one is also when
usetex=True but after the patch I describe below.
First of all, I borrowed this idea from the PyX which is in GPL.
Although there is little of copying, other than the basic idea, I'm
not 100% sure if this could be BSD-compatible.
Anyhow, the idea is that you can have LateX to print out the width,
height, and descent (=depth) of a given text by enclosing the text in
a box. For example,
\newbox\MatplotlibBox%
\setbox\MatplotlibBox=\hbox{$\frac{1}{2}\pi$}%
\copy\MatplotlibBox
\immediate\write16{MatplotlibBox:\the\wd\MatplotlibBox,\the\ht\MatplotlibBox,\the\dp\MatplotlibBox}%
I define a newbox (called MatplotlibBox) which encloses
$\frac{1}{2}\pi$. And then print out the width, height and depth of
the box.
Attached is a patch of a texmanager.py which utilize above method to
figure out the dimension of the text. The template string to generate
a ".tex" file is slightly modified. After latex is run, the
dimensional information of the text is extracted and saved in
".baseline" file and get_text_width_height_descent() method is added
under the TexManager class, which reads in the ".baseline" file and
return its content. (you need to empty out the tex.cache directory for
this work correctly).
A backend can simply call the get_text_width_height_descent() of
texmanager (a simple patch for the Agg backend is attached). I also
tested this with PS and PDF backends and they worked out fine.
So if the license issue is okay, I wonder if this patch can be
reviewed and applied (after any necessary modifications) to improve
the baseline handling in matploltib.
Regards,
-JJ
<>Index: lib/matplotlib/texmanager.py
===
--- lib/matplotlib/texmanager.py (revision 6055)
+++ lib/matplotlib/texmanager.py (working copy)
@@ -236,6 +236,12 @@
else:
unicode_preamble = ''
+
+
+# newbox, setbox, immediate, etc. are used to find the box
+# extent of the rendered text.
+
+
s = r"""\documentclass{article}
%s
%s
@@ -243,7 +249,10 @@
\usepackage[papersize={72in,72in}, body={70in,70in}, margin={1in,1in}]{geometry}
\pagestyle{empty}
\begin{document}
-\fontsize{%f}{%f}%s
+\newbox\MatplotlibBox%%
+\setbox\MatplotlibBox=\hbox{{\fontsize{%f}{%f}%s}}%%
+\copy\MatplotlibBox
+\immediate\write16{MatplotlibBox:\the\wd\MatplotlibBox,\the\ht\MatplotlibBox,\the\dp\MatplotlibBox}%%
\end{document}
""" % (self._font_preamble, unicode_preamble, custom_preamble,
fontsize, fontsize*1.25, tex)
@@ -283,6 +292,14 @@
fh = file(outfile)
report = fh.read()
fh.close()
+
+# find the box extent information in the latex output
+# file and save them in basefile+".baseline" file
+si = report.find("MatplotlibBox:")
+ssi = si + len("MatplotlibBox:")
+ei = report.find("\n", ssi)
+open(basefile+'.baseline',"w").write(report[ssi:ei])
+
except IOError:
report = 'No latex error report available.'
if exit_status:
@@ -292,6 +309,7 @@
for fname in glob.glob(basefile+'*'):
if fname.endswith('dvi'): pass
elif fname.endswith('tex'): pass
+elif fname.endswith('baseline'): pass
else:
try: os.remove(fname)
except OSError: pass
@@ -441,3 +459,22 @@
self.rgba_arrayd[key] = Z
return Z
+
+
+def get_text_width_height_descent(self, tex, fontsize):
+"""
+return text size in point
+"""
+basefile = self.get_basefile(tex, fontsize)
+baselinefile = '%s.baseline'% basefile
+
+
+if DEBUG or not os.path.exists(baselinefile):
+dvifile = self.make_dvi(tex, fontsize)
+
+# width, height, depth of the bpx
+# depth = descent, and height does not include depth
+l = open(baselinefile).read().split(",")
+width, height, depth = [float(l1[:-2]) for l1 in l] # get rid of "pt"
+
+return width, height+depth, depth
Index: lib/matplotlib/backends/backend_agg.py
===
--- lib/ma
Re: [matplotlib-devel] a patch to have a correct baseline when usetex=True
On Thu, Aug 28, 2008 at 2:57 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: > First of all, I borrowed this idea from the PyX which is in GPL. > Although there is little of copying, other than the basic idea, I'm > not 100% sure if this could be BSD-compatible. I think it is fine to borrow the idea; what we need to do is a clean room implementation with no copying. You can best answer that, so if you tell us your patch is cleanly implemented, we can accept it. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] a patch to have a correct baseline when usetex=True
On Thu, Aug 28, 2008 at 4:18 PM, John Hunter <[EMAIL PROTECTED]> wrote: > On Thu, Aug 28, 2008 at 2:57 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: > >> First of all, I borrowed this idea from the PyX which is in GPL. >> Although there is little of copying, other than the basic idea, I'm >> not 100% sure if this could be BSD-compatible. > > I think it is fine to borrow the idea; what we need to do is a clean > room implementation with no copying. You can best answer that, so if > you tell us your patch is cleanly implemented, we can accept it. > > JDH > Thanks for the response. Well, the only part I borrowed from PyX is TeX related commands they use (there is not much of implementation as far as TeX-related code is concerned). From their code, I learned the meaning and usage of the following TeX commands \newbox \setbox \immediate\write16 And I used the same TeX commands in my code. But I personally think this is not a (code) copy. Other than this, the code is clean. Regards, -JJ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
