GNOME Bugzilla – Bug 102768
Preserve the index of some colors in the optimized color palette
Last modified: 2004-12-22 21:47:04 UTC
It would be useful to be able to generate an optimized palette around a predefined set of 'fixed' colors. For example: I have a project where I need to generate a very explicit 16-color palette, 8 of which need to be specific colors attached to specific pens; the remaining 8 can be user-defined to match whatever colors are needed for a specific image. The problem is, that the 8 hard-coded colors are not neatly packed into the beginning of the palette, but instead are scattered throughout; it would be nice, therefore, to be able to tell the GIMP (for example), that pens 0,1,3,7,8,11,12,14, and 15 must be left 'as-is', and that the remaining pens can be populated with an optimized palette. This would allow me to more easily generate images which have to be used in environments that are palette-order sensitive.
Isn't that what was requested in bug #66258 ? If you agree, please make this report a duplicate of #66258.
bug #66258 appears to be similar to this, but is not concerned with the preservation of a specific order in an indexed palette. This idea would be helpful in cases where it is necessary, for technical reasons (such as the creation of banners in Drive Image Pro) to preserve existing palette entries; Drive Image Pro uses specific palette entries to render the GUI of the application, so those entries cannot be modified (for reasons unknown to me, these entries are *not* conveniently packed into the first eight entries, but are scattered throughout a 16-color palette). Therefore, it would be useful, when dithering an image down to a pre-defined palette, to be able to say that I need to preserve specific palette entries, but the palette optimizer can freely replace the remaining entries with whatever colors are most suitable to the specific image. #66258 seems to be a desire to be able to say "I've got certain colors in the image that I *must* preserve, so don't consider them when generating an optimal palette". Both ideas do seem to be very similar, however--it's just that one *is* concerned with preserving specific palette entries, whereas the other is not. I guess you could consider this one a superset of #66258, but I don't think it's a duplicate. Maybe they can be merged into one idea?
OK, so this bug seems to depend on the features requested in #66258.
I have changed the summary of this bug report because the words "fixed pens" were a bit confusing. Bug #66258 is about preserving the RGB values of some colors, which is a prerequisite for this one, which is about preserving not only the value but also the position of these colors in the palette. This one is a bit more tricky, because it will probably require a way to "mark" some colors in an existing palette in order to lock them in their current position even if there are "holes" between the colors. As a marker, we could use a special tag in the names of these colors (these names are seldom used anyway). This is not very elegant, but this is probably the easiest way to implement this feature, which will only be used in some very specific cases.
How about appending " [FIXED]" to the end?
Yes, I thought about something like " [FIXED]" or " [LOCK]". But this can only be done after bug #66258 is solved, so we probably have plenty of time to think about a suitable word for this feature... ;-)
Changes at the request of Dave Neary on the developer mailing list. I am changing many of the bugzilla reports that have not specified a target milestone to Future milestone. Hope that is acceptable.
Hmmm. I'm honestly gunning for a WONTFIX on this one; the code impact would be nontrivial (in an already increasingly over-specialcased area of code) for (critically) a feature useful to a vanishingly tiny number of users. This could be implemented as a separate specialised non-core plugin or png-eater that does an index re-remap of the output of remapping once bug 66258 ('preserve certain colours (but not their indices)') is fixed. If someone wants to write a re-remapper plugin (that could call into the core rgb->index pdb proc if they want a one-step solution) then they should file a bug for that stage disentangled from the core quantizer.