Re: [Gimp-developer] Hard edged Ink tool?
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
Scripsit David Gowers [EMAIL PROTECTED] 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. -- Henning Makholm They discussed old Tommy Somebody and Jerry Someone Else. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
Scripsit Sven Neumann [EMAIL PROTECTED] 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. -- Henning MakholmI have seen men with a *fraction* of your trauma pray to their deity for death's release. And when death doesn't arrive immediately, they reject their deity and begin to beg to another. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
Scripsit David Gowers [EMAIL PROTECTED] On 8/30/06, Henning Makholm [EMAIL PROTECTED] 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. -- Henning Makholm Science, by its nature, is an uncertain undertaking, and offers plenty of opportunity for failure no matter how you approach it. Yet among the myriad ways to get nowhere, the only fully reliable one is doing and thinking the same as everyone else. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
On 8/30/06, Sven Neumann [EMAIL PROTECTED] wrote: 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 indexedimages and probably mean how indexed images are currently treated inGIMP. 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 onindexed images? Is it the alpha-thresholding that is done for no goodreason? 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 improvethat functionality.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. As for the good of alpha-thresholding, it prevents 'junk' colored pixels that often occur when quantizing quickly to a small palette (solid part of applied paint is colored okay, semitransparent part is colored strangely.. like a bright orange with a medium green) -- cloning a multicolored pattern onto such an image may give you an idea of what I'm talking about. Junk colors are harmful both for mapping (as Henning described) and sprites (where the total amount of pixels is small enough that a single discolored pixel is a significant glitch, and makes it look even worse when palette-swapped) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
On 8/29/06, Sven Neumann [EMAIL PROTECTED] wrote: Gegl doesn't support images with indexed colors and I very much doubtthat it ever will support it. It is rather likely that indexed mode willbe 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 befulfilled by a different application then.Ah. It's not so much a need, as the tools would be much faster in indexed mode (eg 'shade' mode -- painting that cause pixels to change to the next brighter or darker color in the palette). Naturally palette searching would be needed for that in RGB mode, as opposed to running the indice through a 256-entry lookup table. However, I suspect that simply having a 'indexize'* op just before the display op in the graph would probably work well enough (possibly better, even).*or 'quantize' -- whatever it would be called, where it receives RGB data and outputs quantized RGB data. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
Scripsit Sven Neumann [EMAIL PROTECTED] 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. -- Henning Makholm It was intended to compile from some approximation to the M-notation, but the M-notation was never fully defined, because representing LISP functions by LISP lists became the dominant programming language when the interpreter later became available. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
On 8/29/06, Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Sven Neumann [EMAIL PROTECTED] 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. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
On 8/29/06, Henning Makholm [EMAIL PROTECTED] wrote: 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.Smudge and layer masks are two things that I would appreciate for indexed images. I already have workarounds which let me return the results to the appropriate palette quickly, that is how I found that out. 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.Yes. 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, aslong as the net effect of don't let my editing result in pixel colors outside this small predeterined palette is still attainable with thesum of GEGL + futureGimp.That is essentially what I want, too. Henning Makholm This imposes the restriction on anyprocedure statement that the kind and type of each actual parameter be compatible with the kind and type of the corresponding formal parameter.Is that quote meant to be hard to understand? Or just to demonstrate how awkward english can be? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
Henning Makholm ([EMAIL PROTECTED]) wrote: Scripsit Øyvind Kolås [EMAIL PROTECTED] 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 -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
On 8/29/06, Simon Budig [EMAIL PROTECTED] wrote: Henning Makholm ([EMAIL PROTECTED]) wrote: Scripsit Øyvind Kolås [EMAIL PROTECTED] 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. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
On 8/29/06, Øyvind Kolås [EMAIL PROTECTED] wrote: 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 grayscalewith a predefined, or optimally computed R,G,B palette is the naturalprogression. That op could be used before saving/as a step towards displaying data.This allows implementations of all other processing and compositingoperations to be ignorant of indexed drawables, but is not an indexedworkflow, it will not work when multiple of the original colors mapped to the same RGB triplet, but has a differentinterpretation.I believe that last thing is a minor issue that should be addressable by an output op; Certainly, actually editing with identical colors that have different indices is unhelpful and confusing. Some kind of custom remapping for a certain set of colors would probably be the way to go. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
Scripsit Simon Budig [EMAIL PROTECTED] Henning Makholm ([EMAIL PROTECTED]) 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 http://dk.trackmap.net/a. 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. -- Henning Makholm*Vi vil ha wienerbrød!* ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
On 8/29/06, Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Simon Budig [EMAIL PROTECTED] Henning Makholm ([EMAIL PROTECTED]) 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. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
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. -- Henning Makholm The practical reason for continuing our system is the same as the practical reason for continuing anything: It works satisfactorily. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
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 http://dk.trackmap.net/a. 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: image width='751' height='650' layers layer name='brown' layer mode='apply_mask' filter mode='threshold' grayscalelayer/ /layer layer color='rgb(0.5,0.5,0.2)'/ layer name='blue' layer mode='apply_mask' filter mode='threshold' grayscalelayer/ /layer layer color='rgb(0.0,0.0,1.0)'/ layer name='violet' layer mode='apply_mask' filter mode='threshold' grayscalelayer/ /layer layer color='rgb(0.0,1.0,1.0)'/ layer name='black' layer mode='apply_mask' filter mode='threshold' grayscalelayer/ /layer layer color='rgb(0.0,0.0,0.0)'/ layer name='green' layer mode='apply_mask' filter mode='threshold' grayscalelayer/ /layer layer color='rgb(0.0,1.0,0.0)'/ layer name='red' layer mode='apply_mask' filter mode='threshold' grayscalelayer/ /layer layer color='rgb(1.0,0.0,0.0)'/ /layer layer color='rgb(1.0,1.0,1.0)'/ /layer /image /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
Scripsit Øyvind Kolås [EMAIL PROTECTED] 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 http://dk.trackmap.net/a. 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. -- Henning MakholmDe kan rejse hid og did i verden nok så flot Og er helt fortrolig med alverdens militær ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
On 8/30/06, Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Øyvind Kolås [EMAIL PROTECTED] 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 http://dk.trackmap.net/a.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 suggestingthat I use a seperate layer for each color? That would make any kindof 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.By back-propagate i mean, you draw on a layer, it get quantized before display -- and you can propagate that change back to the original layer. It seems a highly desireable option to me, even for non-quantized images.(nor is GEGL in any way suited to implement back-propagation of the sort you described. It goes against its data model; Whereas this is suitable for GIMP to implement.) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
