From: Andrew R. <ar...@ge...> - 2001-11-27 02:39:53
|
At 12:09 AM 27/11/01 +0000, Jo=E3o Cardoso wrote: >On Monday 26 November 2001 20:43, Alan W. Irwin wrote: >| I have a suggestion. Why not add a function to this demo to input >| various image formats and extract the information required by >| plimage? Right now, there is rudimentary support for reading ppm >| images from x20c.c, and I suggest replacing this with the >| appropriate calls to libpbm, libpgm, libpnm, or libppm. > >I have no strong objections to that, except that x20c will depend on=20 >libraries that may not be available on some other systems. In the=20 >first place, unix is not linux, plplot runs also on Macs and=20 >MSWindows, and the purpose of a demo is just showing a capability.=20 >That's the reason why I spend some time coding the reading of the=20 >image, instead of just calling a library. (After all it looks like=20 >that I have objections ;-) I am inclined to agree with Joao here with regards to the concerns of having those libraries available on other systems. I confess that have never looked to see if libpbm etc... are available for DJGPP, thought I expect they would be in some form. What would prove more difficult is evoking external image converter programs on other platforms. I /personally/ think it is perhaps best left as is, with the image command just rendering a user-supplied bitmap, and leaving the supply/generation of that bitmap up to the user. However, if we do want to have INTERNAL loading of bitmaps (not just user-provided ones) there are some other things to consider.=20 With respect to linking to libpbm etc... and letting them do the image reading, and then using external conversion programs to change the format into pbms etc... that almost SETS the preferred image format to the pbm family. Why pick that format over any others ? It is a very easy one to read in a demo like X20c, but isn't necessarily the most flexible or acceptable image format out there. There is almost zero use on platforms outside on unix/linux. We could just as easily (and perhaps more logically), link to libgd, libjpeg, & libpng then read either JPEGs and/or PNG images as the "raw format" supported by plplot, using external image converters to convert other formats (ie the pbm family) to PNGs. In some respect, especially for DOS, windows, and MACs, PNGs have more use, flexibility, and acceptance than the pbm family. Just a thought... - Andrew |
From: Alan W. I. <ir...@be...> - 2001-11-27 07:36:14
|
My motivation here is to have a good-looking demo. Obviously something is not correct about the current method of reading in lena.pgm since the other parts of the demo show that plimage works well, and if I look at lena.pgm directly with kview, that is one heck of a good-looking image....;-) Probably, one could fix up the current pgm input, but I don't see much poin= t to this reincarnation of the libpgm library if we can satisfy the valid cross-platform concerns that you and Joao have expressed another way. Thus, Andrew, I like your suggestion for using png format for our standard input format and using libgd to read it since both are cross-platform. Also as you point out, on Linux the user can convert anything to png format usin= g the netpbm package. I have already used that package in the following way: anytopnm < lena.pgm | pnmtopng > lena.png. The high-quality result was indistinguishable from the original even at high magnification. Thus, I would like to concentrate now on getting proper input of png images for x20c.c so we can have a good-looking result. Now the big question for Andrew: would you be willing to programme png inpu= t to x20c.c using libgd (version 2)? I am willing to do this myself starting tomorrow using libgd version 2.0.1 that is on my Debian woody system, but i= t might take me a while and with your C skills it might be trivial for you to do. Even if you provide just the bare bones of the png reading programme, i= t would help me get a much quicker start. Let me know what you decide. Alan email: ir...@be... phone: 250-727-2902=09FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ On Tue, 27 Nov 2001, Andrew Roach wrote: > At 12:09 AM 27/11/01 +0000, Jo=E3o Cardoso wrote: > >On Monday 26 November 2001 20:43, Alan W. Irwin wrote: > >| I have a suggestion. Why not add a function to this demo to input > >| various image formats and extract the information required by > >| plimage? Right now, there is rudimentary support for reading ppm > >| images from x20c.c, and I suggest replacing this with the > >| appropriate calls to libpbm, libpgm, libpnm, or libppm. > > > >I have no strong objections to that, except that x20c will depend on > >libraries that may not be available on some other systems. In the > >first place, unix is not linux, plplot runs also on Macs and > >MSWindows, and the purpose of a demo is just showing a capability. > >That's the reason why I spend some time coding the reading of the > >image, instead of just calling a library. (After all it looks like > >that I have objections ;-) > > I am inclined to agree with Joao here with regards to the concerns of > having those libraries available on other systems. I confess that have > never looked to see if libpbm etc... are available for DJGPP, thought I > expect they would be in some form. What would prove more difficult is > evoking external image converter programs on other platforms. I > /personally/ think it is perhaps best left as is, with the image command > just rendering a user-supplied bitmap, and leaving the supply/generation = of > that bitmap up to the user. > > However, if we do want to have INTERNAL loading of bitmaps (not just > user-provided ones) there are some other things to consider. > > With respect to linking to libpbm etc... and letting them do the image > reading, and then using external conversion programs to change the format > into pbms etc... that almost SETS the preferred image format to the pbm > family. Why pick that format over any others ? It is a very easy one to > read in a demo like X20c, but isn't necessarily the most flexible or > acceptable image format out there. There is almost zero use on platforms > outside on unix/linux. We could just as easily (and perhaps more > logically), link to libgd, libjpeg, & libpng then read either JPEGs and/o= r > PNG images as the "raw format" supported by plplot, using external image > converters to convert other formats (ie the pbm family) to PNGs. In some > respect, especially for DOS, windows, and MACs, PNGs have more use, > flexibility, and acceptance than the pbm family. Just a thought... > > - Andrew > > > > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: <jca...@in...> - 2001-11-27 16:05:21
|
On Tuesday 27 November 2001 07:35, Alan W. Irwin wrote: | My motivation here is to have a good-looking demo. Obviously | something is not correct about the current method of reading in | lena.pgm Thus, lets correct it. | since the other parts of the demo show that plimage works | well, and if I look at lena.pgm directly with kview, that is one | heck of a good-looking image....;-) Probably, one could fix up the | current pgm input, but I don't see much point to this reincarnation | of the libpgm library if we can satisfy the valid cross-platform | concerns that you and Joao have expressed another way. There is no such reincarnation of libpgm in x20c.c. libpgm has=20 certainly much more functionalities than just reading "lena". | Thus, Andrew, I like your suggestion for using png format for our | standard input format Do we have a standard [image] input format? That is another issue. As=20 Andrew said, there are two issues here: x20c.c and libplplot. As libplplot currently has no API entries to reading/convert images,=20 x20c.c uses a fast and crude way of reading an image, with the=20 purpose of demonstrate a libplplot API. "lena" is generaly available=20 as jpeg. As I *didn't* want to use libgd to read jpeg, I converted it=20 to ppm, which is simple to read. If we are willing to have image reading/convertion in libplplot, than=20 we must start thinking on what we want, why, implement it, and than=20 recode x20c.c to use and *demonstrate* the new libplplot capabilities. But I don't think that plplot should have such image capabilities, as=20 there are enought good quality libraries for that purpose. Instead,=20 the user will write his program, read the image in whatever format he=20 desires, using the method or library he desires, transformate it in=20 whatever way he desires, and then call plimage() to draw it. Thus, I think that one must correct the x20c.c *demo*, and eventually=20 discuss the image operations to add to plplot. Joao | and using libgd to read it since both are | cross-platform. Also as you point out, on Linux the user can | convert anything to png format using the netpbm package. I have | already used that package in the following way: anytopnm < lena.pgm | | pnmtopng > lena.png. The high-quality result was | indistinguishable from the original even at high magnification. | Thus, I would like to concentrate now on getting proper input of | png images for x20c.c so we can have a good-looking result. | | Now the big question for Andrew: would you be willing to programme | png input to x20c.c using libgd (version 2)? I am willing to do | this myself starting tomorrow using libgd version 2.0.1 that is on | my Debian woody system, but it might take me a while and with your | C skills it might be trivial for you to do. Even if you provide | just the bare bones of the png reading programme, it would help me | get a much quicker start. Let me know what you decide. | | Alan | | email: ir...@be... | phone: 250-727-2902=09FAX: 250-721-7715 | snail-mail: | Dr. Alan W. Irwin | Department of Physics and Astronomy, | University of Victoria, P.O. Box 3055, | Victoria, British Columbia, Canada, V8W 3P6 | __________________________ | | Linux-powered astrophysics | __________________________ | | On Tue, 27 Nov 2001, Andrew Roach wrote: | > At 12:09 AM 27/11/01 +0000, Jo=E3o Cardoso wrote: | > >On Monday 26 November 2001 20:43, Alan W. Irwin wrote: | > >| I have a suggestion. Why not add a function to this demo to | > >| input various image formats and extract the information | > >| required by plimage? Right now, there is rudimentary support | > >| for reading ppm images from x20c.c, and I suggest replacing | > >| this with the appropriate calls to libpbm, libpgm, libpnm, or | > >| libppm. | > > | > >I have no strong objections to that, except that x20c will | > > depend on libraries that may not be available on some other | > > systems. In the first place, unix is not linux, plplot runs | > > also on Macs and MSWindows, and the purpose of a demo is just | > > showing a capability. That's the reason why I spend some time | > > coding the reading of the image, instead of just calling a | > > library. (After all it looks like that I have objections ;-) | > | > I am inclined to agree with Joao here with regards to the | > concerns of having those libraries available on other systems. I | > confess that have never looked to see if libpbm etc... are | > available for DJGPP, thought I expect they would be in some form. | > What would prove more difficult is evoking external image | > converter programs on other platforms. I /personally/ think it is | > perhaps best left as is, with the image command just rendering a | > user-supplied bitmap, and leaving the supply/generation of that | > bitmap up to the user. | > | > However, if we do want to have INTERNAL loading of bitmaps (not | > just user-provided ones) there are some other things to consider. | > | > With respect to linking to libpbm etc... and letting them do the | > image reading, and then using external conversion programs to | > change the format into pbms etc... that almost SETS the preferred | > image format to the pbm family. Why pick that format over any | > others ? It is a very easy one to read in a demo like X20c, but | > isn't necessarily the most flexible or acceptable image format | > out there. There is almost zero use on platforms outside on | > unix/linux. We could just as easily (and perhaps more logically), | > link to libgd, libjpeg, & libpng then read either JPEGs and/or | > PNG images as the "raw format" supported by plplot, using | > external image converters to convert other formats (ie the pbm | > family) to PNGs. In some respect, especially for DOS, windows, | > and MACs, PNGs have more use, flexibility, and acceptance than | > the pbm family. Just a thought... | > | > - Andrew | > | > | > | > | > _______________________________________________ | > Plplot-devel mailing list | > Plp...@li... | > https://lists.sourceforge.net/lists/listinfo/plplot-devel | | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2001-11-27 20:29:35
|
On Tue, 27 Nov 2001, [iso-8859-1] Jo=E3o Cardoso wrote: > On Tuesday 27 November 2001 07:35, Alan W. Irwin wrote: > > | Thus, Andrew, I like your suggestion for using png format for our > | standard input format > > Do we have a standard [image] input format? That is another issue. As > Andrew said, there are two issues here: x20c.c and libplplot. Indeed there are two issues. But I think you are misunderstanding me here. My whole e-mail including the sentence you quoted was focussed on improving the x20c.c demo by using png images as the input and had nothing to do with libplplot. > If we are willing to have image reading/convertion in libplplot, than > we must start thinking on what we want, why, implement it, and than > recode x20c.c to use and *demonstrate* the new libplplot capabilities. That's one possibility. Another possibility is to leave plplot strictly al= one and simply enhance x20c.c to make a nice looking demo that the majority of our users can relate to and immediately adapt for their own needs. > > But I don't think that plplot should have such image capabilities, as > there are enought good quality libraries for that purpose. Instead, > the user will write his program, read the image in whatever format he > desires, using the method or library he desires, transformate it in > whatever way he desires, and then call plimage() to draw it. I think I agree with you on the libplplot issue. There are all sorts of excellent arguments for keeping it narrowly focussed on a plotting API without adding extra features that aren't directly related to plotting. So let us forget libplot and concentrate on the x20c.c issue from now on. > > x20c.c uses a fast and crude way of reading an image, with the > purpose of demonstrate a libplplot API. "lena" is generaly available > as jpeg. As I *didn't* want to use libgd to read jpeg, I converted it > to ppm, which is simple to read. I acknowledge your approach seems to work now (from your subsequent e-mail although you haven't checked it in so I cannot see for myself, yet), and also it does have the great advantage of simplicity. Nevertheless, in my view it is too limited an approach. IMHO, part of the point of demos is to allow our users to relate plplot with other work. Thus, I would profoundly disagree with the notion that no special libraries are allowed to be used b= y our examples other than libplplot and friends. Here with x20c we have an outstanding chance to do something really interesting so let us take advantage of the opportunity rather than limiting ourselves. To be specific, right now you limit the x20c demonstration to false colour (using default cmap1) and gray-scale images. With the png approach we can have the demonstration of actual colour images (i.e., scanned photographs o= r whatever). Now in order to work with colour images in plplot you do need the appropriate colour pallette defined for cmap1, but the png format, for example, does allow for up to 256 different colours in a pallette. (png format also has the truecolour alternative, but we must avoid that because plplot would not be able to work with it.) I have just found that the combination of pnmquant and pnmtopng does produce the colour-pallete style png format. Now I have done little coding yet, but from the documentation it looks like the colour pallette is accessible using the libgd library so that for the cost of ~15 extra lines of code in x20c we can demonstrate processing a colour image. With a few lines of commentary in x20c.c we can also advise all our Linux users how to use the netpbm utilities to transfor= m *any* of their favorite colour images into a png image with colour palette that the ~15 lines of libgd-related code in x20c.c could understand. Joao, instead of more discussion about this *before the fact*, let me try t= o implement colour images for x20c in the way I have outlined as a basis for further discussion. If I am successful with the code, and there are no othe= r nasty issues that arise, I hope to convince you that a colour picture of Lena will look better....;-) I have already found a colour version of this test image at http://www.dcs.gla.ac.uk/~wpc/gmm3/web/lena.jpg. Andrew, I assume you haven't yet had a chance to implement a libgd-based image reading routine for x20c so I am just going to go ahead on my own. Alan |
From: Alan W. I. <ir...@be...> - 2001-11-27 21:23:58
|
On Tue, 27 Nov 2001, Alan W. Irwin wrote: > (png > format also has the truecolour alternative, but we must avoid that because > plplot would not be able to work with it.) I have just found that the > combination of pnmquant and pnmtopng does produce the colour-pallete style > png format. Now I have done little coding yet, but from the documentation > it looks like the colour pallette is accessible using the libgd library so > that for the cost of ~15 extra lines of code in x20c we can demonstrate > processing a colour image. With a few lines of commentary in x20c.c we can > also advise all our Linux users how to use the netpbm utilities to transform > *any* of their favorite colour images into a png image with colour palette > that the ~15 lines of libgd-related code in x20c.c could understand. Correction: I have just discovered the gdImageTrueColorToPalette function in libgd which translates an image from truecolour to palette. So strike my comments about netpbm. Everything we need to process colour png images of any type is already in libgd. Alan |
From: <jca...@in...> - 2001-11-28 01:45:44
|
On Tuesday 27 November 2001 21:23, Alan W. Irwin wrote: | On Tue, 27 Nov 2001, Alan W. Irwin wrote: | > (png | > format also has the truecolour alternative, but we must avoid | > that because plplot would not be able to work with it.) I have | > just found that the combination of pnmquant and pnmtopng does | > produce the colour-pallete style png format. Now I have done | > little coding yet, but from the documentation it looks like the | > colour pallette is accessible using the libgd library so that for | > the cost of ~15 extra lines of code in x20c we can demonstrate | > processing a colour image. With a few lines of commentary in | > x20c.c we can also advise all our Linux users how to use the | > netpbm utilities to transform *any* of their favorite colour | > images into a png image with colour palette that the ~15 lines of | > libgd-related code in x20c.c could understand. | | Correction: I have just discovered the gdImageTrueColorToPalette | function in libgd which translates an image from truecolour to | palette. So strike my comments about netpbm. Everything we need | to process colour png images of any type is already in libgd. But I had to compile my libgd, because Suse-7.0 didn't have it! We have irreconciliable opinions in this respect. Joao |
From: <jca...@in...> - 2001-11-28 01:45:45
|
On Tuesday 27 November 2001 20:29, Alan W. Irwin wrote: | On Tue, 27 Nov 2001, [iso-8859-1] Jo=E3o Cardoso wrote: | > On Tuesday 27 November 2001 07:35, Alan W. Irwin wrote: =2E.. | > x20c.c uses a fast and crude way of reading an image, with the | > purpose of demonstrate a libplplot API. "lena" is generaly | > available as jpeg. As I *didn't* want to use libgd to read jpeg, | > I converted it to ppm, which is simple to read. | | I acknowledge your approach seems to work now (from your subsequent | e-mail although you haven't checked it in so I cannot see for | myself, yet), and also it does have the great advantage of | simplicity. Nevertheless, in my view it is too limited an | approach. IMHO, part of the point of demos is to allow our users to | relate plplot with other work. Thus, I would profoundly disagree | with the notion that no special libraries are allowed to be used by | our examples other than libplplot and friends. Here with x20c we | have an outstanding chance to do something really interesting so | let us take advantage of the opportunity rather than limiting | ourselves. You want to write a tutorial; I just want to show that it can be=20 done. You want to write code that users can modify to theirs needs; I=20 just want to show them that it can be done. I profoundly disagree (as you said) on puting library dependencies on=20 demos. It is not a question of being nice to have color images, but a=20 question of software development. What do others think? | To be specific, right now you limit the x20c demonstration to false | colour (using default cmap1) and gray-scale images. With the png | approach we can have the demonstration of actual colour images | (i.e., scanned photographs or whatever). Now in order to work with | colour images in plplot you do need the appropriate colour pallette | defined for cmap1, but the png format, for example, does allow for | up to 256 different colours in a pallette. (png format also has | the truecolour alternative, but we must avoid that because plplot | would not be able to work with it.) I have just found that the | combination of pnmquant and pnmtopng does produce the | colour-pallete style png format. Now I have done little coding | yet, but from the documentation it looks like the colour pallette | is accessible using the libgd library so that for the cost of ~15 | extra lines of code in x20c we can demonstrate processing a colour | image. With a few lines of commentary in x20c.c we can also advise | all our Linux users how to use the netpbm utilities to transform | *any* of their favorite colour images into a png image with colour | palette that the ~15 lines of libgd-related code in x20c.c could | understand. | | Joao, instead of more discussion about this *before the fact*, let | me try to implement colour images for x20c in the way I have | outlined as a basis for further discussion. If I am successful with | the code, and there are no other nasty issues that arise, I hope to | convince you that a colour picture of Lena will look better....;-) | I have already found a colour version of this test image at | http://www.dcs.gla.ac.uk/~wpc/gmm3/web/lena.jpg. In octave: (pplimage not yet cvs commited) file =3D"color-lena.ppm"; fp =3D fopen(file, "r"); ver =3D fscanf(fp, "%s%*c", "C"); a =3D '#'; while (a(1,1) =3D=3D '#') pos =3D ftell(fp); a =3D fgetl(fp); endwhile; fseek(fp, pos); [xx yy max_c] =3D fscanf(fp, "%d%d%d", "C"); img =3D fread(fp, [xx*3 yy], "uchar"); fclose(fp); red =3D reshape (img(1:3:xx*3, :)', xx*yy, 1); green =3D reshape (img(2:3:xx*3,:)', xx*yy, 1); blue =3D reshape (img(2:3:xx*3,:)', xx*yy, 1); plenv(-1,1,-1,1,1,-1); pplimage(red, xx, yy, -1,1,-1,1,-1,1,-1,1) pplimage(green, xx, yy, -1,1,-1,1,-1,1,-1,1) pplimage(blue, xx, yy, -1,1,-1,1,-1,1,-1,1) palette =3D [reshape (red, xx*yy, 1) \ reshape (green, xx*yy, 1) \ reshape (blue, xx*yy, 1) ]; To continue, reducing the palete to 256 colors, I need a definition=20 of what a "near color" to other color is. Joao |
From: Alan W. I. <ir...@be...> - 2001-11-28 03:44:04
|
On Wed, 28 Nov 2001, [iso-8859-1] Jo=E3o Cardoso wrote: > You want to write a tutorial; I just want to show that it can be > done. You want to write code that users can modify to theirs needs; I > just want to show them that it can be done. > > I profoundly disagree (as you said) on puting library dependencies on > demos. It is not a question of being nice to have color images, but a > question of software development. Note, I am leaving in your gray-scale image reading since it now works, and I am simply adding another page for a colour image. We can straightforwardly configure out the colour image reading in x20c.c for the case where the user does not have libgd installed. Thus, I don't believe there is any cause for your concern here since your work is essentially left unaffected. > ....(lots of example code from octave deleted) > To continue, reducing the palete to 256 colors, I need a definition > of what a "near color" to other color is. I am running into a problem with the plimage colour image that may be relevant to your question. The problem is the index range is effectively stored as a floating point number and converted inside plimage to the range 0. --> 1, then a call to plcol1 is made. That is all well and good, but I a= m just starting to review the plcol1 code now to see how the 0. to 1. range i= s mapped to the colour palette index range. For colour images that index mapping has to be exact. If there is an off-by-one error in the resulting index it makes very little difference to gray-scale images since the colour palette is continuous in that case. However, such an error would make a hug= e mess for non-continuous colour palettes that occur for most colour images. = I am getting such a colour mess at the moment (poor Lena has surreal colours!= ) while the identical set of calls to libgd and plimage work fine if the lena.png image is gray-scale. That is why I am looking for off-by-one error= s in plcol1. Alan |
From: Geoffrey F. <fu...@ga...> - 2001-11-30 17:02:57
|
Jo=E3o Cardoso writes: > You want to write a tutorial; I just want to show that it can be=20 > done. You want to write code that users can modify to theirs needs; = I=20 > just want to show them that it can be done. >=20 > I profoundly disagree (as you said) on puting library dependencies o= n=20 > demos. It is not a question of being nice to have color images, but = a=20 > question of software development. >=20 > What do others think? I want to steer clear of any headstrong stance here myself, but I do have some thoughts. I also believe "demos" should be minimalist in their linkage requirements. But I also believe more extended examples could be valuable. I duno if anyone remembers, but long ages ago, I once mentioned that I had hacked a raster capability into a development copy of plplot, using a new plescape hook in xwin.c. I never got around to committing that. The reason (well, among a host of others, including the whole business of finding a hosting arrangement for PLplot) was that that particular program was not only an example of an image display capability, but it was also parallelized, using either Pthreads or MPI. (It was a parallel mandlebrot calculator, displaying to xwin). So it was a /very/ complex example program. I could not figure out how to package an MPI example program into a suitable state for distribution with PLplot. Then the pressures of work diverted my attention until it was effectively abandonded. In general, I guess I favor having some mechanism to exhibit "extensive examples" (potentially with substantial external linking requirements), but I just don't think the "demos" is the right medium for such expositions. In my former case mentioned above, I had always sort of wanted to set up something else, a new class of demos or something. In other words, not call it a demo, but call it a contrib/example/XYZ, or something. So, it seems to me that something similar is waranted in this case too. I agree with both of you. There is a need for demos to be simple, and a need for extensive examples to be exhibited. My suggestion is to somehow think of a packaging technique that puts the extensive, external dependency laden examples, into a seperate collection. Probably each of those has to be separately configured, based on the availability of various --enable-xyz options, drivers, libraries, etc.=20 Because its so much work to set something like that up, that's why I've never done it. =20 Gotta run. --=20 Geoffrey Furnish fu...@ga... |
From: Joao C. <jca...@in...> - 2001-11-30 18:47:44
|
On Friday 30 November 2001 17:02, Geoffrey Furnish wrote: | Jo=E3o Cardoso writes: | > You want to write a tutorial; I just want to show that it can be | > done. You want to write code that users can modify to theirs needs; = I | > just want to show them that it can be done. | > | > I profoundly disagree (as you said) on puting library dependencies o= n | > demos. It is not a question of being nice to have color images, but = a | > question of software development. | > | > What do others think? | | I want to steer clear of any headstrong stance here myself, but I do | have some thoughts. | | I also believe "demos" should be minimalist in their linkage | requirements. But I also believe more extended examples could be | valuable. | | I duno if anyone remembers, but long ages ago, I once mentioned that I | had hacked a raster capability into a development copy of plplot, | using a new plescape hook in xwin.c. I never got around to committing | that. The reason (well, among a host of others, including the whole | business of finding a hosting arrangement for PLplot) was that that | particular program was not only an example of an image display | capability, but it was also parallelized, using either Pthreads or | MPI. (It was a parallel mandlebrot calculator, displaying to xwin). | So it was a /very/ complex example program. I could not figure out | how to package an MPI example program into a suitable state for | distribution with PLplot. Then the pressures of work diverted my | attention until it was effectively abandonded. | | In general, I guess I favor having some mechanism to exhibit | "extensive examples" (potentially with substantial external linking | requirements), but I just don't think the "demos" is the right medium | for such expositions. In my former case mentioned above, I had always | sort of wanted to set up something else, a new class of demos or | something. In other words, not call it a demo, but call it a | contrib/example/XYZ, or something. Yes, of course! I think that this is the solution! | So, it seems to me that something similar is waranted in this case | too. I agree with both of you. There is a need for demos to be | simple, and a need for extensive examples to be exhibited. My | suggestion is to somehow think of a packaging technique that puts the | extensive, external dependency laden examples, into a seperate | collection. Probably each of those has to be separately configured, | based on the availability of various --enable-xyz options, drivers, | libraries, etc. | | Because its so much work to set something like that up, that's why | I've never done it. | | Gotta run. |
From: Alan W. I. <ir...@be...> - 2001-11-30 19:47:08
|
On Fri, 30 Nov 2001, Joao Cardoso wrote: > On Friday 30 November 2001 17:02, Geoffrey Furnish wrote: > | I also believe "demos" should be minimalist in their linkage > | requirements. But I also believe more extended examples could be > | valuable. > | > | [snip] In my former case mentioned above, I had always > | sort of wanted to set up something else, a new class of demos or > | something. In other words, not call it a demo, but call it a > | contrib/example/XYZ, or something. > > Yes, of course! I think that this is the solution! > I agree with the important distinction that Geoffrey has drawn between simple demos and extended examples that may include dependencies on non-plplot libraries. And I agree with having the latter in a separate directory. However, I don't like the name contrib/example because the implication of "contrib" is it was contributed from outside the plplot group, and we don't maintain it or have anything to do with it. So the name I propose is plplot/extended_examples, instead. I don't think we are going to have a lot of extended examples so I propose *not* to divide up plplot/extended_examples into various sub-directories for each of the front-ends like plplot/examples is divided up at the present moment. Directory and file names are always a pain to change in CVS so I will give you a chance to think about the name I have proposed and the flat directory structure below it before I commit anything to CVS tomorrow. Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
From: Maurice L. <mj...@ga...> - 2001-11-30 20:13:15
|
Alan W. Irwin writes: > I agree with the important distinction that Geoffrey has drawn between > simple demos and extended examples that may include dependencies on > non-plplot libraries. And I agree with having the latter in a separate > directory. However, I don't like the name contrib/example because the > implication of "contrib" is it was contributed from outside the plplot > group, and we don't maintain it or have anything to do with it. So the name > I propose is plplot/extended_examples, instead. I don't think we are going > to have a lot of extended examples so I propose *not* to divide up > plplot/extended_examples into various sub-directories for each of the > front-ends like plplot/examples is divided up at the present moment. I greatly prefer plplot/examples/extended or something like that. > Directory and file names are always a pain to change in CVS so I will give > you a chance to think about the name I have proposed and the flat directory > structure below it before I commit anything to CVS tomorrow. Good idea. -- Maurice LeBrun mj...@ga... |
From: Andrew R. <ar...@ge...> - 2001-12-01 02:08:49
|
> >I greatly prefer plplot/examples/extended or something like that. > I like that approach too. Try and keep the name to 8 characters though please, just for us folk stuck DOS 8.3 file names. - Andrew |
From: Joao C. <jca...@in...> - 2001-11-30 20:19:31
|
On Friday 30 November 2001 20:12, Maurice LeBrun wrote: | Alan W. Irwin writes: | > I agree with the important distinction that Geoffrey has drawn betwe= en | > simple demos and extended examples that may include dependencies on | > non-plplot libraries. And I agree with having the latter in a separ= ate | > directory. However, I don't like the name contrib/example because th= e | > implication of "contrib" is it was contributed from outside the plpl= ot | > group, and we don't maintain it or have anything to do with it. So t= he | > name I propose is plplot/extended_examples, instead. I don't think w= e | > are going to have a lot of extended examples so I propose *not* to | > divide up plplot/extended_examples into various sub-directories for = each | > of the front-ends like plplot/examples is divided up at the present | > moment. | | I greatly prefer plplot/examples/extended or something like that. | | > Directory and file names are always a pain to change in CVS so I wil= l | > give you a chance to think about the name I have proposed and the fl= at | > directory structure below it before I commit anything to CVS tomorro= w. | | Good idea. That's OK for me. Anyway, it is difficult to antecipate what kind of=20 subdirectories will be needed. Of course, if the directory becomes crowed, what I don't think will happe= n,=20 it is always possible to move files to subdirectories, as long as the cvs= =20 history is not important, which I don't think will be the case with this = kind=20 of source code. Joao |
From: Maurice L. <mj...@ga...> - 2001-11-30 20:42:40
|
Joao Cardoso writes: > On Friday 30 November 2001 20:12, Maurice LeBrun wrote: > | Alan W. Irwin writes: > | > I agree with the important distinction that Geoffrey has drawn between > | > simple demos and extended examples that may include dependencies on > | > non-plplot libraries. And I agree with having the latter in a separate > | > directory. However, I don't like the name contrib/example because the > | > implication of "contrib" is it was contributed from outside the plplot > | > group, and we don't maintain it or have anything to do with it. So the > | > name I propose is plplot/extended_examples, instead. I don't think we > | > are going to have a lot of extended examples so I propose *not* to > | > divide up plplot/extended_examples into various sub-directories for each > | > of the front-ends like plplot/examples is divided up at the present > | > moment. > | > | I greatly prefer plplot/examples/extended or something like that. > | ... > > That's OK for me. Anyway, it is difficult to antecipate what kind of > subdirectories will be needed. > > Of course, if the directory becomes crowed, what I don't think will happen, > it is always possible to move files to subdirectories, as long as the cvs > history is not important, which I don't think will be the case with this kind > of source code. I envision one subdirectory for each extended (complex) example, since it may be comprised of multiple files: script code, compiled code, its own makefile, data files, a readme file, etc. -- Maurice LeBrun mj...@ga... |
From: <jca...@in...> - 2001-12-04 23:13:05
|
On Friday 30 November 2001 20:23, Maurice LeBrun wrote: | Joao Cardoso writes: | > On Friday 30 November 2001 20:12, Maurice LeBrun wrote: | > | Alan W. Irwin writes: =2E.. | > Of course, if the directory becomes crowed, what I don't think | > will happen, it is always possible to move files to | > subdirectories, as long as the cvs history is not important, | > which I don't think will be the case with this kind of source | > code. | | I envision one subdirectory for each extended (complex) example, | since it may be comprised of multiple files: script code, compiled | code, its own makefile, data files, a readme file, etc. I agree. Whow, shall we have an extended Lena example with a=20 magnifying lens for close (scientific!) inspection? :) Another subject, x20c.c related. I have been looking more closely at the plimage() code. I already=20 knew that it didn't support the standard difilt() transformations for=20 the xwin driver, so I start implementing them. They imply some=20 significant changes to xwin.c! I have them kind of half-baked (!) but=20 still far from ready to commit. x20c can now use the -ori and -wplt=20 command line options, but with some segmentation faults and rough=20 aspect. Thus, as I don't have available time next week, that's better=20 for nobody to start working in xwin.c, DrawImage(), as severe=20 conflits will arise. Joao |
From: Alan W. I. <ir...@be...> - 2001-12-04 23:41:17
|
On Sun, 2 Dec 2001, [iso-8859-1] Jo=E3o Cardoso wrote: > I have been looking more closely at the plimage() code. I already > knew that it didn't support the standard difilt() transformations for > the xwin driver, so I start implementing them. They imply some > significant changes to xwin.c! I have them kind of half-baked (!) but > still far from ready to commit. x20c can now use the -ori and -wplt > command line options, but with some segmentation faults and rough > aspect. Thus, as I don't have available time next week, that's better > for nobody to start working in xwin.c, DrawImage(), as severe > conflits will arise. For some reason sourceforge delayed your message until today so that is why my reply is also today....;-) Anyhow, just to repeat the gist of my previous post, I have no plans to change xwin.c or any other plplot code for image index swaps so xwin.c, etc= =2E are all yours for now as far as I am concerned. Instead, I will be working on finishing the extended example for a colour image which got delayed over the last two days.... Good luck with the final polishing of your difilt transformation stuff for images. Alan email: ir...@be... phone: 250-727-2902=09FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
From: Andrew R. <ar...@ge...> - 2001-11-28 01:40:40
|
>whatever). Now in order to work with colour images in plplot you do need >the appropriate colour pallette defined for cmap1, but the png format, for >example, does allow for up to 256 different colours in a pallette. (png >format also has the truecolour alternative, but we must avoid that because >plplot would not be able to work with it.) Is that /really/ true ? I must confess I have not looked at the code yet (or for months), but I didn't think that plplot /was/ limited to 256 colours. my last look at the colourmap stuff made me think it could easily cope with more than that. The current PNG driver is limited to 256 because the 1.? versions of GD didn't support truecolour, but unless I am mistaken plplot should be "open" enough to support more than 256 colours already. 16.5 million might be pushing it, but all the same... Someone please correct me if I am wrong. >Andrew, I assume you haven't yet had a chance to implement a libgd-based >image reading routine for x20c so I am just going to go ahead on my own. I was sleeping while most of these discussions were going on - you forget, I am on the other side of the world from most of you guys :-) I was going to have a look at it today and see what was to be done. Let me know what progress you're making and let see what happens. Apart from anything else, I have to build GD 2.0.1. I downloaded it last night, and tried a build but ran into problems. Since GD 1.8.? they clobbered the 8.3 naming conventions, so I had to remake the make file fixing up the problems, then to slow things down even more, I discovered that somehow (how or why it happened, I have NO idea) I no longer have libpng's header files so could not recompile the new GD. Once I get those headers back I will have another go at rebuilding the library. - Andrew |
From: Alan W. I. <ir...@be...> - 2001-11-28 03:02:38
|
On Wed, 28 Nov 2001, Andrew Roach wrote: > >whatever). Now in order to work with colour images in plplot you do need > >the appropriate colour pallette defined for cmap1, but the png format, for > >example, does allow for up to 256 different colours in a pallette. (png > >format also has the truecolour alternative, but we must avoid that because > >plplot would not be able to work with it.) > > Is that /really/ true ? I must confess I have not looked at the code yet > (or for months), but I didn't think that plplot /was/ limited to 256 > colours. my last look at the colourmap stuff made me think it could easily > cope with more than that. The current PNG driver is limited to 256 because > the 1.? versions of GD didn't support truecolour, but unless I am mistaken > plplot should be "open" enough to support more than 256 colours already. > 16.5 million might be pushing it, but all the same... Someone please > correct me if I am wrong. I agree plplot can cope with almost arbitrary numbers of colours in cmap1 so it is possible to get rid of the 256 limit in the png driver. However, I was talking about the png format palette limit above and not libgd or cmap1. Sorry for that misunderstanding. For a reference on this 8-bit limit for the png palette, see http://www.w3.org/TR/PNG-Chunks.html#C.IHDR. Later, in an update I did talk about libgd where there is a function called gdImageTrueColorToPalette to convert from truecolor to palette. It is largely undocumented except for the header file so I don't know what the limitations are there on the number of palette indices, but I assume it is pretty likely it conforms to the 256 png limit above. > I was sleeping while most of these discussions were going on - you forget, > I am on the other side of the world from most of you guys :-) I was going > to have a look at it today and see what was to be done. Let me know what > progress you're making and let see what happens. Excellent progress. It truly is just a small number of lines of code. Gray scale works fine and I am close on the colour image as well. See comment I will make to Joao's question about colour images. Alan |
From: <jca...@in...> - 2001-11-27 16:50:07
|
On Tuesday 27 November 2001 16:20, you wrote: | On Tuesday 27 November 2001 07:35, Alan W. Irwin wrote: | | My motivation here is to have a good-looking demo. Obviously | | something is not correct about the current method of reading in | | lena.pgm | | Thus, lets correct it. Done. Just a "char *" to an "unsigned char*" change. I will commit it=20 this night. Joao |
From: Andrew R. <ar...@ge...> - 2001-11-27 11:22:14
|
>My motivation here is to have a good-looking demo. Obviously something is >not correct about the current method of reading in lena.pgm since the other I believe the problem is caused by the fact that the image uses all 256 greyscales, whereas the PNG driver is using CMAP1's 240 greyslots (the other 16 being taken by CMAP0) and at present no translation is being made. So basically everything is moved "down" by 16 indices, and the top 16 are lost. That is an issue that will probably have to be resolved even with GD, although gd quite possibly has in-built functions that would simplify the task. >Now the big question for Andrew: would you be willing to programme png input >to x20c.c using libgd (version 2)? I am willing to do this myself starting >tomorrow using libgd version 2.0.1 that is on my Debian woody system, but it >might take me a while and with your C skills it might be trivial for you to >do. Even if you provide just the bare bones of the png reading programme, it >would help me get a much quicker start. Let me know what you decide. I will have a loot at it tomorrow and see what is involved and get back to you. - Andrew |