Re: [matplotlib-devel] rgba formats
I think I'm a little confused by the question. From the Python perspective, everything in the Agg backend takes floats. Agg actually has color types for both floating point and 8-bit-per-plane colors, though obviously it's converted to 8-bit-per-plane eventually. But, of course, that is done on the fly without much memory copying, so I'm quite surprised that the speed up is significant... Where exactly is this conversion happening, and how are you now avoiding it? (Is this in code that is not checked in, perhaps?) As for the other backends, it's a mixed bag. PDF, PS and Cairo want floats, SVG wants ints. Personally, I just *like* floats better, as it feels more future proof, even though most people aren't using the extra color resolution now. (Of course, if your plot relies on high-resolution color, you probably need to rethink your plot anyway... ;) Cheers, Mike - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] reformatting
Improved consistency is a good thing. And ANSI is a sane choice (even though my muscle memory knows K&R, I'm willing to fight against that for the betterment of the whole... just don't be surprised if I screw some things up initially ;). I do have one concern, however. It is very useful for me to be able to cross-compare the branch to the trunk, and I wouldn't want there to be so many irrelevant differences that that became more difficult. It may be that if astyle was run on both the branch and the trunk that things would still be okay, but I think it's worth checking before committing, just to be sure. We would still have problems diffing into the past on either tree, however. That is perhaps an argument for waiting and only doing this on the branch (once it becomes the trunk). Also, I would suggest that we not reformat any code that was brought in reasonably clean from other sources (Agg, CXX, ttconv). It is useful to diff those files against new versions as they are released. Cheers, Mike - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] reformatting
Michael Droettboom wrote: > > Improved consistency is a good thing. And ANSI is a sane choice > (even though my muscle memory knows K&R, I'm willing to fight against > that for the betterment of the whole... just don't be surprised if I > screw some things up initially ;). > > I do have one concern, however. It is very useful for me to be able > to cross-compare the branch to the trunk, and I wouldn't want there > to be so many irrelevant differences that that became more difficult. > It may be that if astyle was run on both the branch and the trunk > that things would still be okay, but I think it's worth checking > before committing, just to be sure. We would still have problems > diffing into the past on either tree, however. That is perhaps an > argument for waiting and only doing this on the branch (once it > becomes the trunk). This is exactly what I was concerned with, also. We can wait. Why don't you do it (or give me the all-clear) whenever it seems helpful and appropriate. You can choose K&R if you prefer; I have always used ansi because it makes the bracket matching clearest to me, but I recognize that K&R has an advantage in being more compact. Either is OK. > > Also, I would suggest that we not reformat any code that was brought > in reasonably clean from other sources (Agg, CXX, ttconv). It is > useful to diff those files against new versions as they are released. > Agreed, absolutely. Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rgba formats
Michael Droettboom wrote: > I think I'm a little confused by the question. From the Python > perspective, everything in the Agg backend takes floats. Agg > actually has color types for both floating point and 8-bit-per-plane > colors, though obviously it's converted to 8-bit-per-plane > eventually. But, of course, that is done on the fly without much > memory copying, so I'm quite surprised that the speed up is > significant... Where exactly is this conversion happening, and how > are you now avoiding it? (Is this in code that is not checked in, > perhaps?) I was referring to _image.cpp and the quadmesh code in _backend_agg.cpp. Both work directly with agg::rgba8, and can benefit from doing a color table lookup directly in 8-bit space instead of using floats and then converting. Eric > > As for the other backends, it's a mixed bag. PDF, PS and Cairo want > floats, SVG wants ints. Personally, I just *like* floats better, as > it feels more future proof, even though most people aren't using the > extra color resolution now. (Of course, if your plot relies on > high-resolution color, you probably need to rethink your plot > anyway... ;) > > Cheers, Mike - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] RFC on basemap changes
Jeff Whitaker wrote: > 1) an external dependency on the GEOS lib (which is LGPL). Would it be any better to depend on an existing python binding GEOS? Here's one option: http://trac.gispython.org/projects/PCL/wiki/Shapely -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] RFC on basemap changes
Christopher Barker wrote: > > Jeff Whitaker wrote: >> 1) an external dependency on the GEOS lib (which is LGPL). > > Would it be any better to depend on an existing python binding GEOS? > Here's one option: > > http://trac.gispython.org/projects/PCL/wiki/Shapely That is what Jeff started with, but it uses ctypes, and adds complexity to the licensing and the installation. Therefore he wrote his own pyrex binding to the C API of GEOS, which avoids all that and works fine for basemap purposes. Eric > > -Chris > > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] RFC on basemap changes
Christopher Barker wrote: > Jeff Whitaker wrote: > >> 1) an external dependency on the GEOS lib (which is LGPL). >> > > Would it be any better to depend on an existing python binding GEOS? > Here's one option: > > http://trac.gispython.org/projects/PCL/wiki/Shapely > > -Chris > > > Chris: I prototyped the code changes with Shapely (which uses ctypes), then coded my own pyrex replacement, both to get more speed and to avoid depending on ctypes too. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 NOAA/OAR/CDC R/PSD1FAX : (303)497-6449 325 BroadwayBoulder, CO, USA 80305-3328 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
