It would be nice to clean up the system a bit. Many of the reports are
 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.
Agreed. The signal-to-noise ratio is declining.
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 [EMAIL PROTECTED], 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

Reply via email to