GNOME Bugzilla – Bug 313458
palette-map does not work 'as advertised'
Last modified: 2005-08-27 18:13:20 UTC
the help says 'a complete black pixel becomes the lowest palette index, and complete white becomes the highest.' The actual behaviour is to interpret intensities directly as indices, Clipping at the end of the palette, so that if you have a 4-color palette, anything brighter than 3/255 will be mapped to the final palette entry. This patch fixes it, so that the input range [0.255] really does map to [0..max_pal_entry].
Created attachment 50681 [details] [review] fix palette-map to map palettes != 256colors correctly
That looks indeed broken, however the patch would change the plug-in's behavior, so it should probably go only into CVS HEAD. Setting milestone to 2.4
Palette-map is new as of GIMP 2.3, and the current behavior is what I intended when I wrote it, thinking that people would be happiest having each gray level map to the corresponding palette index. But it wouldn't bother me much if this were changed. The plug-in does not actually have any help; this bug report is referring to the blurb, which I was careless in modifying from the one for the gradient map plug-in.
It is MUCH more useful this way. I usually use it with a palette of 16 or less, for pixel-art. This is good for controlled color reduction + color swaps. A 256-entry palette produces the same result as before.. so if you really want the clipping effect (why?!) you can just pad the palette to 256 entries with the last valid color.
I tend to agree with David here, I would have expected the behaviour that he describes.
This patch does work as advertized, so I think it should go in.
2005-08-27 Michael Schumacher <schumaml@cvs.gnome.org> * plug-ins/common/gradmap.c: applied a patch by David Gowers, which makes palette-map behave the same as gradient-map. Fixes bug 313458.