Opened 10 years ago

Last modified 5 years ago

#1071 new defect

histogram equalized color rules for raster takes inordinately long to display

Reported by: isaacullah Owned by: grass-dev@…
Priority: major Milestone: 6.4.6
Component: Display Version: svn-releasebranch64
Keywords: histogram equalization, display, r.colors Cc:
CPU: Unspecified Platform: Linux

Description

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?

Attachments (1)

color_xform.diff (2.3 KB) - added by neteler 6 years ago.
Backport patch for GRASS 6, develbr6

Download all attachments as: .zip

Change History (7)

comment:1 in reply to:  description ; Changed 10 years ago by 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.

comment:2 in reply to:  1 Changed 10 years ago by 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.

comment:3 Changed 8 years ago by neteler

Milestone: 6.4.06.4.3

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

Changed 6 years ago by neteler

Attachment: color_xform.diff added

Backport patch for GRASS 6, develbr6

comment:4 Changed 6 years ago by neteler

Milestone: 6.4.36.4.5
Version: 6.4.0 RCssvn-releasebranch64

Review of attached color management backport patch desired.

comment:5 Changed 5 years ago by martinl

Milestone: 6.4.5

Ticket retargeted after milestone closed

comment:6 Changed 5 years ago by martinl

Milestone: 6.4.6
Note: See TracTickets for help on using tickets.