On 8/29/06, Simon Budig <simon@xxxxxxxx> wrote:
That would work for me definitely. I use indexed mode for drawing pixel art. As long as that Op could be placed wherever I want it -- because antialiasing something, shading it, and then quantizing it is not the same as antialiasing it, quantizing it, shading it, and quantizing it again (the latter may be more effective.). I believe this would satisfy people who want to quantize to a >256 color palette (eg Pantone colors). I cannot comment on texture drawing.
I *would* want the palette to be saved with the image, because that makes color selection a lot easier -- I wouldn't have to try to select the right palette for the image before drawing on it.
Along a similar line of thinking, I've tried at various times to convince gimp's convert-indexed functionality to output RGB rather than indexed. I find the code somewhat confusing, but I think this is what I need to do:
* allocate RGB tiles instead of indexed ones.
* write color values rather than indices
actually, that seems rather simple now. I'm marking all the changes needed in gimpimage-convert.c now. Thanks.
> I don't really care whether it is duplicated in GEGL or outside it, as
> long as the net effect of "don't let my editing result in pixel colors
> outside this small predeterined palette" is still attainable with the
> sum of GEGL + futureGimp.
I wonder if a "quantize to palette" Gegl Op would solve these problems.
In most of the cases when people are asking for an indexed palette, the
palette is already determined somehow, either by importing from the
image or by editing for a specific hardware or certain texture
conventions.
In that case you really could have a "quantize" op, that maps all colors
in the images to the appropriate colors in the palette. You'd have all
the power of semitransparent layers, all tools would work as "expected"
for a given definition of "expected" :), blurring would work etc.
I am pretty positive that these problems could be sorted out when we
know what people working with palette-based images want to have. I am
just guessing on the needs here...
That would work for me definitely. I use indexed mode for drawing pixel art. As long as that Op could be placed wherever I want it -- because antialiasing something, shading it, and then quantizing it is not the same as antialiasing it, quantizing it, shading it, and quantizing it again (the latter may be more effective.). I believe this would satisfy people who want to quantize to a >256 color palette (eg Pantone colors). I cannot comment on texture drawing.
I *would* want the palette to be saved with the image, because that makes color selection a lot easier -- I wouldn't have to try to select the right palette for the image before drawing on it.
Along a similar line of thinking, I've tried at various times to convince gimp's convert-indexed functionality to output RGB rather than indexed. I find the code somewhat confusing, but I think this is what I need to do:
* allocate RGB tiles instead of indexed ones.
* write color values rather than indices
actually, that seems rather simple now. I'm marking all the changes needed in gimpimage-convert.c now. Thanks.
_______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
