Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
On 9/20/2010 6:40 PM, Hazen Babcock wrote: > Schwab,Wilhelm K wrote: >> First, are any of you using plsmem() to obtain graphs w/o saving them to a >> file? Encouragement in the form of success stories or warnings of trouble >> spots would be greatly appreciated. >> >> Another question that has arisen come in the form of image formats readily >> understood by the Smalltalk environment I am using, called Pharo and >> available at http://pharo-project.org/home. I am still struggling slightly >> to understand the various twists, but it appears that it is willing readily >> absorb images made up of RGB and an alpha value (4 bytes per pixel instead >> of 3). >> >> If I am reading thing correctly, I could allocate an array of RGB values, >> let PLplot draw on it, then use a C function to copy the memory into >> RGB+Alpha array for Pharo. Could Smalltalk do the memory manipulation? >> Yes, but there are usually great speed gains to be had by doing such >> looping in C, regardless of the details of how that is accomplished. >> >> The question for you is whether adding an alpha value >> has any interest to the future of PLplot? I think it should be of interest and I would like to see an OpenGL driver to support it. It should be possible to have a very lightweight OpenGL driver supporting both non-interactive and interactive operation (say via a GLUT/FreeGLUT interface for maximum portability and minimum external dependencies). Still on my list to work on when I get enough round tuits --Chris > > I think that an alpha value would be a fine addition to the memory (mem) > driver, but the mem driver is pretty basic and unlikely to get improved > much as we would just be duplicating functionality provided by a number > of different 3rd party graphics libraries. You might also look at the > memcairo driver, as this already supports both alpha values and fills, > as well as unicode fonts, anti-aliasing and a bunch of other nice stuff. > Of course it requires installing the Cairo library which is not always > entirely straightforward depending on your OS. > > Could you describe a little bit more about what you want to do? It > sounds like you already have some sort of language bindings for > Smalltalk, but you'd like to use the graphs in some sort of GUI? On the > off-chance that the Smalltalk GUI is built on GTK I would look at the > extcairo driver, or if it is based on Qt then the extqt driver might be > an option. > > -Hazen > > > -- > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > ___ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel > > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.851 / Virus Database: 271.1.1/3147 - Release Date: 09/20/10 > 02:35:00 > -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
On 2010-09-22 15:32-0700 Alan W. Irwin wrote: > Back in the mists of time, I figured out a way (I think with display > options) to show a semi-transparent background for real, i.e., without > the checkboard and with the desktop (whatever it is) showing through > the plotted image. That was a really cool effect, but I cannot > remember what I did exactly. Has anybody figured out how to do that? Never mind. Google to the rescue. Use the -immutable option for display. However, that doesn't work quite correctly on my current KDE4.4 desktop. The experimental result is complete transparency if the alpha channel is 127 or less and complete opaqeness if the alpha channel is in the range from 128 to 255! I have read elsewhere there are a lot of compositing fixes in KDE4.5 so transparency effects may work better once I upgrade to that. If you have good transparency handling with your desktop you may find the current test_memcairo.py example (with alpha = 200, dark gray background), gives an interesting effect with "display -immutable". But in all cases just middle click with the mouse on some part of the image to find the exact colour and alpha that is meant to be displayed for that part of the image. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
Hi Hazen: On 2010-09-22 10:48-0400 Hazen Babcock wrote: > Schwab,Wilhelm K wrote: >> Alan, Hazen, >> >> I certainly can figure out how to build the library, but it would *really* >> be nice to have it in the plplot9-driver-cairo package. Never hurts to ask >> :) >> >> However, it turns out not to be magic fix, as the memory layout is ARGB vs. >> RGBA: >> >> /* Malloc memory the way cairo likes it. Aligned on the stride computed >> by cairo_format_stride_for_width >> * and in the RGB24 format (from >> http://cairographics.org/manual/cairo-Image-Surfaces.html): >> * Each pixel is a 32-bit quantity, with the upper 8 bits unused. >> * Red, Green, and Blue are stored in the remaining 24 bits in that >> order */ >> >> I need to read up on Pharo, what it calls Rome, and Cairo. If Pharo has or >> grows a Cairo interface, then the above become a non-problem. > > If are willing to use bleeding edge PLplot (v11198), we now have a > function called plsmema() that you can use to pass RGBA formatted memory > to PLplot. You will also have to use the memcairo driver as it is the > only one that can take advantage of memory formatted in this way. Don't > worry though, because when you get the array back from Cairo it will > still be in RGBA format, it doesn't get converted to ARGB. > > examples/python/test_memcairo.py shows how you might use plsmema() and > plsmem() from Python to create plots in memory, then save them as .png > files. I fixed an issue (actually declare plsmema in plplot.h) in revision 11201. Without that fix, some default declaration is used without PLDLLIMPEXP so the build fails for me for my default gcc options (-fvisibility=hidden) and would also fail on Windows for the same reason. Thanks, for creating test_memcairo.py following Simon's lead with test_mem.py. For others here, if you compare results from the two examples you can see why we recommend -dev memcairo over -dev mem. The TrueType fonts, antialiasing, and high-quality filling are huge improvements for -dev memcairo over -dev mem for plsmem RGB results. And, of course, -dev memcairo currently has exclusive access to RGBA as well. As of revision 11202 I have imposed a dark gray background for the example for RGB and dark gray semi-transparent background for the RGBA case. I prefer setting some explicit colour and opacity to test that the memcairo device plots on top of the specific RGB or RGBA background image you supply rather than and all-zero image with black or transparent black background. For the semi-transparent results, the ImageMagick display app displays a checkerboard rather than a semi-transparent background colour. But you can confirm the RGBA colours of the background area by clicking the middle mouse button. That gives the expected results so all seems to be well with this example. Back in the mists of time, I figured out a way (I think with display options) to show a semi-transparent background for real, i.e., without the checkboard and with the desktop (whatever it is) showing through the plotted image. That was a really cool effect, but I cannot remember what I did exactly. Has anybody figured out how to do that? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
Hazen, plsmema() sounds like a/the answer. For the moment (time pressure is mounting), I am going to hack a most-recent-graph temp file, hold my nose and get some work done with a crude interactive plotting capability that will hopefully get me through the next couple of weeks. Thanks! Bill From: Hazen Babcock [hbabc...@mac.com] Sent: Wednesday, September 22, 2010 10:48 AM To: Schwab,Wilhelm K Cc: plplot-devel@lists.sourceforge.net Subject: Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB? Schwab,Wilhelm K wrote: > Alan, Hazen, > > I certainly can figure out how to build the library, but it would *really* be > nice to have it in the plplot9-driver-cairo package. Never hurts to ask :) > > However, it turns out not to be magic fix, as the memory layout is ARGB vs. > RGBA: > > /* Malloc memory the way cairo likes it. Aligned on the stride computed > by cairo_format_stride_for_width > * and in the RGB24 format (from > http://cairographics.org/manual/cairo-Image-Surfaces.html): > * Each pixel is a 32-bit quantity, with the upper 8 bits unused. > * Red, Green, and Blue are stored in the remaining 24 bits in that order > */ > > I need to read up on Pharo, what it calls Rome, and Cairo. If Pharo has or > grows a Cairo interface, then the above become a non-problem. If are willing to use bleeding edge PLplot (v11198), we now have a function called plsmema() that you can use to pass RGBA formatted memory to PLplot. You will also have to use the memcairo driver as it is the only one that can take advantage of memory formatted in this way. Don't worry though, because when you get the array back from Cairo it will still be in RGBA format, it doesn't get converted to ARGB. examples/python/test_memcairo.py shows how you might use plsmema() and plsmem() from Python to create plots in memory, then save them as .png files. -Hazen -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
> If are willing to use bleeding edge PLplot (v11198), we now have a > function called plsmema() that you can use to pass RGBA formatted memory > to PLplot. You will also have to use the memcairo driver as it is the > only one that can take advantage of memory formatted in this way. Don't > worry though, because when you get the array back from Cairo it will > still be in RGBA format, it doesn't get converted to ARGB. > Just a note that PIL appears to support the ARGB format too, so if you're going through python you can use it to reformat the data. See "unpackARGB" in: http://svn.effbot.org/public/tags/pil-1.1.4/libImaging/Unpack.c Simon -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
Schwab,Wilhelm K wrote: > Alan, Hazen, > > I certainly can figure out how to build the library, but it would *really* be > nice to have it in the plplot9-driver-cairo package. Never hurts to ask :) > > However, it turns out not to be magic fix, as the memory layout is ARGB vs. > RGBA: > > /* Malloc memory the way cairo likes it. Aligned on the stride computed > by cairo_format_stride_for_width > * and in the RGB24 format (from > http://cairographics.org/manual/cairo-Image-Surfaces.html): > * Each pixel is a 32-bit quantity, with the upper 8 bits unused. > * Red, Green, and Blue are stored in the remaining 24 bits in that order > */ > > I need to read up on Pharo, what it calls Rome, and Cairo. If Pharo has or > grows a Cairo interface, then the above become a non-problem. If are willing to use bleeding edge PLplot (v11198), we now have a function called plsmema() that you can use to pass RGBA formatted memory to PLplot. You will also have to use the memcairo driver as it is the only one that can take advantage of memory formatted in this way. Don't worry though, because when you get the array back from Cairo it will still be in RGBA format, it doesn't get converted to ARGB. examples/python/test_memcairo.py shows how you might use plsmema() and plsmem() from Python to create plots in memory, then save them as .png files. -Hazen -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
On 9/20/2010 6:40 PM, Hazen Babcock wrote: > Schwab,Wilhelm K wrote: >> First, are any of you using plsmem() to obtain graphs w/o saving them to a >> file? Encouragement in the form of success stories or warnings of trouble >> spots would be greatly appreciated. >> >> Another question that has arisen come in the form of image formats readily >> understood by the Smalltalk environment I am using, called Pharo and >> available at http://pharo-project.org/home. I am still struggling slightly >> to understand the various twists, but it appears that it is willing readily >> absorb images made up of RGB and an alpha value (4 bytes per pixel instead >> of 3). >> >> If I am reading thing correctly, I could allocate an array of RGB values, >> let PLplot draw on it, then use a C function to copy the memory into >> RGB+Alpha array for Pharo. Could Smalltalk do the memory manipulation? >> Yes, but there are usually great speed gains to be had by doing such >> looping in C, regardless of the details of how that is accomplished. >> >> The question for you is whether adding an alpha value >> has any interest to the future of PLplot? I think it should be of interest and I would like to see an OpenGL driver to support it. It should be possible to have a very lightweight OpenGL driver supporting both non-interactive and interactive operation (say via a GLUT/FreeGLUT interface for maximum portability and minimum external dependencies). Still on my list to work on when I get enough round tuits --Chris > > I think that an alpha value would be a fine addition to the memory (mem) > driver, but the mem driver is pretty basic and unlikely to get improved > much as we would just be duplicating functionality provided by a number > of different 3rd party graphics libraries. You might also look at the > memcairo driver, as this already supports both alpha values and fills, > as well as unicode fonts, anti-aliasing and a bunch of other nice stuff. > Of course it requires installing the Cairo library which is not always > entirely straightforward depending on your OS. > > Could you describe a little bit more about what you want to do? It > sounds like you already have some sort of language bindings for > Smalltalk, but you'd like to use the graphs in some sort of GUI? On the > off-chance that the Smalltalk GUI is built on GTK I would look at the > extcairo driver, or if it is based on Qt then the extqt driver might be > an option. > > -Hazen > > > -- > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > ___ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel > > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.851 / Virus Database: 271.1.1/3147 - Release Date: 09/20/10 > 02:35:00 > -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
Alan W. Irwin wrote: > > Hi Hazen: > > The rest of this is directed to you. There is a note in > cmake/modules/drivers-init.cmake that says "memcairo does not work so > turn it off by default". Does memcairo actually work now? If so, you > should remove that note, and turn memcairo on by default just like our > other cairo devices so that users don't have to use -DPLD_memcairo=ON > to access it. Hi Alan, Hm, good question. I remember that initially it had some problems, but it looks like Doug Hunt fixed it up around March 2008. At that time I applied his patch and felt that it was working, though I can't remember how I actually tested it. See the thread at that time titled: "[Plplot-devel] memcairo driver fixes" Looks like it does not support alpha values however. I'll look into remedying that and verifying that it works. Then we can turn it on by default for the next release. -Hazen -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
Alan, Hazen, I certainly can figure out how to build the library, but it would *really* be nice to have it in the plplot9-driver-cairo package. Never hurts to ask :) However, it turns out not to be magic fix, as the memory layout is ARGB vs. RGBA: /* Malloc memory the way cairo likes it. Aligned on the stride computed by cairo_format_stride_for_width * and in the RGB24 format (from http://cairographics.org/manual/cairo-Image-Surfaces.html): * Each pixel is a 32-bit quantity, with the upper 8 bits unused. * Red, Green, and Blue are stored in the remaining 24 bits in that order */ I need to read up on Pharo, what it calls Rome, and Cairo. If Pharo has or grows a Cairo interface, then the above become a non-problem. Thanks! Bill From: Alan W. Irwin [ir...@beluga.phys.uvic.ca] Sent: Tuesday, September 21, 2010 11:24 AM To: Schwab,Wilhelm K; Hazen Babcock Cc: plplot-devel@lists.sourceforge.net Subject: Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB? On 2010-09-21 10:43-0400 Schwab,Wilhelm K wrote: > Hazen, > > Ideally, I would prefer a cross-platform solution, but the reality is that I > work on Linux. Cairo appears to have installed vai apt-get; I have yet to do > anything with it. > > Where should I look for the memcairo driver? Hi Bill: First, make sure our cairo device driver (that contains all sorts of devices including memcairo) works. If your list of devices in the cmake output includes any device with "cairo" in the name, then that means our build system has found the development version pango/cairo libraries needed by our cairo device driver. Otherwise, look for any WARNING messages in your cmake output having to do with pango/cairo and deal with them (normally by installing the developer version of pango and cairo, cleaning out your build tree, and trying again). Once some "*cairo" devices are available, then make the memcairo device available using the cmake option -DPLD_memcairo=ON. Hi Hazen: The rest of this is directed to you. There is a note in cmake/modules/drivers-init.cmake that says "memcairo does not work so turn it off by default". Does memcairo actually work now? If so, you should remove that note, and turn memcairo on by default just like our other cairo devices so that users don't have to use -DPLD_memcairo=ON to access it. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
On 2010-09-21 10:43-0400 Schwab,Wilhelm K wrote: > Hazen, > > Ideally, I would prefer a cross-platform solution, but the reality is that I > work on Linux. Cairo appears to have installed vai apt-get; I have yet to do > anything with it. > > Where should I look for the memcairo driver? Hi Bill: First, make sure our cairo device driver (that contains all sorts of devices including memcairo) works. If your list of devices in the cmake output includes any device with "cairo" in the name, then that means our build system has found the development version pango/cairo libraries needed by our cairo device driver. Otherwise, look for any WARNING messages in your cmake output having to do with pango/cairo and deal with them (normally by installing the developer version of pango and cairo, cleaning out your build tree, and trying again). Once some "*cairo" devices are available, then make the memcairo device available using the cmake option -DPLD_memcairo=ON. Hi Hazen: The rest of this is directed to you. There is a note in cmake/modules/drivers-init.cmake that says "memcairo does not work so turn it off by default". Does memcairo actually work now? If so, you should remove that note, and turn memcairo on by default just like our other cairo devices so that users don't have to use -DPLD_memcairo=ON to access it. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
Schwab,Wilhelm K wrote: > Hazen, > > Ideally, I would prefer a cross-platform solution, but the reality is that I > work on Linux. Cairo appears to have installed vai apt-get; I have yet to do > anything with it. > > Where should I look for the memcairo driver? It is not enabled by default. Does anyone remember why? Anyway, you will have to recompile PLplot, telling cmake to enable the memcairo device, eg: cmake /path/to/plplot_source -DPLD_memcairo=ON The code for the driver is in drivers/cairo.c -Hazen -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
Hazen, Ideally, I would prefer a cross-platform solution, but the reality is that I work on Linux. Cairo appears to have installed vai apt-get; I have yet to do anything with it. Where should I look for the memcairo driver? Bill From: Hazen Babcock [hbabc...@mac.com] Sent: Monday, September 20, 2010 6:40 PM To: Schwab,Wilhelm K Cc: plplot-devel@lists.sourceforge.net Subject: Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB? Schwab,Wilhelm K wrote: > First, are any of you using plsmem() to obtain graphs w/o saving them to a > file? Encouragement in the form of success stories or warnings of trouble > spots would be greatly appreciated. > > Another question that has arisen come in the form of image formats readily > understood by the Smalltalk environment I am using, called Pharo and > available at http://pharo-project.org/home. I am still struggling slightly > to understand the various twists, but it appears that it is willing readily > absorb images made up of RGB and an alpha value (4 bytes per pixel instead of > 3). > > If I am reading thing correctly, I could allocate an array of RGB values, let > PLplot draw on it, then use a C function to copy the memory into RGB+Alpha > array for Pharo. Could Smalltalk do the memory manipulation? Yes, but there > are usually great speed gains to be had by doing such looping in C, > regardless of the details of how that is accomplished. > > The question for you is whether adding an alpha value has any interest to the > future of PLplot? I think that an alpha value would be a fine addition to the memory (mem) driver, but the mem driver is pretty basic and unlikely to get improved much as we would just be duplicating functionality provided by a number of different 3rd party graphics libraries. You might also look at the memcairo driver, as this already supports both alpha values and fills, as well as unicode fonts, anti-aliasing and a bunch of other nice stuff. Of course it requires installing the Cairo library which is not always entirely straightforward depending on your OS. Could you describe a little bit more about what you want to do? It sounds like you already have some sort of language bindings for Smalltalk, but you'd like to use the graphs in some sort of GUI? On the off-chance that the Smalltalk GUI is built on GTK I would look at the extcairo driver, or if it is based on Qt then the extqt driver might be an option. -Hazen -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
Hazen, I have an evolving binding for Pharo, but it currently gives me no choice but to save graphs to disk. It is also allowing me to generate numbers in memory and create graphs from them without turning it all into text and/or fighting with pipes to get to gnuplot, so it's a win even now. memcairo is a new to me, so I will have a look and see if it will do the job. Making a long story short, in an ideal world, I will be able to create an image (RGBA array or whatever makes sense to both systems) in memory, have PLplot scrawl data all over it, and then do further processing without writing a file until it suits me, if ever. It is partly perfectionism, and a lot of removing a potentially troublesome limitation. Things that I might want to do with an image include arraying graphs to create a multi-plot structure that might be much more easily created in Smalltalk than in PLplot, and going directly from data in memory to a preview plot in the IDE. My immediate goal is to hit a proposal deadline, and for that it's fine/preferred to write files. That will change as I turn to more interactive analysis of these and other data sets. Bill From: Hazen Babcock [hbabc...@mac.com] Sent: Monday, September 20, 2010 6:40 PM To: Schwab,Wilhelm K Cc: plplot-devel@lists.sourceforge.net Subject: Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB? Schwab,Wilhelm K wrote: > First, are any of you using plsmem() to obtain graphs w/o saving them to a > file? Encouragement in the form of success stories or warnings of trouble > spots would be greatly appreciated. > > Another question that has arisen come in the form of image formats readily > understood by the Smalltalk environment I am using, called Pharo and > available at http://pharo-project.org/home. I am still struggling slightly > to understand the various twists, but it appears that it is willing readily > absorb images made up of RGB and an alpha value (4 bytes per pixel instead of > 3). > > If I am reading thing correctly, I could allocate an array of RGB values, let > PLplot draw on it, then use a C function to copy the memory into RGB+Alpha > array for Pharo. Could Smalltalk do the memory manipulation? Yes, but there > are usually great speed gains to be had by doing such looping in C, > regardless of the details of how that is accomplished. > > The question for you is whether adding an alpha value has any interest to the > future of PLplot? I think that an alpha value would be a fine addition to the memory (mem) driver, but the mem driver is pretty basic and unlikely to get improved much as we would just be duplicating functionality provided by a number of different 3rd party graphics libraries. You might also look at the memcairo driver, as this already supports both alpha values and fills, as well as unicode fonts, anti-aliasing and a bunch of other nice stuff. Of course it requires installing the Cairo library which is not always entirely straightforward depending on your OS. Could you describe a little bit more about what you want to do? It sounds like you already have some sort of language bindings for Smalltalk, but you'd like to use the graphs in some sort of GUI? On the off-chance that the Smalltalk GUI is built on GTK I would look at the extcairo driver, or if it is based on Qt then the extqt driver might be an option. -Hazen -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
On 2010-09-20 12:08-0400 Schwab,Wilhelm K wrote: > The question for you is whether adding an alpha value has any interest to the future of PLplot? All our new colour work is RBGA. And we have gone to a lot of trouble to make RBGA variants of many of our old colour functions. So patches to add alpha to any RGB-only colour functions that are still left are always welcome so long as you don't introduce backwards incompatibilities (e.g., add new functions rather than varying the argument lists of old ones). Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
Hi Bill: Please don't cross-post between the two PLplot lists. It annoys those that are subscribed to both lists (especially if you receive a lot of replies where people forget to filter out one of the lists). In this case, your post was most relevant to PLplot-devel so I would stick with that for the remainder of the thread. To others here, please remember to filter out plplot-general from your replies. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
Schwab,Wilhelm K wrote: > First, are any of you using plsmem() to obtain graphs w/o saving them to a > file? Encouragement in the form of success stories or warnings of trouble > spots would be greatly appreciated. > > Another question that has arisen come in the form of image formats readily > understood by the Smalltalk environment I am using, called Pharo and > available at http://pharo-project.org/home. I am still struggling slightly > to understand the various twists, but it appears that it is willing readily > absorb images made up of RGB and an alpha value (4 bytes per pixel instead of > 3). > > If I am reading thing correctly, I could allocate an array of RGB values, let > PLplot draw on it, then use a C function to copy the memory into RGB+Alpha > array for Pharo. Could Smalltalk do the memory manipulation? Yes, but there > are usually great speed gains to be had by doing such looping in C, > regardless of the details of how that is accomplished. > > The question for you is whether adding an alpha value has any interest to the > future of PLplot? I think that an alpha value would be a fine addition to the memory (mem) driver, but the mem driver is pretty basic and unlikely to get improved much as we would just be duplicating functionality provided by a number of different 3rd party graphics libraries. You might also look at the memcairo driver, as this already supports both alpha values and fills, as well as unicode fonts, anti-aliasing and a bunch of other nice stuff. Of course it requires installing the Cairo library which is not always entirely straightforward depending on your OS. Could you describe a little bit more about what you want to do? It sounds like you already have some sort of language bindings for Smalltalk, but you'd like to use the graphs in some sort of GUI? On the off-chance that the Smalltalk GUI is built on GTK I would look at the extcairo driver, or if it is based on Qt then the extqt driver might be an option. -Hazen -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
