[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