Hi,

On Fri, 2006-08-25 at 20:01 +0930, David Gowers wrote:

Is there some simple way to achieve hard-edged rendering for the Ink tool?

Should be a simple change, just turn off supersampling in the ink code.

I find the hard edged rendering used in INDEXED mode best for drawing lineart, but dislike the other constraints (no drawing modes/opacity/layer modes) imposed by working in INDEXED mode.

Eeek, the way it acts in INDEXED mode is so ugly. Why would you want to do this?

So far, I've tried to find the part of the code that handles indexed images without success.

Why would you look for it? That's completely unrelated here. The ugly behaviour in indexed mode is just a shortcoming of the code that combines regions.

Sven

Hi,

On Sat, 2006-08-26 at 01:57 +0930, David Gowers wrote:

It's good to know that. I previously got the impression that you were indifferent to GIMP's usefulness for editing INDEXED images. I certainly hope that I can substantially improve indexed drawing specifically, when GEGL is in use and I understand it. I think it would be relatively simple to bring INDEXED drawing to the level of usefulness demonstrated by professional pixeling tools (ProMotion, or the older DeluxePaint and it's clones) with a sound architecture like that.

Gegl doesn't support images with indexed colors and I very much doubt that it ever will support it. It is rather likely that indexed mode will be completely handled by load and save plug-ins in a gegl-based GIMP. If there's a need for editing indexed mode, this need will likey have to be fulfilled by a different application then.

Sven

Hi,

On Sat, 2006-08-26 at 02:28 +0930, David Gowers wrote:

Ah, the #define SUBSAMPLE 8 line. Changing it to 1 does indeed do what I wanted.

Actually, I take that back.

Well, of course changing the define is not what you want because then you can't get the old behaviour back.

I'm looking for normal supersampling which is subsequently alpha-thresholded (exactly the way the ink and airbrush tools work in INDEXED mode.)
The behaviour of the Ink tool without supersampling is unacceptably chunky.

So it looks like this may not be possible :(

What keeps you from thresholding the alpha values (which is essentially what the combine_regions code is doing, even though there is actually no goood reason for this behaviour)?

Sven

Scripsit Sven Neumann

Gegl doesn't support images with indexed colors and I very much doubt that it ever will support it. It is rather likely that indexed mode will be completely handled by load and save plug-ins in a gegl-based GIMP. If there's a need for editing indexed mode, this need will likey have to be fulfilled by a different application then.

Or rather, we who need indexed imaged would have to fork Gimp from the last sane version.

On 8/29/06, Henning Makholm wrote:

Scripsit Sven Neumann

Gegl doesn't support images with indexed colors and I very much doubt that it ever will support it. It is rather likely that indexed mode will be completely handled by load and save plug-ins in a gegl-based GIMP. If there's a need for editing indexed mode, this need will likey have to be fulfilled by a different application then.

Or rather, we who need indexed imaged would have to fork Gimp from the last sane version.

I wonder which version of GIMP that is, my version of GIMP is already crippled when it comes to supporting indexed images. I'm not allowed to create new images in indexed mode, I cannot set the opacity for a layer, I cannot use the smudge or blur|sharpen tool, gaussian blur doesn't work neither does unsharp mask, layer masks seems to work but get their alpha thresholded. To do any real work on an indexed image I already have to go by RGB.

Duplicating this behavior in GEGL would not be appropriate in my opinion, if an indexed image is loaded, the lookup table of the palette is interpreted and it is treated as a color image. Thus GEGL will have the same stance towards GIF/PCX as JPG, RAW and SVG, they might be included as source material verbatim, but expecting palette preserved, DCT level compositing, non-demosaiced bayer-data or vectors in the output,. after compositing and image processing, is quite simply outside the reasonable scope for a image processing/compositing library.

Adding capabilities outside GEGL that special cases editing of indexed drawables is of course an option, (in the same manner that the path tool or inkscape would be possible to invoke for operation on SVG based vector data.

/Øyvind K.

Scripsit "Øyvind Kolås"

On 8/29/06, Henning Makholm wrote:

Or rather, we who need indexed imaged would have to fork Gimp from the last sane version.

I wonder which version of GIMP that is, my version of GIMP is already crippled when it comes to supporting indexed images. I'm not allowed to create new images in indexed mode,

A minor nuisance, easily worked around. Equally easy coded around in a fork.

I cannot set the opacity for a layer,

A major nuisance.

I cannot use the smudge or blur|sharpen tool, gaussian blur doesn't work neither does unsharp mask, layer masks seems to work but get their alpha thresholded.

Neither of which are something one usually needs in a situation where one wants to stick to a colormap while editing.

To do any real work on an indexed image I already have to go by RGB.

Your idea of "real work" is obviously very different from mine. I do lots of real work on indexed images.

Duplicating this behavior in GEGL would not be appropriate in my opinion,

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.

Henning Makholm (henning@makholm.net) wrote:

Scripsit "Øyvind Kolås"

I cannot use the smudge or blur|sharpen tool, gaussian blur doesn't work neither does unsharp mask, layer masks seems to work but get their alpha thresholded.

Neither of which are something one usually needs in a situation where one wants to stick to a colormap while editing.

To do any real work on an indexed image I already have to go by RGB.

Your idea of "real work" is obviously very different from mine. I do lots of real work on indexed images.

Duplicating this behavior in GEGL would not be appropriate in my opinion,

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...

Bye, Simon

On 8/29/06, Simon Budig wrote:

Henning Makholm (henning@makholm.net) wrote:

Scripsit "Øyvind Kolås"

I cannot use the smudge or blur|sharpen tool, gaussian blur doesn't work neither does unsharp mask, layer masks seems to work but get their alpha thresholded.

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...

Having an implied conversion to RGB on input of indexed drawables is the way GEGL will currently deal with such images. Adding an op that converts this to 8bit/16bit/32bit integer grayscale with a predefined, or optimally computed R,G,B palette is the natural progression. That op could be used before saving/as a step towards displaying data.

This allows implementations of all other processing and compositing operations to be ignorant of indexed drawables, but is not an indexed workflow, it will not work when multiple of the original colors mapped to the same RGB triplet, but has a different interpretation.

/Øyvind K.

Scripsit Simon Budig

Henning Makholm (henning@makholm.net) wrote:

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.

It would work for me, if the surrounding application allowed me to set as a layer or image property that I want that operation to be applied _immediately_ for each drawing operation I do.

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...

My concrete need is that I edit bitmaps with a specific color convention - they can be seen e.g. at . I use a system of ad-hoc software to convert the bitmap source to the vector versions linked to below the image; this software depends on the exact colormap in the picture, because different colors should be vectorized in different ways.

[Before someone asks: yes, I have considered using a vector tool as the master editing format, but I have not found one whose user interface fits my way of working as well as Gimp does].

Now, when I edit in indexed mode I am sure that I don't accidentally give a pixel a color that is off the expected one by a delta that is too small for me to see. For example I sometimes accidentally select the airbrush or pen tool and draw something. I may not notice this until later, when it is too late to undo automatically, but at least with the implicit quantization it is immediately clear to me which pixels I need to repair manually. If I had worked in RGB mode I would need to wonder whether I had accidentally airbrushed something from 255/255/255 to 252/252/252, which is impossible to see by eye.

Essentially, indexed mode helps me by making sure that what I see is all I get. And does it *while* I edit: doing a separate quantization step at the end of my work and then going over all of the image in zoomed mode to look for glitches would be seriously bothersome.

On 8/29/06, Henning Makholm wrote:

Scripsit Simon Budig

Henning Makholm (henning@makholm.net) wrote:

Now, when I edit in indexed mode I am sure that I don't accidentally give a pixel a color that is off the expected one by a delta that is too small for me to see. For example I sometimes accidentally select the airbrush or pen tool and draw something. I may not notice this until later, when it is too late to undo automatically, but at least with the implicit quantization it is immediately clear to me which pixels I need to repair manually. If I had worked in RGB

snip<

Within the current gimp architecture you are asking for the job that op would be performing to be done in a display filter, with a fixed pallete (whilst working in RGB mode). This would cause all work being done on the image to be displayed with the reduced palette. Thus allow you to work "non-indexed" but see a reduced pallete result in realtime.

/Øyvind K.

Scripsit Øyvind Kolås

Within the current gimp architecture you are asking for the job that op would be performing to be done in a display filter, with a fixed pallete (whilst working in RGB mode). This would cause all work being done on the image to be displayed with the reduced palette. Thus allow you to work "non-indexed" but see a reduced pallete result in realtime.

No - I don't only want to _see_ a reduced-palette result; I want to actually _get_ a reduced-palette result. With an action purely on the display level, I cannot see or correct inaccuracies on the underlying pixel data; I cannot be sure that when I use the colorpicker tool it is the standard color that I see that gets picked up, etc.

Additionally, it _would_ be rather cool to have the pixel data in each layer be quantized but still be able to select partial layer opacities while editing.

On 8/29/06, Henning Makholm

My concrete need is that I edit bitmaps with a specific color convention - they can be seen e.g. at . I use a system of ad-hoc software to convert the bitmap source to the vector versions linked to below the image; this software depends on the exact colormap in the picture, because different colors should be vectorized in different ways.

This need could be solved using layer-masks and threshold. Or to attack the problem with an unstable dialect of xml:

/Øyvind K.

Scripsit "Øyvind Kolås"

On 8/29/06, Henning Makholm

My concrete need is that I edit bitmaps with a specific color convention - they can be seen e.g. at . I use a system of ad-hoc software to convert the bitmap source to the vector versions linked to below the image; this software depends on the exact colormap in the picture, because different colors should be vectorized in different ways.

This need could be solved using layer-masks and threshold. Or to attack the problem with an unstable dialect of xml:

I'm not sure I can see what you're getting at, but are you suggesting that I use a seperate layer for each color? That would make any kind of editing extremely painful.

Hi,

On Tue, 2006-08-29 at 15:14 +0200, Henning Makholm wrote:

Your idea of "real work" is obviously very different from mine. I do lots of real work on indexed images.

Perhaps you should write up a summary then that explains your workflow on real world examples. At the moment we are talking about "indexed images" and probably mean "how indexed images are currently treated in GIMP". But what exactly is it that you need? Is it working with a limited palette of colors? Is it the current behaviour of paint tools on indexed images? Is it the alpha-thresholding that is done for no good reason? I would really like to know what's important about indexed images so that we can see if there are ways to preserve or even improve that functionality.

Sven

Hi,

On Wed, 2006-08-30 at 18:49 +0930, David Gowers wrote:

Henning has already described what he does, and it seems clear to me that alpha-thresholding all paint application would work well for his purposes. I'm sure he'll say if that is not the case.

We still need a summary of all this for the design of GIMP 3.0. Unless we can agree on a document that describes what kind of "indexed image" support is needed for our target users, there isn't going to be any.

Sven

Scripsit "David Gowers"

Henning has already described what he does, and it seems clear to me that alpha-thresholding all paint application would work well for his purposes. I'm sure he'll say if that is not the case.

It sounds like a good direction, but I'm not sure that it would also be effective against an accidental application of, say, the smudge tool, or ordinary paint tools that accidentally get used in color-changing (rather than paint-applying) drawing modes.

Scripsit Sven Neumann

On Tue, 2006-08-29 at 15:14 +0200, Henning Makholm wrote:

Your idea of "real work" is obviously very different from mine. I do lots of real work on indexed images.

Perhaps you should write up a summary then that explains your workflow on real world examples.

Could you describe what you find missing in the explanation of my workflow on real-world examples that I have already posted?

But what exactly is it that you need?

As I have already explained, I need to be sure that I don't accidentally stray from a small predetermined number of colors.

Is it working with a limited palette of colors? Is it the current behaviour of paint tools on indexed images?

Yes and yes.

I would really like to know what's important about indexed images

The important things about indexed images is that they prevent me from accidentally creating pixel content that does not fit the colormap.

Scripsit "David Gowers"

On 8/30/06, Henning Makholm wrote:

I'm not sure I can see what you're getting at, but are you suggesting that I use a seperate layer for each color? That would make any kind of editing extremely painful.

When I saw it, I thought so too.
However, remember this is GEGL being discussed here. *GIMP* might well provide a way to back-propagate the result of an Op in the graph, which should take care of this okay.

If it's just an implementation detail, I don't care, of course. But I have difficulty imagining how this setup would be easier to code than a single actual layer whose pixel colors are simply constrained to those of the colormap.

Hi,

On Thu, 2006-08-31 at 12:34 +0200, Henning Makholm wrote:

Could you describe what you find missing in the explanation of my workflow on real-world examples that I have already posted?

We need a document explaining this which is not hidden in a mailing-list thread. A document that we can show to a user interface designer and that he/she is able. And we before we do this, we need to discuss here if we actually want such a feature, if it is at all part of our vision for GIMP.

Sven

Scripsit Sven Neumann

On Thu, 2006-08-31 at 12:34 +0200, Henning Makholm wrote:

Could you describe what you find missing in the explanation of my workflow on real-world examples that I have already posted?

We need a document explaining this which is not hidden in a mailing-list thread.

I'm afraid I am not able to post documents in less hidden places than mailing list threads.

On 9/4/06, Henning Makholm wrote:

We need a document explaining this which is not hidden in a mailing-list thread.

I'm afraid I am not able to post documents in less hidden places than mailing list threads.

Is wiki.gimp.org a less hidden place than mailing threads? :)

Alexandre

Hi,

On Mon, 2006-09-04 at 12:22 +0200, Henning Makholm wrote:

I'm afraid I am not able to post documents in less hidden places than mailing list threads.

The point is not where the document is posted. The mailing-list is fine for this, probably even the best place since it should be discussed. The point is that at the end of this discussion, there should be a self-contained document.

Sven

Hi,

On Mon, 2006-09-04 at 14:25 +0400, Alexandre Prokoudine wrote:

Is wiki.gimp.org a less hidden place than mailing threads? :)

Definitely. Putting something up on wiki.gimp.org is pretty much equivalent to writing it on a piece of paper and flushing it down the toilet. Noone notices when something is added to the wiki and it is very unlikely that a developer or user interface designer is ever going to read it.

Sven

On 9/4/06, Sven Neumann wrote:

On Mon, 2006-09-04 at 14:25 +0400, Alexandre Prokoudine wrote:

Is wiki.gimp.org a less hidden place than mailing threads? :)

Definitely. Putting something up on wiki.gimp.org is pretty much equivalent to writing it on a piece of paper and flushing it down the toilet. Noone notices when something is added to the wiki and it is very unlikely that a developer or user interface designer is ever going to read it.

What would it take one to finally add link to the wiki to the sidebar at gimp.org?

Alexandre

Alexandre Prokoudine wrote:

On 9/4/06, Sven Neumann wrote:

Definitely. Putting something up on wiki.gimp.org is pretty much equivalent to writing it on a piece of paper and flushing it down the toilet. Noone notices when something is added to the wiki and it is very unlikely that a developer or user interface designer is ever going to read it.

What would it take one to finally add link to the wiki to the sidebar at gimp.org?

A nice default theme for the wiki and someone who is willing to clean up obsolete stuff and has the permissions to do so.

That's just my opinion, of course :)

HTH, Michael

Hi,

On Mon, 2006-09-04 at 22:42 +0400, Alexandre Prokoudine wrote:

What would it take one to finally add link to the wiki to the sidebar at gimp.org?

Not much. That's why it was done some months ago. That doesn't change anything about the fact that wiki.gimp.org is ugly, hopelessly unstructured and pretty much unmaintained.

Sven