[GRASS-dev] [GRASS GIS] #1071: histogram equalized color rules for raster takes inordinately long to display

GRASS GIS trac at osgeo.org
Mon May 17 13:00:07 EDT 2010

#1071: histogram equalized color rules for raster takes inordinately long to
 Reporter:  isaacullah                                 |       Owner:  grass-dev at lists.osgeo.org
     Type:  defect                                     |      Status:  new                      
 Priority:  major                                      |   Milestone:  6.4.0                    
Component:  Display                                    |     Version:  6.4.0 RCs                
 Keywords:  histogram equalization, display, r.colors  |    Platform:  Linux                    
      Cpu:  Unspecified                                |  
 Recently, I have discovered that displaying a map that has been recolored
 using the histogram equalization option (-e) in r.color takes much much
 much longer than displaying the same map colored without the histogram
 equalization option. With a histogram equalized raster, every redisplay
 takes about 5 minutes, whereas with a normally colored raster, redisplay
 takes a second. This means that every little action you do that causes a
 need to redisplay (ie. even just moving the scale bar) leads to a 5 minute
 wait. I've tested this with 6.4 RC5 and 6.5SVN, and both have the same
 behavior. I'm using a single ASTER tile as a test raster. The tile
 displays normally (fast) when given normal color rules, but when the
 histogram equalization option is checked, it takes about 5 minutes to
 display it (or even just a small portion of it).
 I'm using a brand new 64bit core-i5 laptop with 4 gigs of RAM running
 Ubuntu 10.04. My system is blazing fast, so this is definitely NOT a
 hardware issue. I don't know if this is a known issue with the -e option
 of r.color, or perhaps a known issue with installation on Ubuntu 10.04,
 but I don't remember experiencing this problem in the past (with other
 versions of 6.4RC's or 6.5SVN on Ubuntu 9.10 or Windows), and I can't find
 any other open bug tickets that report this problem. If this is indeed a
 bug, this seems like a pretty major issue that would need to be addressed
 before the 6.4 stable is released?

Ticket URL: <http://trac.osgeo.org/grass/ticket/1071>
GRASS GIS <http://grass.osgeo.org>

More information about the grass-dev mailing list