<snipped...>
It would be nice to clean up the system a bit. Many of the reports areAgreed. The signal-to-noise ratio is declining.
simply unusable or at least not reproduceable, so maybe trying to contact that
particular persons and asking them whether they can reproduce a bug and how
would be great.
But even here care must be taken with purges. Just yesterday, the hauntingly
obscure #2683 with its perplexing title, "Colors problems with picture indexed"
suddenly came clear to me. Nothing ever resets color_hash_table [paint_funcs.c
CVS 1.70 line 114]. This object plays a role in mapping RGB into an indexed
image's current palette. (In the context of copying an RGB image into an indexed.
See, in particular, map_rgb_to_indexed() [paint_funcs.c CVS 1.70 line 3071]).
Once an index is chosen for a particular RGB triplet, it is hashed away for future
reference. All well and good until the user transforms the indexed image into
RGB, transforms the color space, then converts the image back into
an indexed format. This generally changes the palette completely (different colors,
different sized tables). But guess what? the old mappings still persist in the
hash table, (it's not purged when an image transitions from indexed to RGB
format). Should the user THEN copy another RGB into the (now
reorganized) indexed image, those now-outdated hash entries pick indices
that don't exist anymore or are referencing completely differnt colors.
Had this bug report been purged as too strange to work with, I never
would
have (eventually) grokked on it.
This, by the way, will be forwarded to 2683@xxxxxxxxxxxxxx, which will
automagically update that report without requiring further keystrokes
on
my part. Now all I need is a weekend to fix it.
Be good, be well
Garry Osgood
