GNOME Bugzilla – Bug 141249
Indexing without mode change
Last modified: 2018-05-24 11:03:34 UTC
the idea is to preserve the image mode (RGB/Greyscale) and just modify the color data. for most kinds of indexization this is effective. (the only case i know where it is not is when you want two palette entries the same color in your palette -- for instance for color-cycling effects) making indexization into a filter could address these bugs: + #52123 : option to indexize images with palettes > 256 colors + #88361 : use marked area for creation of palette + #66258, #66261 : colors that should not be (dithered/ modified) during indexization. i find i often want to indexize only part of an image; this would also resolve that problem which i currently have to work around.
Yes, this would be an important improvement.
Created attachment 79023 [details] [review] Usable (but unfinished) version of indexize-without-mode-change. This patch presently forces all 'indexed conversions' to preserve the mode. This is a regression[1], and that is why the preserve_mode field is used. Until I add a UI, preserve_mode is hardcoded to TRUE. It's also rather messy -- not the actual code, but I added lots of comments that should go away later. All combinations of settings should behave correctly, I've tested fairly extensively. (Note: This doesn't mean I've fixed bug #349882; I haven't.) Remaining issues: * Doesn't respect the selection -- I should use shadow buffer tiles for preserve_mode output rather than manually allocing new tiles, right? * Doesn't allow palettes > 256 colors. This is a fairly hairy problem, with 256 hardcoded in many places, and static allocation assumed in others. It may take some trial and error to eliminate all of those assumptions in the code. [1] Sometimes you actually need the output to be colormapped, so for instance it can be colorcycled or easily palette-swapped; it also saves memory when making animated GIFs.
The approach gone here is so pointless. If at all we would redesign the indexing so that the mode conversion becomes an extra step after quantisation. We would also want to move this to a plug-in then.
I already planned on refactoring it, after I'd gotten a working prototype. However. IMO indexization is needed in the core, and gimp_image_convert is the only function that provides it. Then you think that in the case of indexed images gimp_image_convert should just map RGB colors directly to indices without any of the current fancy processing (dithering, removing unused colors) ? That seems OK to me, and more in line with the behaviour of converting to RGB or GRAY. The main reason that the dithering and other color-reduction functions in gimpimage-convert cannot currently become plugins, is that they use CPercep. Anyway, I've already separated the part that does the non-mode-changing color reduction into a separate function.
Does it really make sense to waste time on this now? We aren't going to include this in 2.4 and after 2.4 we are going to move to gegl anyway.
The most important reasons why this is a worthwhile use of time are: it gives me feedback, and something I can use immediately. Porting the quantization to GEGL may be a good project after I've acquired some experience with it.
The cpercep routines could be given a reasonable API and moved to libgimpcolor if they are needed outside the core.
*** Bug 52123 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/75.