Now, to fit the other parts of the chain together.

Would be nice to have comments/annotation in that code.

BEGIN {
    my %map = (
         255 => sub{         0,             0,   $_[0] * 255 },
         510 => sub{         0,     $_[0]*255,           255 },
         765 => sub{         0,           255, (1-$_[0])*255 },
        1020 => sub{ $_[0]*255,           255,             0 },
        1275 => sub{       255, (1-$_[0])*255,             0 },
        1530 => sub{       255,             0,     $_[0]*255 },
        1785 => sub{       255,     $_[0]*255,           255 },
    );
    my @map = sort{ $::a <=> $::b } keys %map;
    sub colorRamp1785 {
        my( $v, $vmin, $vmax ) = @_;

        ## Peg $v to $vmax if it is greater than $vmax
        $v = $vmax if $v > $vmax;

        ## Or peg $v to $vmin if it is less tahn $vmin.
        $v = $vmin if $v < $vmin;

        ## Normalise $v relative to $vmax - $vmin
        $v = ( $v - $vmin ) / ( $vmax - $vmin );

        ## Scale it to the range 0 .. 1784
        $v *= 1785;

        ## And look up the appropriate rgb value
        ## And pack that into a 32-bit integer compatible with GD true
+color
        $v < $_ and return rgb2n( $map{ $_ }->( $v % 255 / 256 ) ) for
+ @map;
    }
}
[download]

The code provides a single function colorRamp1785() which takes 3 parameters:

1. $v: is the numeric value to map to a color on the color ramp.
2. $vmin is the minimum value $v will take. This will be mapped to the color black (rgb:0,0,0).
3. $vmax is the maximum value $v will take. This will be mapped to the color white (rgb:255,255,255)
• The sub pegs $v to $vmin or $vmax if it lies beyond their range.
• It then normalises $v in terms of the range between $vmin & $vmax.

  Ie. If you pass in ( 150, 100, 200 ), the $v becomes 0.5

• It then scales that to the 0 .. 1784 range of the color ramp

  Continuing the above example, $v now becomes 1785 * 0.5 = 892.5.

• Looks up the appropriate rgb value for that point on the color ramp

  Rather than having a huge 1785 entry lookup table, it uses a hash of subs to perform the mapping.

  • If the value is less than 256, then it represents the blue value directly with red and green both 0.

    $v = 0 => rgb(0,0,0); 1 => rgb(0,0,1); ... 255 => rgb(0,0,255)

    The color transitions from black to blue.

  • If the value is 256 .. 511, then (mod 256) it represents the green value directly with red = 0 and blue = 255.

    $v = 256 => rgb(0,0,255); 257 => rgb(0,1,255); ... 511 => rgb(0,255,255)

    The color transitions from blue to cyan.

  • If the value is 512 .. 783, then (mode 256) it inversely represents the blue value with red = 0 and green = 255.

    $v = 512 => rgb(0,255,255); 513 => rgb(0,255,254); ... 783 => rgb(0,255,0)

    The color transitions from cyan to green.

  • And so on through green to yellow to red to magenta to white.
• Packs the 3x8-bit rgb values to a 32-bit value compatible with truecolor images
• And returns it.

As a user, all you need to do is supply the numeric value + minimum and maximum and use the return to draw your plot.

Eg. If your minimum rainfall value is 0.5" and maximum 10", then to get the right color to plot the value 2.5",

my $plotColor = colorRamp1785( 2.5, 0.5, 10 );
[download]

If the drawing package you use needs discrete RGBs rather than packed, just remove the rgb2n() call from the return line.

Does that help?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"I'd rather go naked than blow up my ass"

Does that help?

Oh, absolutely! I have taken the code for colorRamp and am adapting it to my use. I have not just precip, but many different ecophysical variables, so I can use it for creating visualizations of all of them. My colorRamp itself is going to be customizable so that I will be able to specify starting and ending colors (kinda like I linked to at http://colorbrewer.org). This is truly great, and thanks and attribution goes to you, of course.

By the way, if you don't mind answering -- why do you have the colorRamp definition itself inside a BEGIN {} block?

--

when small people start casting long shadows, it is time to go to bed

Hi, I was using Acme::AsciiArt2HtmlTable which makes tables with coloured cells but has some problems such as limited colours and it's a bit slow(I guess because it's in Acme namespace it's not really supposed to be used for serious stuff). anyway got your colourramp1785 and modified it a bit to work with almut's GD snippet:

my @map=(
    sub{(         0,             0,   $_[0] * 255 )},
    sub{(         0,     $_[0]*255,           255 )},
    sub{(         0,           255, (1-$_[0])*255 )},
    sub{( $_[0]*255,           255,             0 )},
    sub{(       255, (1-$_[0])*255,             0 )},
    sub{(       255,             0,     $_[0]*255 )},
    sub{(       255,     $_[0]*255,           255 )},
);
 
sub ramp {
    my( $v, $vmin, $vmax ) = @_;
 
    ## Peg $v to $vmax if it is greater than $vmax
    $v = $vmax if $v > $vmax;
    ## Or peg $v to $vmin if it is less tahn $vmin.
    $v = $vmin if $v < $vmin;
    ## Normalise $v relative to $vmax - $vmin
    $v = 
    ( $v    - $vmin ) /
    ( $vmax - $vmin ) ;
    ## Scale it to the range 0 .. 1784
    $v *= 1785;
 
    my @a = 
    map { int } 
    $map[$v/255]->( ($v % 255) / 256 );
 
    #print join(',',@a)."\n";
 
    return 
    ($a[2]<<8 ) |
    ($a[1]<<4 ) |
    ($a[0]    ) ;
};
[download]

I'm using it in a loop like so: $img->setPixel($x, $y, $some_val_from_a_table ,  1,16 )) ; it works ok but sometime produces colours which are too near to each other to be distinguished easily. Browser_Uk , how di dyou write your colour ramp ? I read about some colour ramps <-- here, but not sure if they fit the common usage.