Re: image indexed mode, major hole

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/7/07, Henning Makholm <henning@xxxxxxxxxxx> wrote:
> Scripsit Sven Neumann
> One cannot do this, in general, because an indexed PNG stores a single
> alpha value for each palette entry. An image with an unrestricted
> alpha channel would most likely lead to more color/alpha combinations
> than the 256 palette slots available in PNG.
>
> > But it's more likely that we will soon drop indexed mode completely and
> > push handling of indexed color to the load and save plug-ins.
>
> I can see good software-engineering reasons to want to eliminate
> indexed representation internally, but from a usability standpoint it
> will be a loss not to be able to restrict the possible color values to
> a predetermined palette.
That is not implied by 'push handling of indexed color to the load and
save plug-ins'. Indeed, it would be rather easy to attach data
dictating what colormap to indexize to, what parameters (eg dithering)
to use.., via a parasite, and have indexed savers use that data.

>
> Imagine finding out only after several hours of editing that some of
> the pixels you intended to be (255,192,53) accidentally became
> (255,192,54), and others became (255,188,53) and a few of the
> (64,64,0) became (64,64,3), and this is a source of immense confusion
> to software later your build process, which recognizes exactly those
> colors to have a special meaning, and now you have to go through a few
> dozen layers to find all of the misfit pixels and correct their color
> one layer and color at a time. Indexed editing prevents making the
> mistake in the first place; if I have not explicitly added
> (255,192,54) to the palette I know that I'll not risk finding it in
> the output.

Although I understand the problem posed by the above type of
cumulative error - For example it can be easily caused by accidentally
bumping drawing opacity down to 99 instead of 100, and with enough
cumulative error it might quantize to an unintended color, not the
color you meant to draw with...
I believe the solution to that is to allow the user to quantize their
image to an indexed palette at any time -- indeed, having such a
quantization as a toggleable display filter would be abundantly
useful. Note that this is a separate issue from indexization --
quantization only refers to dictating what colors are in the output,
not the manner in which they are stored.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux