Hi,

On Tue, 2007-06-05 at 20:23 +0200, yeziut@o2.pl wrote:

Hi i'm not a developer, but here's an issue that developers should consider in my honest opinion. Since it's not a bug, but a missing feature, i'm posting this here.

Ok, to the point: Conversion to indexed mode in GIMP kills any alpha transparency in the image, even if the palette used has semi-transparent colors in it.

It doesn't do that. Only the display layer does alpha thresholding. If someone would write a PNG save plug-in that actually uses the full alpha channel information for indexed images, then we would simply remove that thresholding from the display code.

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.

Sven

Scripsit Sven Neumann

If someone would write a PNG save plug-in that actually uses the full alpha channel information for indexed images,

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.

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.

On 6/7/07, Henning Makholm 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.

Hi,

On Thu, 2007-06-07 at 01:05 +0200, Henning Makholm wrote:

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.

That is one way of storing alpha and indexed colors in PNG. As far as I know there's also another mode that involves a real alpha channel. That should be easily implementable.

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.

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.

This is not exactly the kind of job that we design GIMP for. You will have to use another application (or an older version of GIMP) for this purpose then.

Sven

Henning wrote:

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.

I see it as a boost for usability when this whole indexed mode disappears from the UI. To many user complaints are being triggered by the possibility of working in different modes.

It is good thing when working in gimp is unambiguously in full resolution and indexed becomes a matter of importing and exporting. This will enable us to have a less schizophrenic UI.

And while exporting, one deals with the problem you describe here:

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.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture