[GRASS-user] Landsat color correction fails with "Segmentation fault" in GRASS 6.3

Hamish hamish_b at yahoo.com
Mon Jun 2 01:41:38 EDT 2008


Marius Jigmond wrote:
> Have you run into this kind of errors:

Nope.
 
> GRASS 6.3.0 (Romania):~> i.landsat.rgb
>    red=RGB321.3 at marius green=RGB321.2 at marius blue=RGB321.1 at marius
> Processing  ...
> Segmentation fault
> ERROR: bad rule (syntax error): white
> Processing  ...
> Segmentation fault
> ERROR: bad rule (syntax error): white
> Processing  ...
> Segmentation fault
> ERROR: bad rule (syntax error): white
> 
> It's a three band Landsat mosaic. I am running Ubuntu
> 8.04 with GRASS 6.3 from Jachym Cepicky's repo
> (http://les-ejk.cz/ubuntu/). I am not 
> really sure where to start poking.

It would seem that r.univar is failing in this part of the i.landsat.rgb script:

   for i in $RED $GREEN $BLUE ; do
      g.message "Processing <$i> ..."
      MIN=`r.univar -ge $i perc=2 | grep "^percentile_" | cut -d'=' -f2`
      MAX=`r.univar -ge $i perc=$BRIGHTNESS | grep "^percentile_" | cut -d'=' -f2`
      g.message -d message="<$i>:  min=$MIN   max=$MAX"
      r.colors $i col=rules << EOF
        0% black
        $MIN black
        $MAX white
        100% white
EOF
      done


so $MAX would be unset, and r.colors gets a color without a value, which is a bad rule.
???

can you try "r.univar -ge RGB321.3 at marius perc=98" on the command line and see what happens?

also, what does "g.region -p" look like?

and finally can you rerun i.landsat.rgb with debug messages turned on?
  g.gisenv set="DEBUG=1"   # to turn them back off set to 0 
then the g.message info will be displayed.

but why does r.colors not complain about "$MIN black" too?


Hamish



      



More information about the grass-user mailing list