#336: r.colors -e flag does not use full color range if map values are between 0.
and 1.
---------------------+------------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-trunk
Keywords: | Platform: All
Cpu: All |
---------------------+------------------------------------------------------
Using r.colors -e on normalized maps show a color problem leading to low
contrast maps. See attachment for illustration (histogram maps).
#336: r.colors -e flag does not use full color range if map values are between 0.
and 1.
----------------------+-----------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-trunk
Resolution: | Keywords:
Platform: All | Cpu: All
----------------------+-----------------------------------------------------
Comment (by hamish):
Replying to [ticket:336 neteler]:
> See attachment for illustration (histogram maps).
#336: r.colors -e flag does not use full color range if map values are between 0.
and 1.
----------------------+-----------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-trunk
Resolution: | Keywords:
Platform: All | Cpu: All
----------------------+-----------------------------------------------------
Comment (by neteler):
Code to reproduce right side screenshots:
{{{
# Spearfish
g.region rast=elevation.dem
r.mapcalc "tmp1=elevation.dem - 1066."
r.mapcalc "elv=tmp1 / 774."
r.colors elv col=gyr
d.mon x4
d.histogram elv
r.colors elv col=gyr -e
d.mon x0
d.histogram elv
}}}
#336: r.colors -e flag does not use full color range if map values are between 0.
and 1.
----------------------+-----------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-trunk
Resolution: | Keywords:
Platform: All | Cpu: All
----------------------+-----------------------------------------------------
Comment (by glynn):
Replying to [ticket:336 neteler]:
> Using r.colors -e on normalized maps show a color problem leading to low
contrast maps. See attachment for illustration (histogram maps).
Histogram equalisation depends upon categories, which in turn depends upon
quantisation. If you have a 0-1 map with "round" quantisation, you only
get two categories, 0 (covering 0-0.5) and 1 (covering 0.5-1). If the map
uses "truncate" quantisation, you get one category, 0 (covering 0-1).
The equalisation code takes the colour corresponding to the category's
median value and maps it to the category's nominal value. See
G_histogram_eq_colors() in lib/gis/color_xform.c for the actual code.
I suppose that I could change it to map the colour for the lower bound to
cat and the colour for the upper bound to cat+1. However, I'm not sure
there is really much point, given that histogram equalisation on one or
two categories doesn't seem to be of much practical use.
Ultimately, decent histogram equalisation for FP data will require
replacing the use of the Cell_stats code with something else (i.e. binning
the data into arbitrary FP ranges, rather than one bin per integer
category). Also, it will need to use logarithmic (geometrically-spaced)
bins in order to work well with -g (log scaling).
#336: r.colors -e flag does not use full color range if map values are between 0.
and 1.
--------------------------+-------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-trunk
Resolution: | Keywords:
Platform: All | Cpu: All
--------------------------+-------------------------------------------------
Changes (by neteler):
* type: defect => enhancement
Comment:
Thanks for the insights.
At this point I should simply normalize to 100 instead of 1 (I am
normalizing indeed the output of r.texture). And hope for a better
histogram equalisation for FP data in a future GRASS version.
#336: r.colors -e flag does not use full color range if map values are between 0.
and 1.
--------------------------+-------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-trunk
Resolution: | Keywords:
Platform: All | Cpu: All
--------------------------+-------------------------------------------------
Comment (by glynn):
Replying to [comment:3 glynn]:
> Ultimately, decent histogram equalisation for FP data will require
replacing the use of the Cell_stats code with something else (i.e. binning
the data into arbitrary FP ranges, rather than one bin per integer
category). Also, it will need to use logarithmic (geometrically-spaced)
bins in order to work well with -g (log scaling).
Implemented in r33889 (7.0).
Currently hardcoded to 1000 bins, which should provide reasonable quality
without creating excessively large colour tables.
#336: r.colors -e flag does not use full color range if map values are between 0.
and 1.
--------------------------+-------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: closed
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-trunk
Resolution: fixed | Keywords:
Platform: All | Cpu: All
--------------------------+-------------------------------------------------
Changes (by neteler):
* status: new => closed
* resolution: => fixed
Comment:
Very nice, thanks. Tested and backported as r33903 to 6.4.svn.