in reply to Re: visualizing data in a table
in thread visualizing data in a table

Gosh! ColorRamp1785 is beautiful. Many thanks. Update: Would be nice to have comments/annotation in that code. As is, it is not understandable by mortals such as myself. It does work beautifully.

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

--

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

Replies are listed 'Best First'.
Re^3: visualizing data in a table
by BrowserUk (Patriarch) on Mar 27, 2010 at 06:13 UTC
    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; } }

    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 );

    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.
      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
        why do you have the colorRamp definition itself inside a BEGIN {} block?

        Just to ensure that the lookup table is built before the sub can be called.

        That would take care of itself if it was in a module. But so far, everyone who's contacted me about the snippet has had a different set of requirements of it. Some want discrete rgbs; some rgba; some as html-style 3 or 6 hex digits; some want cmyk. Everyone seems to need to adapt it some way or another.


        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.
      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] ) ; };
      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.

        The idea behind the code started from here.


        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.