[GRASS-dev] inverted color scales

What do you guys think of a flag in r.colors to apply an inverted color scale?

cheers


±----------------------------------------------------------+
Carlos Henrique Grohmann - Guano
Visiting Researcher at Kingston University London - UK
Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
±----------------------------------------------------------+


“Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive.”
–The winning entry in a “What were HAL’s first words” contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke

Carlos "Guâno" Grohmann wrote:

What do you guys think of a flag in r.colors to apply an _inverted_ color
scale?

Sounds really usefull to me.

Maciek

I have been wanting this feature for a while!

thanks Carlos!

Dylan

On 6/27/07, Maciej Sieczka <tutey@o2.pl> wrote:

Carlos "Guâno" Grohmann wrote:
> What do you guys think of a flag in r.colors to apply an _inverted_ color
> scale?

Sounds really usefull to me.

Maciek

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

Maciej Sieczka wrote:

> What do you guys think of a flag in r.colors to apply an _inverted_ color
> scale?

Sounds really usefull to me.

Sounds really trivial to implement, too.

"struct Colors" already has an "invert" field, which can be inverted
with G_invert_colors().

AFAICT, you just need e.g.:

    flag.n = G_define_flag();
    flag.n->key = 'n';
    flag.n->description = _("Invert colors");

  ...

    if (flag.n->answer)
    {
  G_invert_colors(&colors);
  colors = colors_tmp;
    }

The only issue is whether the inversion should come before or after
logarithmic scaling (I think that it matters, although I haven't
actually checked).

As more transforms are added, it's looking more important to replace
the various flags with an option, e.g. trans=log,eq,inv.

NOTE: this will add another situation where the GUI's assumption that
opt->multiple=YES implies a set (rather than a list) will fail.

--
Glynn Clements <glynn@gclements.plus.com>

> What do you guys think of a flag in r.colors to apply an
> > _inverted_ color scale?
>
> Sounds really usefull to me.

I've wanted this for a long time too.

Glynn:

Sounds really trivial to implement, too.

"struct Colors" already has an "invert" field, which can be inverted
with G_invert_colors().

AFAICT, you just need e.g.:

    flag.n = G_define_flag();
    flag.n->key = 'n';
    flag.n->description = _("Invert colors");

  ...

    if (flag.n->answer)
    {
  G_invert_colors(&colors);

[//] colors = colors_tmp;

    }

done in 6.3 CVS.

The only issue is whether the inversion should come before or after
logarithmic scaling (I think that it matters, although I haven't
actually checked).

I think that it matters too, and I put it before the scaling.
(flipping it is conceptually a linear operation, don't apply a linear
operation to log-transformed data; or if you prefer, keep the rule defn
code separate from the math post-processing code)

Hamish

Hamish wrote:

> > What do you guys think of a flag in r.colors to apply an
> > > _inverted_ color scale?
> >
> > Sounds really usefull to me.

I've wanted this for a long time too.

Glynn:
> Sounds really trivial to implement, too.
>
> "struct Colors" already has an "invert" field, which can be inverted
> with G_invert_colors().
>
> AFAICT, you just need e.g.:
>
> flag.n = G_define_flag();
> flag.n->key = 'n';
> flag.n->description = _("Invert colors");
>
> ...
>
> if (flag.n->answer)
> {
> G_invert_colors(&colors);
[//] colors = colors_tmp;

Nope; unlike the other transformations, G_invert_colors() operates
"in-place" (it simply inverts the "invert" flag in the structure).

In the above, colors_tmp essentially contains garbage; it may not have
even been initialised.

--
Glynn Clements <glynn@gclements.plus.com>