histogram equalized color rules for raster takes inordinately long to display

[isaacullah]

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?

[glynn]

Replying to isaacullah:

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,

If you use -e on an integer map, it will create one rule for each value which occurs in the map, which can result in an excessively large colour table.

I'm sure that this very issue has been addressed before, but I don't remember the details.

The quick fix would be to use the same code as for floating point (which just splits the range into 1000 bins, and always generates 1000 rules). A better fix is to coalesce a run with a constant colour into a single rule.

[glynn]

Replying to glynn:

A better fix is to coalesce a run with a constant colour into a single rule.

I've done this for 7.0 with r42277.

[neteler]

I have added a backport patch for GRASS 6 which needs review against r42277.

[neteler]

Backport patch for GRASS 6, develbr6

[neteler]

Review of attached color management backport patch desired.

[martinl]

Ticket retargeted after milestone closed