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
[Gimp-developer] http://layers.gimp.org/ is Ugly
Hi all! I'm afraid to say that http://layers.gimp.org/ is incredibly ugly, and makes us look very bad. As people who develop an image editing software we should have at least a bit of rudimentary aesthetic sense. Carol told me she tried to make it look like the Layers dialog. Well, that's not what I'd like to see there, and even so with some CSS and images it can look much better. In any case, a web page can be even more visually appealing without trying to emulate a GUI dialog. Other problems in the site: 1. There is no RSS feed as link in the head. 2. The tabs at the top (Layers, Paths, etc.) are cryptic and also their links don't contain the 'title=' attributes. 3. The title of the page just reads GIMP Layers without any explanation that we refer to an aggregated feed of the GIMP developers blogs. 4. There are no links at the side to the individual blog homepages and their feeds. Please fix all that. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-web] http://layers.gimp.org/ is Ugly
On Tuesday 29 August 2006 13:07, Carol Spears wrote: On Tue, Aug 29, 2006 at 12:30:59PM +0300, Shlomi Fish wrote: Please fix all that. do you want me to remove your feed from that planet instance? Carol, I already told you on the IRC that I don't want such a thing. I don't want the GIMP planets to disappear or my feeds to be removed them. I think they are a very good thing to have. However, I do want their problems to be resolved, so everyone can enjoy them better. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] http://layers.gimp.org/ is Ugly
CCed to the list because I hate it when people email me annoying emails in private, and expect private responses. (see: http://www.mail-archive.com/iglu-web%40iglu.org.il/msg01595.html ) On Tuesday 29 August 2006 13:14, Carol Spears wrote: hello, when i put together the people for the gtk+ planet, i limited it to only those who had contributed for the current version cycle. I disagree with this strategy. First of all, because it may imply that people that did not contribute for the next version will be removed. And secondly, because many people contributed in the past and are worth mentioning. ugly maybe is a better word to describe people who make minimum contributions and have maximum opinions and needs. This is not the case for me. I've made many past and present contributions to the GIMP. And I never had maximum opinions and needs. 'not my taste' is better to describe web page formating. Perhaps. But I believe most people will find it not their taste, which in this case will make it ugly. And the usability problems I've mentioned are perfectly objective issues. And just to match my requests with code, if you'll give me a pointer to the code of the planet, I will perform the necessary changes. Carol, will you stop being so annoying? You're doing more harm than good, your logic sucks, and you seem to have a grudge against the entire world. Please stop, or I'll recommend and support that you'll no longer have access to the gimp.org facilities, and that all posts from you to the gimp mailing lists will be moderated. thanks for your continued contribution, You're welcome. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-web] http://layers.gimp.org/ is Ugly
Hi folks, On Tue, Aug 29, 2006 at 12:30:59PM +0300, Shlomi Fish wrote: I'm afraid to say that http://layers.gimp.org/ is incredibly ugly, and makes us look very bad. As people who develop an image editing software we should have at least a bit of rudimentary aesthetic sense. Carol told me she tried to make it look like the Layers dialog. Well, that's not what I'd like to see there, and even so with some CSS and images it can look much better. In any case, a web page can be even more visually appealing without trying to emulate a GUI dialog. Besides the technical problems, I think you should propose a new site layout than just pestering about the current layout. I think 'ugly' is a very subjective term and if no one comes up with something better I wouldn't change anything in Carols position. This is similar to what GIMP users nag the developers about (Usability, Window Management, etc) Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgpoyquJZLWnt.pgp Description: PGP signature ___ 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] Re: [Gimp-web] http://layers.gimp.org/ is Ugly
On Tuesday 29 August 2006 14:34, Roman Joost wrote: Hi folks, On Tue, Aug 29, 2006 at 12:30:59PM +0300, Shlomi Fish wrote: I'm afraid to say that http://layers.gimp.org/ is incredibly ugly, and makes us look very bad. As people who develop an image editing software we should have at least a bit of rudimentary aesthetic sense. Carol told me she tried to make it look like the Layers dialog. Well, that's not what I'd like to see there, and even so with some CSS and images it can look much better. In any case, a web page can be even more visually appealing without trying to emulate a GUI dialog. Besides the technical problems, I think you should propose a new site layout than just pestering about the current layout. I think 'ugly' is a very subjective term and if no one comes up with something better I wouldn't change anything in Carols position. This is similar to what GIMP users nag the developers about (Usability, Window Management, etc) Well, we can use any of the following designs, which are much better: * http://www.planetapache.org/ * http://advogato.ev-en.org/ * http://planet.gnome.org/ * http://planetsun.org/ I recall seeing even better looking planets in my neverending web surfing. Plus, we can always re-use a theme of WordPress or whatever. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets. ___ 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] Re: [Gimp-web] http://layers.gimp.org/ is Ugly
On Aug 29, 2006, at 3:58 PM, Shlomi Fish wrote: Well, we can use any of the following designs, which are much better: * http://www.planetapache.org/ * http://advogato.ev-en.org/ * http://planet.gnome.org/ * http://planetsun.org/ I recall seeing even better looking planets in my neverending web surfing. Plus, we can always re-use a theme of WordPress or whatever. I personally much prefer the current custom, unique layout than ripping either one of those (or any other, for that matter) sites' layouts or simply taking a wordpress theme and adapting it. I don't necessarily agree with the current one being ugly, per se, though I agree it needs some work. Mostly it's too bulky. I like the idea of making it look like a layers dialog a lot. Regards, Marco Wessel ___ 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] Re: [Gimp-web] http://layers.gimp.org/ is Ugly
On 8/29/06, Shlomi Fish wrote: Well, we can use any of the following designs, which are much better: * http://www.planetapache.org/ * http://advogato.ev-en.org/ * http://planet.gnome.org/ * http://planetsun.org/ I recall seeing even better looking planets in my neverending web surfing. Plus, we can always re-use a theme of WordPress or whatever. Then there is no sense in naming the planet layers anymore. I agree that implementation could be better, though I can even imagine how exactly within current approach). Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] http://layers.gimp.org/ is Ugly
Von: Shlomi Fish [EMAIL PROTECTED] On Tuesday 29 August 2006 13:14, Carol Spears wrote: when i put together the people for the gtk+ planet, i limited it to only those who had contributed for the current version cycle. I disagree with this strategy. First of all, because it may imply that people that did not contribute for the next version will be removed. And secondly, because many people contributed in the past and are worth mentioning. IMO it is worth mentioning that we did discuss a similiar distinction for the GIMP about dialog during LGM. Right now, it looks like GIMP has a huge amount of active developers. This may explain why some people think that we're turining down enhancement requests because we don't like them, while the reason is we just don't have the manpower. So carol's trategy doesn't sound like the worst possible metric to me. Likewise, the feeds provided at gimp.org should be about people involved with GIMP. Originally there was one feed for the active developers and and for active users. IMO it should also be limited to posts in the respective person's gimp- or graphics-related categories. For example, we do not need to relay conspiracy theories or nationalist thoughts. Regards, Michael -- Feel free – 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ 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
[Gimp-developer] Re: [Gimp-web] http://layers.gimp.org/ is Ugly
From: Shlomi Fish [EMAIL PROTECTED] I'm afraid to say that http://layers.gimp.org/ is incredibly ugly, and makes us look very bad. As people who develop an image editing software we should have at least a bit of rudimentary aesthetic sense. If this were a bug report, the first thing we would do is demand that the bug reporter apologize for using such unnecessarily abusive language, and explain that antagonizing people is not the way to get a problem fixed. Well, it *is* a bug report! -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ 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
