Re: [Gimp-developer] What would be a better set of default resources?
On Wednesday 22 July 2009 00:37:43 Sven Neumann wrote: Hi, On Tue, 2009-07-21 at 18:33 -0300, Joao S. O. Bueno wrote: I d'be against the removal of the vintage pixmaped brushes. Why? Tell us a good reason then why we should keep them. Ive done a few quite nice wallpapers with just dynamics and wine and spark brushes, so these two with dynamics on board definitely have value. Pepper brush in my eyes has value as something that clearly exhibits the effect of dynamics and as such is useful for demo purposes, so one vote from me against removing them. Like I said, they are not whats wrong wit gimps resources today. the problem is brushes that are identical in shape and only vary in size. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On 07/20/2009 06:43 AM, Laxminarayan Kamath wrote: On Mon, Jul 20, 2009 at 4:06 AM, Martin Nordholtsense...@gmail.com wrote: Hi, With the integration of tagging support in GIMP we have a mechanism that allows us to organize resources (brushes, patterns, palettes, and gradients). This enables us to add a bigger set of default resources. I would re-suggest integrating GHNS or have a similar way of easy sharing of resources from The GIMP or all CREATE projects. Once that is done, the most popular brushes can be added to the default set. What say ?? Just my 2 cents. I would support someone wanting to implement GHNS. It looks to me though that the spec needs to be augmented with support for resources that are tagged. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
Indeed, they are good examples. For me, the thing is : why these examples ? To give examples doesn't mean not to justify them. A justification could be the need of the users, if after a study it appears that the color Brush the most relevant to provide by default is a Pepper, I would understand. Unfortunately, I don't think so. I could also totally understand if someone justifies it by saying it's for historical reason, the Pepper is a symbol for Gimp. Moreover I think I'm not mistaken if I say that a large set of casual users keep using Gimp with the default brush set and don't add custom ones. My opinion would be that the more useful brushes they have, the more they will feel creative. This is why I think Gimp should be shipped with a large set of useful brushes. Steren On Wed, Jul 22, 2009 at 12:53 AM, Rob Antonishen rob.antonis...@gmail.comwrote: One reason to keep some image hose brushes in the default set is just to demonstrate that gimp supports them! I participate in a web forum for amateur cartography, and one of the most common requests is how to use tubes with photoshop. Most are extremely impressed that this capability exists in Gimp. -Rob A On 7/21/09, Sven Neumann s...@gimp.org wrote: Hi, On Tue, 2009-07-21 at 18:33 -0300, Joao S. O. Bueno wrote: I d'be against the removal of the vintage pixmaped brushes. Why? Tell us a good reason then why we should keep them. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On 07/20/2009 10:29 AM, Alexandre Prokoudine wrote: On Mon, Jul 20, 2009 at 2:36 AM, Martin Nordholts wrote: * Add larger variants of the circle and fuzzy circle brushes, say 50, 100, 250 and 500 px The prerequisite for this is GIMP not playing a dying turtle that climbs up to Kilimanjaro top while drawing with a 200+ px brush :) On my computer, painting with a 500px brush on an A4 has acceptable performance. I don't think performance problems should keep us from adding better resources. It would of course be nice if someone looked into what exactly what is slow and if it would be easy to improve performance. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2 part - Scripts to be included in the core, and keybindings?
On 07/20/2009 06:14 PM, Rob Antonishen wrote: Couple quick questions... How is it decided what scripts should be included in the core? If they help us fulfill the product vision [1], they should be added. For example, I have created a new script with a number of menu entries to grow selections orthogonally (like PS with alt and shift-alt cursors) which, when bound to the appropriate keys can be quite handy. (It was asked for at the plugin registry). Would this be of value in the core distribution? In my opinion, these scripts are useful enough to be distributed with vanilla GIMP. Could you create a git commit that adds these? Also - is there anyway to have a script create its own keybinding (assuming it is free)? No, but GIMP can ship with a menurc file that create a default keybinding for the script. Include that in the commit. / Martin [1] http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On 07/20/2009 11:10 AM, Alexia Death wrote: * Add larger variants of the circle and fuzzy circle Please no, there's too many round brushes already and bigger ones would look exactly the same and add confusion. There should not be 2 brushes that look to be the same shape in the default set. Hi Alexia, I get your drift, but is it really reasonable to force a user to scale a say 250px brush to 3px if that is what he desires? It might be, but I don't think it is with our current scaling mechanism. What do you think bout offering a range of brushes that together covers a big radius spectrum? Since scaling currently can be done in the range 10%-1000%, how about these radiuses for the Circle and Fuzzy Circle ones: 10px, 50px, 250px * Try to get rid of the Pepper, Sparks and Vine brushes They represent quite nice examples of bitmap brushes and I don't mind at all that they stick around, after all theres only 3 of them compared to 10+ round brushes. Combined with dynamics they make perfect example/demo brushes. See above for the real annoyance. I agree that we should ship example brushes that shows all capabilities of our brush system, but I question the genericness of the Pepper and Vine brushes. The best would be if we could create a more generic sample brush for demo purposes. Default set of resources should include some tool presets, like some common aspect ratio fixed presets(2:3, 3:4) for crop tool That's Bug 156858 – Add option menu of standard aspect ratios to ratio-using tools [1] / Martin [1] http://bugzilla.gnome.org/show_bug.cgi?id=156858 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On 07/20/2009 03:28 PM, Alexandre Prokoudine wrote: On Mon, Jul 20, 2009 at 2:36 AM, Martin Nordholts wrote: Hi, With the integration of tagging support in GIMP we have a mechanism that allows us to organize resources (brushes, patterns, palettes, and gradients). This enables us to add a bigger set of default resources. What I'd love to see instead/alongside is sane defaults. While Pencil is a brush based tool, users do not actually expect it to behave like a brush. But right now Pencil and Brush use same brush by default: Circle Fuzzy (19), 0,90 scaled, pressure mapped to opacity. Instead Pencil should be a Circle (03) brush, because it's a Pencil :) +1 from me ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On 07/20/2009 06:19 PM, Emil Assarsson wrote: What I really miss is to be able to remove brushes that I don't need and sort/group the ones I use a lot. Maybe it would be better that most - if not all - of the brushes where copied to the users profile as a default instead of being static. I agree with that we should copy the standard brushes to the user profile when the profile is created, just as we do with the default tags. Users/distros/installers wanting to use the read-only brushes for some reason could manually add /usr/share/gimp/2.0/brushes the brush path. Unless someone disagrees here I might actually hack on this soon. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
Martin Nordholts wrote: I get your drift, but is it really reasonable to force a user to scale a say 250px brush to 3px if that is what he desires? It might be, but I don't think it is with our current scaling mechanism. What do you think Regarding this, as an user (and not a programmer), I've always wondered why in the case of vector brushes a scaling setting is used instead of fiddling directly (and easily) with their size. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Request for usage of GIMP logo graphic
On 07/22/2009 06:39 AM, Jonathan Wolf wrote: Hello, I am interested in using the GIMP logo graphic in a commercial product under a special thanks page in the credits. Who would I need to get in contact with to ask for permission for usage? You would either have to comply with the license the graphic is under, or get explicit permission from the author to use it, or just invoke fair use. Exactly what graphic are you talking about? / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On Wed, 22 Jul 2009 12:03:31 +0200 Martin Nordholts ense...@gmail.com wrote: I get your drift, but is it really reasonable to force a user to scale a say 250px brush to 3px if that is what he desires? It might be, but I don't think it is with our current scaling mechanism. What do you think bout offering a range of brushes that together covers a big radius spectrum? Since scaling currently can be done in the range 10%-1000%, how about these radiuses for the Circle and Fuzzy Circle ones: 10px, 50px, 250px As a user who is constantly scaling up the largest fuzzy circle brush, I'd love to see a different interface... but not in the form of more burshes. How about, as Alexia suggested, a single brush and a size box, which could be a combo box offering the standard sizes, plus the option to enter a custom size. Expressing this size in pixels would make them a little less abstract than they currently are, which would make it easier to work with. -- Jon Senior j...@restlesslemon.co.uk ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On 07/22/2009 12:18 PM, SHIRAKAWA Akira wrote: Martin Nordholts wrote: I get your drift, but is it really reasonable to force a user to scale a say 250px brush to 3px if that is what he desires? It might be, but I don't think it is with our current scaling mechanism. What do you think Regarding this, as an user (and not a programmer), I've always wondered why in the case of vector brushes a scaling setting is used instead of fiddling directly (and easily) with their size. I agree with you (and Jon) about this. It would be better to focus on getting scaling (or perhaps better worded, size adjustments to brushes) to work better instead of being lazy and trying to work around this by adding several sizes of the same brush. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On Tue, Jul 21, 2009 at 12:16 AM, Sven Neumann wrote: Easy enough, just unset the 'global-brush' property. I am not sure though if that would make a good default for the average user. So far I only heard from users thanks, but why is it not by default? :) Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On Wed, Jul 22, 2009 at 14:12, Alexandre Prokoudinealexandre.prokoud...@gmail.com wrote: On Tue, Jul 21, 2009 at 12:16 AM, Sven Neumann wrote: Easy enough, just unset the 'global-brush' property. I am not sure though if that would make a good default for the average user. So far I only heard from users thanks, but why is it not by default? :) I guess you wouldn't hear from people who like it the way the default is set, would you? :) Greetings, Fredrik. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
2009/7/22 Fredrik Alströmer wrote: On Wed, Jul 22, 2009 at 14:12, Alexandre Prokoudinealexandre.prokoud...@gmail.com wrote: On Tue, Jul 21, 2009 at 12:16 AM, Sven Neumann wrote: Easy enough, just unset the 'global-brush' property. I am not sure though if that would make a good default for the average user. So far I only heard from users thanks, but why is it not by default? :) I guess you wouldn't hear from people who like it the way the default is set, would you? :) I don't expect to hear from people who never use Pencil tool, if that's what you mean :) I don't really know what else to say. Clear separation of default settings for different tools is such an obvious thing... Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
2009/7/22 Fredrik Alströmer r...@excu.se On Wed, Jul 22, 2009 at 14:12, Alexandre Prokoudinealexandre.prokoud...@gmail.com wrote: On Tue, Jul 21, 2009 at 12:16 AM, Sven Neumann wrote: Easy enough, just unset the 'global-brush' property. I am not sure though if that would make a good default for the average user. So far I only heard from users thanks, but why is it not by default? :) I guess you wouldn't hear from people who like it the way the default is set, would you? :) Well you can hear from me: I like the global-brush setting; if it is accidentally turned off I find it very annoying, having to reselect brush between tools... usually I *do* want to keep just the same brush between tools. When I think about it, I wonder whether such users ever get to using GIMP with any level of frequency or intensity, as IMO with the global-brush option off, there is an unavoidable mental 'thunk' to accommodate for the possible change of brush as you change tool; global-brush == off seems in this way to inherently slow the user's workflow (regardless of what workflow they use -- having to think 'oh, what is the brush of this tool' == slowdown.) A related issue is the difficulty of reliable brush selection. ideally I would hit a shortcut (say CTRL+B) and then type part of a brush name and hit enter to select it. The current brush selection methods either require direct pointing, are inaccurate, or only allow relative selection (ie. next brush, prev brush) (note: you can do absolute brush selection by this method IIRC: make sure your brushes dialog is set to List, then when you want to select a brush by name, hit [the shortcut for the brushes dialog], then CTRL+F and type the name fragment. This has two downsides - a) it's too much keyboard work for a common operation, b) it changes the focus, which means I have to mouse back to the image window or ALT-TAB before I can continue as before (say, adjusting the drawing opacity before I start painting)) Also, Alexandre says: Clear separation of default settings for different tools is such an obvious thing... I agree with that. Unfortunately, having sensible, different defaults for different tools is in direct conflict with having an efficient, un-surprising workflow (and everyday workflow takes priority IMO.. A person remains a newbie for only so long, but the general consistency of workflow is something they will need to deal with as long as they use GIMP -- including any bureaucratic lumps such as (global-brush == off)) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On 07/20/2009 12:36 AM, Martin Nordholts wrote: Does anyone have any suggestions on adjustments and additions to the default set of GIMP resources? Thanks for the great feedback everyone. Summing it up, these are the current desired adjustments to the default set of resources. We should: * Add rake brushes * Add more bristle brushes * Add more realistic patterns from commonly used artistic media * Add more complex vector based brushes because of their good scaling properties * Add Hardedge FG to BG gradient * Add dynamics enabled presets for paint tools * Add large round brushes and remove all smaller duplicates * Add a selected subset of GIMP Paint Studio brushes and presets * Add texture/grunge brushes * Remove the outline squares * Convert small bitmap brushes to larger variants * Either create better example brushes of GIMP's capabilities, or keep existing ones Now we just need to collect or create these resources for inclusion in GIMP 2.8. For this purpose, I have created an enhancement request Bug 589371 – Improve default set of resources [1] Please attach - or if the resource is big, link to - resources there. We will then add these to GIMP 2.8 when the time comes. Please make sure to keep any discussion on-list though, we don't want any discussion in bugzilla. / Martin [1] http://bugzilla.gnome.org/show_bug.cgi?id=589371 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
2009/7/22 David Gowers wrote: tools. When I think about it, I wonder whether such users ever get to using GIMP with any level of frequency or intensity, as IMO with the global-brush option off Don't wonder -- they do. And I do too :) (Speaking of which, the fact that tools presets don't save/restore scale value isn't helpful either.) Clear separation of default settings for different tools is such an obvious thing... I agree with that. Unfortunately, having sensible, different defaults for different tools is in direct conflict with having an efficient, un-surprising workflow Contrary to that I would yell every time I switched from Paintbrush to Eraser if I didn't have global brush disabled. It's way too convenient to use e.g. smaller eraser *automatically* than changing scale back and forth. As you say, workflow is what matters :) But it looks like this discussion is going nowhere, so EOT for me :) Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
Martin Nordholts wrote on Wed, Jul 22, 2009 at 03:05:38PM +0200: On 07/20/2009 12:36 AM, Martin Nordholts wrote: Does anyone have any suggestions on adjustments and additions to the default set of GIMP resources? Thanks for the great feedback everyone. Summing it up, these are the current desired adjustments to the default set of resources. Sorry for being late. For photo touchup, what I'd like to see is fuzzy brushes with different intensity curves going to the outside. I think it would be good to have 1] what we have now, 2] a curve that bumps intensity on the outside sooner (will have a more prominent full opacity in the middle) and 3] the inverse of 2]. So far I've been too lazy to make them but if there are other people missing them I'd be happy to make a set (please send private mail). Speaking of brushes - brush rotation which currently requires a plugin (which is a little painful to use as it isn't interactive) is high on my wishlist. Since I'm wishlist-spamming anyway, what I'd also like is fuzzy brushes with adjustable center (full intensity not in the middle). And stretchable in one dimension. I guess what I need is a quick capability to iwarp brushes. BTW, iwarp rocks. Martin -- %%% Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On 07/22/2009 03:28 PM, Martin Cracauer wrote: Speaking of brushes - brush rotation which currently requires a plugin (which is a little painful to use as it isn't interactive) is high on my wishlist. Brush rotation is implemented in git master and will be part of GIMP 2.7.0. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
Hi, shirakawa.ak...@gmail.com (2009-07-22 at 1218.30 +0200): Martin Nordholts wrote: I get your drift, but is it really reasonable to force a user to scale a say 250px brush to 3px if that is what he desires? It might be, but I don't think it is with our current scaling mechanism. What do you think Regarding this, as an user (and not a programmer), I've always wondered why in the case of vector brushes a scaling setting is used instead of fiddling directly (and easily) with their size. I avoid scale whenever I can, so for vector brushes I just use the brush editor. And I would wish any other brush would be editable. In other words, support pixmap as shape for the editor, or some other solution instead of the current mix of methods. GSR ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] How far away from watching other colorspaces in real time?
Hi. Can somebody tell me how far away GIMP is from being able to view manipulations that you do in a different color space in real time in real colors? I could get along with constant recomposing to view with HSV. But I have recently discovered the LAB colorspace which does really useful things for me. But now it is a pain that I cannot mess with the LAB layers and see how the picture looks like. Photoshop seems to do it, although I haven't personally observed it. How do they do it quick enough? Is it quick in the first place? Even a preview with a much smaller picture or magnified rectangle would be very useful. I don't need too high precision since I usually take the result of LAB layers for mixing with existing layers, so the colors coming out of LAB aren't the final word. Martin -- %%% Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How far away from watching other colorspaces in real time?
On 07/22/2009 11:59 PM, Martin Cracauer wrote: Hi. Can somebody tell me how far away GIMP is from being able to view manipulations that you do in a different color space in real time in real colors? Hi, The current plan is get GIMP 2.8 out the door asap, hopefully within the next few months. Once that is done we will finish porting GIMP to GEGL. That means finally getting rid of all 8bpc-only code and introduce the GEGL data types. With the help of the babl library, GEGL can transparently process image data in any color space, including CIE Lab. See http://www.gegl.org/babl/BablFishPath.html for a more complete list. Currently, neither babl nor GEGL is aware of ICC color profiles, but I don't expect it to be too much work to make GEGL color-profile aware. It is just a matter of feeding the right data into GEGL, which for the vast majority of operations works in linear light RGBA float. So, once we have GEGL in place, working in any color space that has a one-to-one mapping to and from linear light RGBA (this does not include CMYK), should be fairly trivial. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How far away from watching other colorspaces in real time?
Martin Nordholts wrote on Thu, Jul 23, 2009 at 12:16:34AM +0200: On 07/22/2009 11:59 PM, Martin Cracauer wrote: Hi. Can somebody tell me how far away GIMP is from being able to view manipulations that you do in a different color space in real time in real colors? Hi, The current plan is get GIMP 2.8 out the door asap, hopefully within the next few months. Once that is done we will finish porting GIMP to GEGL. That means finally getting rid of all 8bpc-only code and introduce the GEGL data types. With the help of the babl library, GEGL can transparently process image data in any color space, including CIE Lab. See http://www.gegl.org/babl/BablFishPath.html for a more complete list. That sounds great. Do I understand that correctly that you will move to single-floats/color? What exactly happens when you select the use GEGL menu item right now? It uses GEGL but only with the current capabilities? Does it give more than 8 bits/pixel? Martin -- %%% Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
Hi, On Wed, 2009-07-22 at 23:54 +0200, GSR - FR wrote: I avoid scale whenever I can, so for vector brushes I just use the brush editor. Scaling a vector brush from the tool options is equivalent, at least from an implementation point of view, to changing its size in the brush editor. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
Hi, On Tue, 2009-07-21 at 18:53 -0400, Rob Antonishen wrote: One reason to keep some image hose brushes in the default set is just to demonstrate that gimp supports them! I participate in a web forum for amateur cartography, and one of the most common requests is how to use tubes with photoshop. Most are extremely impressed that this capability exists in Gimp. Sure, but then we should ship a useful image hose brush. There are actually a few useful ones in the standard distribution and they can stay. Pepper however is not an image hose. It's not interesting as an example, it doesn't show off any outstanding capabilities, it's quite likely never going to be used. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How far away from watching other colorspaces in real time?
On 07/23/2009 12:27 AM, Martin Cracauer wrote: Do I understand that correctly that you will move to single-floats/color? Yes, virtually all image processing and compositing will be performed in the linear light RGBA color space with 32 bit float depth per channel. There have been discussions about introducing regression tested optimizations for 8 and 16 bit depths, but I don't expect any effort to be put into that soon. First, we need to finalize getting GEGL into GIMP. What exactly happens when you select the use GEGL menu item right now? It uses GEGL but only with the current capabilities? Does it give more than 8 bits/pixel? If you in GIMP 2.6 enable Colors - Use GEGL, then the image processing itself will occur in RGBA float for the color tools. However, the data being processed is stored as RGBA u8. That means that if you do an color adjustment with Use GEGL enabled, then you first have to convert that data to RGBA float for processing, and than back to RGBA u8 to store it again. In other words, not very useful to the end user. If you in the yet not officially released GIMP 2.7 do View - Use GEGL, then the layers will be composited using GEGL. In other words, we have the layers etc ported to a GEGL graph. It is worth mentioning that it is technically trivial to insert non-destructive nodes in the graph, but our focus now is getting GIMP 2.8 out. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
Hi, On Wed, 2009-07-22 at 12:10 +0200, Martin Nordholts wrote: On 07/20/2009 06:19 PM, Emil Assarsson wrote: What I really miss is to be able to remove brushes that I don't need and sort/group the ones I use a lot. Maybe it would be better that most - if not all - of the brushes where copied to the users profile as a default instead of being static. I agree with that we should copy the standard brushes to the user profile when the profile is created, just as we do with the default tags. Users/distros/installers wanting to use the read-only brushes for some reason could manually add /usr/share/gimp/2.0/brushes the brush path. Unless someone disagrees here I might actually hack on this soon. We discussed this before and came to the conclusion that it's a bad idea. What should be done instead of polluting the user directory with such copies is to create a copy transparently whenever the user edits a system resource. And there should be the possibility to easily hide system resources. The new tags system should help with this. Being able to hide resources by adding a 'hidden' tag was one of the reasons for adding tags in the first place. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
Hi, s...@gimp.org (2009-07-23 at 0031.55 +0200): On Wed, 2009-07-22 at 23:54 +0200, GSR - FR wrote: I avoid scale whenever I can, so for vector brushes I just use the brush editor. Scaling a vector brush from the tool options is equivalent, at least from an implementation point of view, to changing its size in the brush editor. That is a technical detail, as technical as Gimp having done brush scaling for some time before it even got scale widget (side effect of tablets and pressure mapping, it had to scale brushes, whatever way it was done then or now). The points are the separate GUI, the mental maths required or the try and error workflow until you find the right size for brush changes, which are the issues the user has to cope with; versus a(n unified) pixel size control (currently non unified as it only works for vector ones, leaving pixmaps in the tiresome usage mode). GSR ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On 07/23/2009 12:39 AM, Sven Neumann wrote: Hi, On Wed, 2009-07-22 at 12:10 +0200, Martin Nordholts wrote: On 07/20/2009 06:19 PM, Emil Assarsson wrote: What I really miss is to be able to remove brushes that I don't need and sort/group the ones I use a lot. Maybe it would be better that most - if not all - of the brushes where copied to the users profile as a default instead of being static. I agree with that we should copy the standard brushes to the user profile when the profile is created, just as we do with the default tags. Users/distros/installers wanting to use the read-only brushes for some reason could manually add /usr/share/gimp/2.0/brushes the brush path. Unless someone disagrees here I might actually hack on this soon. We discussed this before and came to the conclusion that it's a bad idea. What should be done instead of polluting the user directory with such copies is to create a copy transparently whenever the user edits a system resource. And there should be the possibility to easily hide system resources. The new tags system should help with this. Being able to hide resources by adding a 'hidden' tag was one of the reasons for adding tags in the first place. We could either introduce a complex system to allow the user to delete system resources, or we could make it simple for ourselves and the user and just initialize the user dir with a set of default resources. I don't understand why we have to solve this in a complex way. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
Hi, On Thu, 2009-07-23 at 00:51 +0200, Martin Nordholts wrote: We could either introduce a complex system to allow the user to delete system resources, or we could make it simple for ourselves and the user and just initialize the user dir with a set of default resources. I don't understand why we have to solve this in a complex way. Go and read the archives then. One reason is that we would also have to add a way to get the deleted system resource back. So we can as well use the tags system that was added for exactly this purpose and mark the system resource as hidden. Another reason is that it is not reasonable to duplicate the system resources in the folders of all users. Another reason is that it becomes a nightmare when the user updates to the next GIMP version which may ship with a different set of resource files. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
Hi, On Thu, 2009-07-23 at 00:48 +0200, GSR - FR wrote: The points are the separate GUI, the mental maths required or the try and error workflow until you find the right size for brush changes, which are the issues the user has to cope with; versus a(n unified) pixel size control (currently non unified as it only works for vector ones, leaving pixmaps in the tiresome usage mode). Well, you completely failed to explain this in your post. So the issue with the scaling from the tool-options is pixel size control? Wouldn't it be much better if we improved this then? We could for example show some numbers on the brush outline while the user adjusts the brush size. The brush editor is such an awkward thing taking up much needed screen estate. It should be our goal to get rid of it. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On 07/23/2009 12:56 AM, Sven Neumann wrote: Hi, On Thu, 2009-07-23 at 00:51 +0200, Martin Nordholts wrote: We could either introduce a complex system to allow the user to delete system resources, or we could make it simple for ourselves and the user and just initialize the user dir with a set of default resources. I don't understand why we have to solve this in a complex way. Go and read the archives then. I'd rather discuss this again instead. If you have a particular mail or thread in mind, please link to it and I'll read it. One reason is that we would also have to add a way to get the deleted system resource back. We don't provide that for the user-brushes, why would we have to do it for the system ones? The user would simply have to copy the system brushes back into his dir, just as he would have to copy his own deleted brushes back in the user dir. Another reason is that it is not reasonable to duplicate the system resources in the folders of all users. How exactly is this unreasonable in 2009? Compared to the amount of images we can expect a user to have based on our product vision, copies of default resources is negligible. Another reason is that it becomes a nightmare when the user updates to the next GIMP version which may ship with a different set of resource files. It's not trivial to deal with this, but it's not exactly hard either, whatever heuristics we come up with. Special casing treatment of so called system resources all over the place is a much bigger nightmare that dealing with a one-time migration. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On Wed, Jul 22, 2009 at 10:47 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: 2009/7/22 David Gowers wrote: tools. When I think about it, I wonder whether such users ever get to using GIMP with any level of frequency or intensity, as IMO with the global-brush option off Don't wonder -- they do. And I do too :) (Speaking of which, the fact that tools presets don't save/restore scale value isn't helpful either.) AFAICS that isn't a generally true fact. Works for me -- I just checked by choosing 1.06, saving that as a preset, setting it to 0.01 and loading the preset (which correctly reset scale to 1.0). What version are you using (I'm using a recent git version, I'd guess that if there was a bug, any 2.7 version would have it fixed.) I guess also it is possible that one of your preset files is corrupt and causing problems. Clear separation of default settings for different tools is such an obvious thing... I agree with that. Unfortunately, having sensible, different defaults for different tools is in direct conflict with having an efficient, un-surprising workflow Contrary to that I would yell every time I switched from Paintbrush to Eraser if I didn't have global brush disabled. It's way too convenient to use e.g. smaller eraser *automatically* Hmm, I tend to forget that there are people who use mice for general GIMP work. I can see how this could actually save time then, if you only ever use Eraser with one or two different fixed brushes instead of switching a lot. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How far away from watching other colorspaces in real time?
Martin Nordholts wrote on Thu, Jul 23, 2009 at 12:40:06AM +0200: On 07/23/2009 12:27 AM, Martin Cracauer wrote: Do I understand that correctly that you will move to single-floats/color? [...] If you in the yet not officially released GIMP 2.7 do View - Use GEGL, then the layers will be composited using GEGL. In other words, we have the layers etc ported to a GEGL graph. It is worth mentioning that it is technically trivial to insert non-destructive nodes in the graph, but our focus now is getting GIMP 2.8 out. I use the git version of last week. Lost my tablet (probably due to some dbus API issue) but works otherwise. Let me just poke some more. And does all this survive layer copying and other changes? Let's use an example: I like to use the levels tools with a non-destructive adjustment first and although 2.6/2.7 allow me to take the levels I found right to curves I usually don't do this. I prefer to commit the level change, then duplicate the layer and mess with the curves in the new layer. This, of course, causes me losses from interpolation with the 8-bit channels, where it would not if I would edit levels and curves in the same moment without committing levels first and start over with curves. Does current 2.7 carry floating point layers through all of this? I just tried this and I get the same teeth in the histogram in 2.7 no matter whether I asked it to use GEGL or not, but I'm not sure I activate it the right way. This was just on a layer originating from a JPEG. Does 2.7 as is support storing and reloading the floating point format in *.xcf files? Martin -- %%% Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] What would be a better set of default resource ?
1) i agree with Alexia , get rid of all duplicates as the circle soft and circle hard brush. If may be scaled only 1 is needed 2) most flexible brushes are that created with the brush editor that can be not only resized but tilted, rotated,made harder or softer on the fly, even with keystrokes But shapes are so limited : will be no possible add some simple shapes as spiral and ring ? to clarify ring: as circle or square or polygonal BUT only the contour is stamped, and the thickness of the contour may be modified .(..with maximum thickness a square ring brush is identical to a classic square brush ,with minimum is 1px outline of the contour) 3 about animated brush, stars, grass,stones and dirty brushes may be a good example, their possible use should be intuitive 4 brush tools would need better preset i make a example with the clone tool As default for clone tool i see a HARD circle brush at 100% opacity, but the clone tool seldom works well used at full opacity with hard brushes... something as a SOFT round brush with a bit less opacity would be abetter default : better in most case and, even more relevant, for the first contact with the tool. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How far away from watching other colorspaces in real time?
On 07/23/2009 04:11 AM, Martin Cracauer wrote: I use the git version of last week. Lost my tablet (probably due to some dbus API issue) but works otherwise. Let me just poke some more. And does all this survive layer copying and other changes? Does current 2.7 carry floating point layers through all of this? Does 2.7 as is support storing and reloading the floating point format in *.xcf files? No, in git master, everything feeded to a GEGL graph is RGBA u8, and everything returned is RGBA u8, it is just the intermediate processing that is done in RGBA float. Part of the remedy for this is replacing GIMP's TileManager with GEGL's GeglBuffer, which can store image data in any format supported by babl. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How far away from watching other colorspaces in real time?
On Thu, Jul 23, 2009 at 11:41 AM, Martin Cracauer craca...@cons.org wrote: Martin Nordholts wrote on Thu, Jul 23, 2009 at 12:40:06AM +0200: On 07/23/2009 12:27 AM, Martin Cracauer wrote: Do I understand that correctly that you will move to single-floats/color? [...] If you in the yet not officially released GIMP 2.7 do View - Use GEGL, then the layers will be composited using GEGL. In other words, we have the layers etc ported to a GEGL graph. It is worth mentioning that it is technically trivial to insert non-destructive nodes in the graph, but our focus now is getting GIMP 2.8 out. I use the git version of last week. Lost my tablet (probably due to some dbus API issue) but works otherwise. Let me just poke some more. And does all this survive layer copying and other changes? GEGL graphs are completely non-destructive (of course, you can flatten part or all of a graph to destroy information at any time.) The plan for GIMP here is that it will only modify the graph in the course of usual operations, which will enable the option of fully non-destructive workflow. In this system, we simply have to decide the way to present this ability to insert arbitrary nodes at arbitrary positions to the user. The idea I regard as most sensible here is simply treating nodes like a container -- that is, the input being made up of 1 or more node outputs composited together. With this idea, you would be attaching an effect to a group of layers (and effects There are issues with the above (primarily, I oversimplified -- we need to deal with nodes that simply produce, like eg. checkerboard, constant color, as well as filtering nodes), but that's a reasonable overall way to think about it for now. IMO GIMP is heading towards providing a fairly thin abstraction layer over the abilities of GEGL graphs, which in general is good news for anyone concerned about possible leaky abstraction (does all this survive layer copying and other changes) -- thick abstraction layers tend to be much leakier (for example, Photoshop's Adjustment Layers idea -- they are only layers in an absurdly broad sense (so broad as to be nearly meaningless), so they tend to disobey common-sense rules followed by other types of layer.) In short: the capacity for inserting arbitrary nodes is available in GEGL, but GIMP does not currently adulterate the constructed layer graph in any way; When some ability to control the graph in a finer way (like I described) is implemented, we ought to have moved on to the next-generation file format, which should support it in a straightforward way Even shorter: A completely theoretical yes, since such functionality is currently available in GEGL, not leveraged by GIMP or presented to the user yet. Let's use an example: I like to use the levels tools with a non-destructive adjustment first and although 2.6/2.7 allow me to take the levels I found right to curves I usually don't do this. I prefer to commit the level change, then duplicate the layer and mess with the curves in the new layer. This, of course, causes me losses from interpolation with the 8-bit channels, where it would not if I would edit levels and curves in the same moment without committing levels first and start over with curves. Does current 2.7 carry floating point layers through all of this? There are no floating point layers yet. During the composition, the layer pixels are automatically converted to floating point, and converted back after composition. to display the finished projection. Thus, the difference in the resulting image is minimal. During the application of a color tool, a similar thing happens: pixels are converted to float, the change is applied, and pixels are converted back. Eventually, using a color tool will just modify the image graph rather than directly writing pixels; at this time, floating point values will be preserved through that operation (and presumably most subsequently operations -- obviously if there is an explicit 'convert to 8bit' operation in use, floating point values are not going to last beyond that. I just tried this and I get the same teeth in the histogram in 2.7 no matter whether I asked it to use GEGL or not, but I'm not sure I activate it the right way. This was just on a layer originating from a JPEG. Does 2.7 as is support storing and reloading the floating point format in *.xcf files? Again, floating point currently has nothing to do with the normal representation of image in the GIMP, yet. This should answer your question. I believe we are planning to move to a new native image format for 3.0, which will address such problems as: metadata support being bolted on rather than a standard part of the file format, more sophisticated ICC support, support of higher bitdepths, support of different color models (LAB, YCbCr etc)... David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU
