[GRASS5] Re: [GRASSLIST:3252] r.colors color= proposal

[Michael Barton]

On 4/25/04 5:36 PM, "Glynn Clements" <glynn.clements at virgin.net> wrote:

> 
> Michael Barton wrote:
> 
>>> [*] I'm pretty much finished with TrueColor support for core modules
>>> now; let me know if there are any others you want done.
>> 
>> Well, since you mention it, the Cell driver is lacking TrueColor
>> support. If it was there, I could do TrueColor tiff output in
>> d.out.tiff.
> 
> Most of the necessary code is already present in the PNG driver.
> 
> However, there's one significant issue: generating a 24-bpp colour
> table is *really* slow (this is why r.composite defaults to 15 bpp).
> Realistically, a true-colour CELL driver would need to either:
> 
> a) generate three separate R/G/B maps, or
> 
> b) reduce the colour depth to a level for which a colour table could
> reasonably be generated.
> 
> Short version:
> 
> Large colour tables aren't practical with the current implementation.
> 
> Longer version:
> 
> The underlying problem is that the code to add a rule to a colour
> table checks for overlap with the existing rules. The time taken to do
> this is proportional to the total number of rules, so the total time
> taken to construct a colour table is proportional to the square of the
> number of rules.
> 
> For 15-bpp (5 bits/32 levels per component), you need 32 * 32 = 1024
> rules (each covering 32 categories). For 24-bpp (8 bits/256 levels per
> component), you need 256 * 256 = 65536 rules, which is 64 times as
> many rules and takes ~4000 times as long.
> 
> Try comparing "r.composite ... levels=256" with the default
> (levels=32); the extra time taken is entirely down to building the
> colour table.
> 
> BTW, if that was the only issue, I suppose that we could create
> additional functions for use in such situations (i.e. constructing a
> colour table from scratch where it is known that rules never overlap).
> But there is still the issue that the time taken to perform lookups
> would increase in proportion to the number of rules.

Oh well. I figured there was a good reason or it would have already been
done.

> 
>>> I commented out the code for non-referenced color-only rules, as a)
>>> they
>>> don't work, and b) I can't figure out what they are supposed to be
>>> doing
>>> in the first place.
>> 
>> I'm not clear what you are commenting out. If you mean referring to
>> colors by name (blue, green, etc.) they work for me and are helpful
>> many times. But perhaps you mean something else. Sorry to be dense.
> 
> No; he is referring to rules which only specify a colour, but not a
> value.

Check.

--

Michael Barton