On Tue, 2010-04-20 at 09:41 -0500, P Kishor wrote:
> On Tue, Apr 20, 2010 at 9:28 AM, Judd Taylor <[email protected]>
> wrote:
> > Puneet,
> >
> > You are exactly correct. The code generator has a few functions where
> > it pluralizes a function name to indicate that it will operate on
> > piddles of the required args.
> > I just did some quick tests in the perldl shell to verify that this
> > does indeed work, and it does indeed work.
> >
> > When I did the test, the color I used was not a piddle (ie it was a
> > simple perl scalar, with the index of the color that was allocated for
> > that gdImage). This worked due to some of the PDL::PP or threading magic
> > that David was mentioning earlier.
> >
>
> Very nice, but I am unclear about the above sentence...
>
> So, you are saying that in your test, you *didn't* use a piddle for
> the color value (just as David didn't). Is that correct? I would want
> to use a piddle, because I would want a different color for every dot.
> I would calculate the value of the color using the values of the
> variables that I want to map. Actually, ideally, a hypothetical
> command like so would be tremendously useful...
>
> $x = pdl @x; # x coords
> $y = pdl @y, # y coords
> $var = pdl @var; # the var that is to be mapped
> $lut = pdl lookup table; # for every value of $var, retrieve the color
> from the lut
>
> $image->gdImageSetPixels( $x, $y, $var, $lut );
>
Yeah, that will work, too, except you don't need the $var part in there.
When you create the image, you'll need to allocate the colors you're
using, and store the returned indices in a variable. The index values
are what get passed to the functions as the color.
Now, you can do the color allocate step all at once from, say a rainbow
LUT, etc, and then just distill your value down to the index
matmatically, like:
$xs = ...; # from DB
$ys = ...; # from DB
$vals = ...; # from DB
$im->SetPixels( $xs, $ys, lookup( $vals ) );
Where lookup() is a sub you define that maps your vals to your desired
colors.
> from my personal perspective, an even better option would be to
> integrate this with PostGIS like so
>
> 1> $sth->$dbh(prepare("SELECT x, y, var FROM table WHERE whatever");
> 2> my $sth->execute;
> 3> my $res = $sth->fetchall_arrayref;
> 4>
> 5> convert $res to piddle here.
> 6>
> 7> Then,
> 8>
> 9> $image->gdImageSetPixels( $res, $lut );
>
> I can drum up the lines 1 through 8 above myself, but 9 would be a
> very useful addition to the GIS toolbox.
>
Well, that would depend on your version of $res, and your database
engine, and your database design.
Using the explicit parameters is in general safer (you can error check
that you got the required number of params, types of each, etc...),
which is why it's coded like that. Also, if you have an image larger
than 255x255, then the colors will remain a byte type, and the x and y
values will need to be larger integer types.
Going from what you need to do to what you want is pretty trivial, as
far as the calling convention goes. However, for the reasons above, I
don't see it as an improvement on how it already exists.
For the $res part, you can just slice out the X and Y coords and pass it
that way (or change where you convert $res to a piddle so it does a
different piddle for each col).
For the $lut, I'm not certain what you're trying to do. In my
conventions, a lut is a 3x255 byte piddle that contains (in gd talk) a
color allocation table. I would not call a set of values that have
already been looked up in that table a LUT.
A LUT is not part of the SetPixels function, or any of the gd rendering
functions. The color space needs to be setup before you start rendering
things. The reason is that the color space is an image-wide thing, not
something that happens just for a single rendering operation.
As you have it there, there is no mapping between the values you want to
pass in, and what color index should be used for that value (see the
lookup() function, above). I'm guessing you want that to happen
automatically some how in the rendering function... but that's just not
practical as it's 100% application specific to how you want it done.
-Judd
>
>
> > -Judd
> >
> >
> > On Tue, 2010-04-20 at 00:09 -0500, P Kishor wrote:
> >> Hi Judd,
> >>
> >> I am looking for documentation on $image->SetPixels( $x(pdl), $y(pdl),
> >> $color(pdl) ) and other related commands such as
> >> $image->FilledRectangles( $x1(pdl), $y1(pdl), $x2(pdl), $y2(pdl),
> >> $color(pdl) ). Your instructions say that these are aliases for
> >> commands in the GD library that start with 'gdImage', but there is no
> >> gdImageSetPixels in GD. I am assuming the pluralized version sets
> >> pixels at the points represented by the entire piddles, but I can't
> >> grok the usage/syntax for this.
> >>
> >> what is $x(pdl)? Is that a 1D pdl of all the x coords in the image,
> >> essentially a list of x coords? I have gone through the source code of
> >> your module, and I don't see anything except the following --
> >>
> >> # Allow operation on these member function on piddles as well:
> >> #int gdImageGetPixel (gdImagePtr im, int x, int y);
> >> generate_pp_def_members( <<'ENDMEMBERS' );
> >> ..
> >> void gdImageSetPixel (gdImagePtr im, int x, int y, int color);
> >> ..
> >> void gdImageFilledRectangle (gdImagePtr im, int x1, int y1, int x2,
> >> int y2, int color);
> >> ..
> >> ENDMEMBERS
> >>
> > --
> > ____________________________
> > Judd Taylor
> > Software Engineer
> >
> > Orbital Systems, Ltd.
> > 3807 Carbon Rd.
> > Irving, TX 75038-3415
> >
> > [email protected]
> > (972) 915-3669 x127
> >
>
>
>
--
____________________________
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
