Puneet, Thanks for posting your experiences in using this module.
I think I should first give a little background on the development of this module. I first created this module to handle PNG image i/o for remote sensing applications, using piddles for holding the data. For my uses, I only need the non-object oriented functions (write_png(), etc). After using it for years outside of the PDL proper, I decided that I would contribute this to the main PDL distribution, along with the other modules I was contributing all at the same time. After a quick look at the capabilities of the full GD library, I decided it wasn't too cool to contribute something with a name of PDL::IO::GD that only did a tiny portion of what the GD C library is capable of doing. At this point I wrote the object oriented interface, using mostly code generators based on the GD C library header file. It can do everything GD can do now, and in an object oriented fashion, to boot. The original and OO interfaces are what makes up PDL::IO::GD now. As far as authorship, I wrote and maintain that module. CPAN may list something else, as I'm still not certain all the permissions on the modules I've contributed for release with the rest of PDL are pointing to me yet. I'll need to check into all of that to see what's up. As far as documentation problems, it sounds like something went wrong with your build of the .pd file, which autogenerates most of the OO functions, and autogenerates the documentation as well. The PDL online docs don't show any placeholders as you describe: http://pdl.sourceforge.net/PDLdocs/IO/GD.html However, I'm not certain that filling in the placeholders with autogenerated docs is going to be much better. The real reference is the GD library documentation itself: http://www.boutell.com/gd/ I don't think that redocumenting the entire GD library is very practical, as it's pretty huge, and well documented at the C level. The autogenerated documentation aims to relate how you would call a function in PDL::IO::GD to where you can look up the real documentation for the underlying C function that gets called. Another reason against redocumenting inside PDL::IO::GD is that the actual behavior of some of the functions will depend on what version of the GD C library is installed on your system, and Perl/PDL has no control over that. All the module does is tie into the C library, and so (to me, at least), it only makes sense to document how it ties in. I'll take a look and see if I can't replicate your doc generation problem, as if that doesn't work, then it needs to be fixed. Finally, for your database problem. If I was using Class::DBI, I would do a: foreach ( DBI::FooTable->search({ $var => $want_val }) ) { $im->plot( $color, $_->x, $_->y ); } (with the exception that there using the PDL interface you've been talking about would probably be able to get around using that explicit foreach loop) I think you're using something similar to Class::DBI, so it should be possible to do the same type of thing within the framework of the package you're using. I think you should use the database engine to do the searching through the data, as it is built for doing just that, and it should be more reliable and (possibly a lot) faster than doing it directly in perl or PDL. Do a select unique records on the $var column, and then do a select on each of the unique values of that column, and then plot the results. Thanks, Judd On Mon, 2010-04-19 at 09:45 -0500, P Kishor wrote: > I have three generic questions about PDL's interface with GD -- I am > motivated by the logic that if I am confused, other n00bs will also be > confused -- and an actual methodology question. > > 1. (Very minor point). PDL::IO::GD's author is listed as "Judd Taylor" > and yet, it appears under the "Chris Marshall" namespace.. well, > actually, the PDL namespace which is under Chris Marshall as the > author. I guess that may be because all the PDL packages appear under > http://search.cpan.org/~chm/PDL-2.4.6_001/, but I wonder if there > might be some better way to "brand" them. Perhaps under the "Author" > section list the actual authors' name *with* some clarifying text. > > 2. (Minor point). Why are PDL's interfaces with various graphics > libraries under PDL::Graphics::*, but PDL's interface with GD is under > PDL::IO::*. On top of that, PDL::IO::GD is actually listed under the > "Documentation" sub-heading rather than under the "Modules" > sub-heading. This is fairly confusion inducing. Is there a method to > this madness? Shouldn't this be under the "Modules" sub-heading, and > named as PDL::Graphics::GD? > > 3. (Major point). Right now, at least on the Mac, at least for me, PDL > is severely crippled because of its (my) inability to successfully > build PDL with either PGPLOT or with PLplot. However, PDL::IO::GD > works very well, but is also severely crippled because of its almost > non-existent documentation. Almost a third of the documentation > consists of "$image->INSERT_NAME_HERE( INSERT_DOC_ARG_LIST_HERE )" > which doesn't help, and also lacks a lot in terms of generating > confidence in a n00b. To the extent that I have been able to figure it > out, PDL and GD seem to work very well, so it would be really nice to > have good docs for it. I would be happy to write up the docs *if* I > can figure out myself. I have been poring through the source code, but > if I really had to read the source code of libgd to understand how to > use it, it would be pointless trying to use Perl. > > 4. Finally, my question re. using PDL::IO::GD. I have a PDL > constructed out of a query from a db. It looks like so > $a = [ > [$var, $x, $y] > [$var, $x, $y] > .. > ]; > > I want to create a lookup table based on the values of $var (a generic > lookup table might not help, because the values may be very different > for different vars), and generate an image coloring every $x and $y > pixel in the image based on the value of $var and its corresponding > color in the lut. How do I go about doing that? > > Many thanks in advance, > -- ____________________________ Judd Taylor Software Engineer Orbital Systems, Ltd. 3807 Carbon Rd. Irving, TX 75038-3415 [email protected] (972) 915-3669 x127 _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
