Re: [Gimp-developer] Feature Request: Layers from Image ( Linked Layers )
OK- Here is a file containing three scripts that all end up under the Layer menus. Load a new File Linked Layer (loads up an image as a layer and sets the layer name to @FL@full file path.) Reload All File Linked Layers (looks though all the layers for ones where the name starts with the @FL@ flag and reloads them.) Reload File Linked Layer (reloads the active layer if it has the @FL@ flag.) http://ffaat.pointclark.net/incoming/scripts/file_linked_layers.scm Right now it doesn't transfer layer masks, blend modes, or opacity to the newly loaded layers, but that could be added if necessary. Hope that does what you want! -Rob A ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature Request: Layers from Image ( Linked Layers )
On Sun, Jun 14, 2009 at 5:32 AM, kevin wrote: The idea is that you no longer have to Load image as layer every time you change an image because the layer would be the image and would update itself. Sounds like request for XCFv2/OpenRaste/whatever :) Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature Request: Layers from Image ( Linked Layers )
On Sat, Jun 13, 2009 at 9:32 PM, kevinfmw...@gmail.com wrote: The feature is mainly for the possibility of having templates. The idea is that you can place a layer that is a link to a certain image, so you can have 9 layers on top of each other and each one being an image. The idea is that you no longer have to Load image as layer every time you change an image because the layer would be the image and would update itself. My current workflow for this functionality is to edit my images in GIMP and maintain the Template in Inkscape. That sort of thing belongs in a vector editor anyway, imho, and it already does the link to image file thing that you are describing. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature Request: Layers from Image ( Linked Layers )
kevin wrote: I have been using GIMP for a few months now and there is a feature that I have wanted to have and think about every time I open up GIMP. The feature is mainly for the possibility of having templates. The idea is that you can place a layer that is a link to a certain image, so you can have 9 layers on top of each other and each one being an image. The idea is that you no longer have to Load image as layer every time you change an image because the layer would be the image and would update itself. To give an example, let's say you have a template with different images being buttons, menus and background/foreground. You have a window open with all the different linked layers positioned to be how you want it on your site or final look. Now, when you change one of the images, you can see what the result will look like from looking at the window with the template. Benefit being speed ( you don't have to look for the file or any of the tedious crap ) and ease which are two things I like to think GIMP excels over all competitors with. TBH, this sounds more like a vector editing feature than a raster editing feature. Have you tried inkscape? --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature Request: Layers from Image ( Linked Layers )
Not sure I understand your desired workflow. You say when you change an image the layer updates. How do you change an image? Outside gimp? It would be very possible to script some of this... For example, if the layer name were the full path to an image, a script command to reload the layer would be fairly trivial. Possibly modifying the load image as layers to store the full path as a layer parasite so a reload image layers command could be implemented easily. -Rob A On 6/13/09, kevin fmw...@gmail.com wrote: I have been using GIMP for a few months now and there is a feature that I have wanted to have and think about every time I open up GIMP. The feature is mainly for the possibility of having templates. The idea is that you can place a layer that is a link to a certain image, so you can have 9 layers on top of each other and each one being an image. The idea is that you no longer have to Load image as layer every time you change an image because the layer would be the image and would update itself. To give an example, let's say you have a template with different images being buttons, menus and background/foreground. You have a window open with all the different linked layers positioned to be how you want it on your site or final look. Now, when you change one of the images, you can see what the result will look like from looking at the window with the template. Benefit being speed ( you don't have to look for the file or any of the tedious crap ) and ease which are two things I like to think GIMP excels over all competitors with. As far as the linked layer updating itself, that could be either automatic when file changes or you could have a button that auto-updates all layers. GIMP is pretty well written and fast, so I think it being automatic would be fast enough... -- I am new to mailing lists and I am not sure which mailing list I should send a feature request to but this one said to talk about the source code so I decided this one!! ( Hopefully I did everything right? , -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Sent from my mobile device ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature Request: Layers from Image ( Linked Layers )
Well I am glad to hear that it is relatively easy but unfortunately I haven't gotten into scripting with gimp at all... Although, this is definitely going to push me to learn it so I can get this feature ( and various other reasons ). But, as a feature, I still think it would be a helpful add especially for web developers to have a button that just creates a linked layer for them quickly and easily. Thanks for your response and I am already looking at sites w/ tutorials and reading up on this... I know several programming languages, so I am hoping that will help me out while learning this scripting language ,. On 6/13/09, Rob Antonishen rob.antonis...@gmail.com wrote: Not sure I understand your desired workflow. You say when you change an image the layer updates. How do you change an image? Outside gimp? It would be very possible to script some of this... For example, if the layer name were the full path to an image, a script command to reload the layer would be fairly trivial. Possibly modifying the load image as layers to store the full path as a layer parasite so a reload image layers command could be implemented easily. -Rob A On 6/13/09, kevin fmw...@gmail.com wrote: I have been using GIMP for a few months now and there is a feature that I have wanted to have and think about every time I open up GIMP. The feature is mainly for the possibility of having templates. The idea is that you can place a layer that is a link to a certain image, so you can have 9 layers on top of each other and each one being an image. The idea is that you no longer have to Load image as layer every time you change an image because the layer would be the image and would update itself. To give an example, let's say you have a template with different images being buttons, menus and background/foreground. You have a window open with all the different linked layers positioned to be how you want it on your site or final look. Now, when you change one of the images, you can see what the result will look like from looking at the window with the template. Benefit being speed ( you don't have to look for the file or any of the tedious crap ) and ease which are two things I like to think GIMP excels over all competitors with. As far as the linked layer updating itself, that could be either automatic when file changes or you could have a button that auto-updates all layers. GIMP is pretty well written and fast, so I think it being automatic would be fast enough... -- I am new to mailing lists and I am not sure which mailing list I should send a feature request to but this one said to talk about the source code so I decided this one!! ( Hopefully I did everything right? , -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Feature Request: Layers from Image ( Linked Layers )
I have been using GIMP for a few months now and there is a feature that I have wanted to have and think about every time I open up GIMP. The feature is mainly for the possibility of having templates. The idea is that you can place a layer that is a link to a certain image, so you can have 9 layers on top of each other and each one being an image. The idea is that you no longer have to Load image as layer every time you change an image because the layer would be the image and would update itself. To give an example, let's say you have a template with different images being buttons, menus and background/foreground. You have a window open with all the different linked layers positioned to be how you want it on your site or final look. Now, when you change one of the images, you can see what the result will look like from looking at the window with the template. Benefit being speed ( you don't have to look for the file or any of the tedious crap ) and ease which are two things I like to think GIMP excels over all competitors with. As far as the linked layer updating itself, that could be either automatic when file changes or you could have a button that auto-updates all layers. GIMP is pretty well written and fast, so I think it being automatic would be fast enough... -- I am new to mailing lists and I am not sure which mailing list I should send a feature request to but this one said to talk about the source code so I decided this one!! ( Hopefully I did everything right? , -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] feature request: clipping mask layer
On Wed, May 20, 2009 at 9:07 PM, Daniel Johannsen d...@danieljohannsen.de wrote: Hi, yes, your assumption is right. I start the painting process with layers only for shapes and silhouettes. Then i add a layer group with the mask property (or in photoshop-terms a group of clipping mask-layers) to each of the shape-layers. The layers inside the layer group mask define volume, texture, athmospheric perspective, etc. of the shape they are connected to. So to say, the layer group mask has the property of a transparency value. This value is defined by the alpha-value of the layer the group is assigned to. Here is a link that shows the photoshop approach quite well: http://photoshopcontest.com/tutorials/23/clipping-mask-101.html You are absolutely right, every layer in the layer group should maintain their independent transparency, but in addition inherit the transparency of their layer group mask. GEGLs XML format implements such per composition subtree masks. It even allows building these masks using other filters, allowing for instance to create a mask for a layer group using a blurred text layer. I've found the underlying technical approach used to represent the GEGL compositing graph as a tree in those systems to provide all the power that should be needed. Finding sufficiently rich mappings to a user interface most probably using some higher level abstract compositing operations remains a challenge for GIMP in exposing such functionality. An example composition following the underlying model of OpenRaster using low-level operations: crop over translate apply_opacity gaussian blur render text hue-saturation subtract some more noise multiply some more noise some noise pattern checkerboard Some of the low-level ops like the combination of translation and a compositing operation like over (and perhaps even the application of opacity) can be folded into a single UI level concept to avoid having too many individual items in the compositing tree. What the aboive example renders is three noise layers that are combined with different layer modes, a blurred piece of text is used as the overall group opacity for the noise and the noise itself is composited over a checkerboard background. Finally the whole image is cropped (this crop op would probably in fact be the canvas dimensions). See http://create.freedesktop.org/wiki/OpenRaster , http://pippin.gimp.org/oxide/ and http://gegl.org/ for more information. -- «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] feature request: clipping mask layer
Hi, Daniel Johannsen schrieb: I only like to add, that in the layer group it is the alpha value of the lowest layer in the group which provides the masking effect for the grouped layers above. (And not a layer in the middle or on top of the group.) hmm, special-casing the bottom layer seems a bit odd to me. I'd expect the layer group mask to be a property of the layer group and that all layers within that group have independent transparency of their own. Looking at your examples, i assume the photoshop behaviour is convenient because you usually start with a layer and subsequently turn that into a layer group. Assuming correctly? greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] feature request: clipping mask layer
yahvuu schrieb: Hi, Daniel Johannsen schrieb: I only like to add, that in the layer group it is the alpha value of the lowest layer in the group which provides the masking effect for the grouped layers above. (And not a layer in the middle or on top of the group.) hmm, special-casing the bottom layer seems a bit odd to me. I'd expect the layer group mask to be a property of the layer group and that all layers within that group have independent transparency of their own. Looking at your examples, i assume the photoshop behaviour is convenient because you usually start with a layer and subsequently turn that into a layer group. Assuming correctly? greetings, peter Hi, yes, your assumption is right. I start the painting process with layers only for shapes and silhouettes. Then i add a layer group with the mask property (or in photoshop-terms a group of clipping mask-layers) to each of the shape-layers. The layers inside the layer group mask define volume, texture, athmospheric perspective, etc. of the shape they are connected to. So to say, the layer group mask has the property of a transparency value. This value is defined by the alpha-value of the layer the group is assigned to. Here is a link that shows the photoshop approach quite well: http://photoshopcontest.com/tutorials/23/clipping-mask-101.html You are absolutely right, every layer in the layer group should maintain their independent transparency, but in addition inherit the transparency of their layer group mask. greetings, daniel ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] feature request: clipping mask layer
Hi all, On Sun, May 17, 2009 at 10:39 PM, Daniel Johannsen d...@danieljohannsen.de wrote: Solution suggestion: A parent base layer determines alpha values for a dependent stack of child layers above the base layer. Then the last layer on top of the child stack e.g. could be the athmosphere color for the silhouette of the base layer. i wonder, is what you're proposing the same as the 'group layers masks' described in https://lists.xcf.berkeley.edu/lists/gimp-developer/2009-April/022118.html ? Is this already covered by http://bugzilla.gnome.org/show_bug.cgi?id=51112 ? Do you envision a user interface for this? The UI Brainstorm always welcomes cool mock-ups: http://gimp-brainstorm.blogspot.com/ greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] feature request: clipping mask layer
yahvuu wrote: i wonder, is what you're proposing the same as the 'group layers masks' described in https://lists.xcf.berkeley.edu/lists/gimp-developer/2009-April/022118.html ? Is this already covered by http://bugzilla.gnome.org/show_bug.cgi?id=51112 ? In photoshop it is a single layer that docks to the layer (or multiple layers) beneath it, acting as a mask. In PS it is activated by Ctrl+LMB (from memory) on the edge between two layers. Layer group masks would achieve the same thing, and sounds easier to understand/ use. regards, Stephen. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] feature request: clipping mask layer
yahvuu schrieb: Hi all, On Sun, May 17, 2009 at 10:39 PM, Daniel Johannsen d...@danieljohannsen.de wrote: Solution suggestion: A parent base layer determines alpha values for a dependent stack of child layers above the base layer. Then the last layer on top of the child stack e.g. could be the "athmosphere color" for the silhouette of the base layer. i wonder, is what you're proposing the same as the 'group layers masks' described in https://lists.xcf.berkeley.edu/lists/gimp-developer/2009-April/022118.html ? Is this already covered by http://bugzilla.gnome.org/show_bug.cgi?id=51112 ? Do you envision a user interface for this? The UI Brainstorm always welcomes cool mock-ups: http://gimp-brainstorm.blogspot.com/ greetings, peter Hi to all, yes your links point in the right direction. I agree, the term "layer group mask" hits the mark. I only like to add, that in the layer group it is the alpha value of the lowest layer in the group which provides the masking effect for the grouped layers above. (And not a layer in the middle or on top of the group.) I am not surprised, that this feature is used a lot in photoshop (here it is called "clipping mask"). Some examples in order to stress how important this is for the painting process: 1)One can start with searching for a good composition by defining only silhouettes. Then, in dependency of the silhouette, you can add volume and texture layers above the silhouette. 2)Often the shapes are not known in advance. Then they are dependend of normally subsequent painting steps like adding volume and texture layers. With layer group masks one can quickly correct all the layers of the object only by manipulating the base shape layer. 3)Painting objects made of transparent materials like colored glass. The layer group mask feature would look like the following: * top layer: highlights (dependent) * middle layer: glass texture (dependent) * underlying layer: glass shape in the color of the glass with 50% opacity (defines the transparency for the dependent layers) regards, Daniel. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] feature request: clipping mask layer
yahvuu schrieb: Hi all, On Sun, May 17, 2009 at 10:39 PM, Daniel Johannsen d...@danieljohannsen.de wrote: Solution suggestion: A parent base layer determines alpha values for a dependent stack of child layers above the base layer. Then the last layer on top of the child stack e.g. could be the athmosphere color for the silhouette of the base layer. i wonder, is what you're proposing the same as the 'group layers masks' described in https://lists.xcf.berkeley.edu/lists/gimp-developer/2009-April/022118.html ? Is this already covered by http://bugzilla.gnome.org/show_bug.cgi?id=51112 ? Do you envision a user interface for this? The UI Brainstorm always welcomes cool mock-ups: http://gimp-brainstorm.blogspot.com/ greetings, peter Hi to all, yes your links point in the right direction. I agree, the term layer group mask hits the mark. I only like to add, that in the layer group it is the alpha value of the lowest layer in the group which provides the masking effect for the grouped layers above. (And not a layer in the middle or on top of the group.) I am not surprised, that this feature is used a lot in photoshop (here it is called clipping mask). Some examples in order to stress how important this is for the painting process: 1)One can start with searching for a good composition by defining only silhouettes. Then, in dependency of the silhouette, you can add volume and texture layers above the silhouette. 2)Often the shapes are not known in advance. Then they are dependend of normally subsequent painting steps like adding volume and texture layers. With layer group masks one can quickly correct all the layers of the object only by manipulating the base shape layer. 3)Painting objects made of transparent materials like colored glass. The layer group mask feature would look like the following: * top layer: highlights (dependent) * middle layer: glass texture (dependent) * underlying layer: glass shape in the color of the glass with 50% opacity (defines the transparency for the dependent layers) regards, Daniel. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] feature request: clipping mask layer
Problem: Painting (e.g. with wacom-board) complex athmospheric perspective with overlapping objects. Solution suggestion: A parent base layer determines alpha values for a dependent stack of child layers above the base layer. Then the last layer on top of the child stack e.g. could be the athmosphere color for the silhouette of the base layer. People suggest as workaround the alpha to selection feature. But if the silhouette of the base layer has transparency gradients, e.g. when painting clouds, every addition of color to child layers will nevertheless end up opaque in the child layer. Especially when painting on alpha masks of the child layers to evolve the forms gradually a clipping mask layer is in fact the only possibilty of producing complex scenes with athmospheric depth. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request, include filename with curves autosave
On Thu, Oct 9, 2008 at 5:47 PM, David Gowers [EMAIL PROTECTED] wrote: Hi, On Fri, Oct 10, 2008 at 5:17 AM, Kent Tenney [EMAIL PROTECTED] wrote: Howdy, I wish the gimp-curves-tool.settings file, which contains sections starting with: (GimpCurvesConfig 2008-10-03 14:34:26 (time 1223062466) (channel value) (curve ... also listed the name of the file (or 'unnamed') This is the name of the file: '' I guess I'm unclear, an example; I open a photo file in gimp DSCN001.jpg I adjust curves on that file. The description of the adjustment is written to gimp-curves-settings. I would like to see the following in gimp-curves-settings (GimpCurvesConfig 2008-10-03 14:34:26 (time 1223062466) (file DSCN001.jpg) (channel value) (curve ... If this is possible, it would allow me to match the required adjustment with the image file. I could then write scripts which applied this correction. Does that make sense? Thanks, Kent ie. no file (the only completely-accurate preservation of the curve is in the gimp-curves-tool.settings file, and unless you've explicitly exported it, no other file will contain data on that curve.) Or were you asking for a list of filenames that this curve has been exported as? fully qualified would be great, bare would be fine. Thanks, Kent HTH, David -- Everything has reasons. Nothing has justification. Ĉio havas kialojn; Neniaĵo havas pravigeron. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Feature request, include filename with curves autosave
Howdy, I wish the gimp-curves-tool.settings file, which contains sections starting with: (GimpCurvesConfig 2008-10-03 14:34:26 (time 1223062466) (channel value) (curve ... also listed the name of the file (or 'unnamed') fully qualified would be great, bare would be fine. Thanks, Kent ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request, include filename with curves autosave
Hi, On Fri, Oct 10, 2008 at 5:17 AM, Kent Tenney [EMAIL PROTECTED] wrote: Howdy, I wish the gimp-curves-tool.settings file, which contains sections starting with: (GimpCurvesConfig 2008-10-03 14:34:26 (time 1223062466) (channel value) (curve ... also listed the name of the file (or 'unnamed') This is the name of the file: '' ie. no file (the only completely-accurate preservation of the curve is in the gimp-curves-tool.settings file, and unless you've explicitly exported it, no other file will contain data on that curve.) Or were you asking for a list of filenames that this curve has been exported as? fully qualified would be great, bare would be fine. Thanks, Kent HTH, David -- Everything has reasons. Nothing has justification. Ĉio havas kialojn; Neniaĵo havas pravigeron. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Feature request: no-image-open window remembers position as well as size
Hi, I've just been playing a bit with 2.6, and have a request. When the last image is closed, the no-image-open window snaps back to whatever size it was before the first image was opened - which is great. Could we take that further and make it snap back to its previous position, as well as size? I like to have GIMP open in between editing, with the toolbox and dock full of dialogs on the right-hand-side of the screen in a neat column - this leaves plenty of screen usable for browsing images, and leaves GIMP accessible for dragging-and-dropping images. As it stands, with 2.6 I either have to have the no-image-open window cluttering the main part of the screen, or I can tuck it neatly out of the way with the toolboxes - but if I do that, I have to drag it manually back into the main part of the screen when I open an image, and put it away again afterwards. Assuming it's not possible to turn this no-image-open window off altogether (it's not, right?) I'd like the window to be able to switch between those two positions automatically as the first image is opened and the last image is closed. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request for a spot healing brush
Hi, On Sun, 2007-11-11 at 01:41 -0700, Joe Eagar wrote: Though I suppose suggesting it on IRC might be more appropriate then on the list. Is that what you meant? No, I only meant that filing enhancement requests for this is a waste of time unless more information can be provided. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request for a spot healing brush
Sven Neumann wrote: Hi, On Sun, 2007-11-04 at 20:37 -0500, Daniel Falk wrote: Photoshop has a tool that works like the healing brush except that it doesn't require a source region to be specified before using the tool. When there are a lot of quick touch-ups to do, this is very convenient. Photoshop somehow guesses what it should use as source material and is often accurate. When it's not accurate, users can undo it, and then fall back on the healing brush and manually specify that information. Since we don't know how this works in detail, there is not much point in suggesting that we add such a feature. Could you explain the reasoning behind this? Such feature requests are always a good thing, and listening to them is a sign of a user-centric development team. By listening to them I don't mean *implementing* them, but a steady stream of such ideas can be beneficial. Though I suppose suggesting it on IRC might be more appropriate then on the list. Is that what you meant? Joe ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request for a spot healing brush
Joe Eagar wrote: Sven Neumann wrote: Hi, On Sun, 2007-11-04 at 20:37 -0500, Daniel Falk wrote: Photoshop has a tool that works like the healing brush except that it doesn't require a source region to be specified before using the tool. When there are a lot of quick touch-ups to do, this is very convenient. Photoshop somehow guesses what it should use as source material and is often accurate. When it's not accurate, users can undo it, and then fall back on the healing brush and manually specify that information. Since we don't know how this works in detail, there is not much point in suggesting that we add such a feature. Could you explain the reasoning behind this? Such feature requests are always a good thing, and listening to them is a sign of a user-centric development team. By listening to them I don't mean *implementing* them, but a steady stream of such ideas can be beneficial. Hi Joe Suggesting a new feature without specifying how the algorithm behind it work is pointless because how could the feature then be implemented? There are way too many other things to use the sparse GIMP developer resources for than to research details of other peoples feature requests. Note the difference between not listening to users and rejecting incomplete feature requests. We appreciate that you think GIMP is worth spending some on to help improving, but please don't take it personal if some of your suggestions are considered incomplete. It would be very appreciated if you took the time to research exactly how this algorithm is supposed to work. Regards, Martin Nordholts ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request for a spot healing brush
Martin Nordholts wrote: Hi Joe Suggesting a new feature without specifying how the algorithm behind it work is pointless because how could the feature then be implemented? There are way too many other things to use the sparse GIMP developer resources for than to research details of other peoples feature requests. Well people do it to me all the time with blender. . .I sometimes figure it out, and if I don't have time to develop it myself I'll try and tell some other dev how it works. And he also offered to show a video about it. Feature videos are really useful for reverse engineering; I don't understand why Sven said otherwise. You can tell a lot sometimes. Also it's not as if anyone *has* to devote time to figuring it out. Users will make many, many more requests then there will ever be time to code, much less research. Simply listening to the more popular or useful sounding ones will give devs an impression of what users really want, and even what they *need*. This can help formulate long-term plans, both for the project but also for individual devs who think that way. Such requests might not always be appropriate for a feature tracker, or even a mailing list (I think IRC is a good place to put forth these ideas). But they shouldn't be rejected out of hand, either. I'm not totally sure the best way to handle this; Blender has a functionality mailing list that kindof serves the purpose of random feature requests, but it doesn't work very well. Like I said, for unlikely or somewhat obscure features it seems to be best if users discuss them on IRC, then if a dev gets interested he can, oh I don't know add it to the feature tracker or something like that. Or if he's like me, he may think about these sorts of a features every once in a while, and in a year or two even implement a few of them. Note the difference between not listening to users and rejecting incomplete feature requests. We appreciate that you think GIMP is worth spending some on to help improving, but please don't take it personal if some of your suggestions are considered incomplete. Imho, an incomplete feature request is something like I want a tool to make healing brush better or something weird like that. I want a tool that automatically selects a source region for healing brush imho gives plenty of information, and if passed along to someone who knows the math behind it might even make sense to them. No one is obligated to research this, or even pay attention to it. All that matters is it sounds like a useful idea proposed by a user. And feature videos can help; I myself pieced 3d ray baking together from watching one modo video. It would be very appreciated if you took the time to research exactly how this algorithm is supposed to work. Regards, Martin Nordholts Well I don't have the time for that. :) Joe ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request for a spot healing brush
On Mon, 2007-11-05 at 09:30 +0100, Sven Neumann wrote: Hi, On Sun, 2007-11-04 at 20:37 -0500, Daniel Falk wrote: Photoshop has a tool that works like the healing brush except that it doesn't require a source region to be specified before using the tool. When there are a lot of quick touch-ups to do, this is very convenient. Photoshop somehow guesses what it should use as source material and is often accurate. When it's not accurate, users can undo it, and then fall back on the healing brush and manually specify that information. Since we don't know how this works in detail, there is not much point in suggesting that we add such a feature. I could find a video for anyone interested, but that really wasn't my point. I suggested the feature not simply to ask for someone to copy photoshop in detail, but to solve the same problem that photoshop has managed to solve. Namely, figuring out an effective, efficient, and time-saving way of cleaning up a photo with a lot of marks or a dusty scan. In general I would like to point out that it is unlikely that any of the active core developers will pick up your feature requests. If you can find a developer who is interested in the algorithms and willing to work on this stuff, then we are very willing to give him/her a hand and guide him/her through the GIMP code and to review patches. But without a volunteer, this is likely to be just another feature requests. We already have several hundreds of them. Sven That's a shame, but I do understand there is a lot of work to be done on the gimp and only so much expertise to go around. Still, can it be logged as a valid feature request somewhere in the event that someone with the interest in improving the gimp might choose to implement this request? After all, I didn't just request it to scratch my own itch. I wanted to add my input into how the GIMP could improve. I wouldn't really know how to find a developer to work on this stuff. I would assume it's more likely that developers would come to you as core developers of the GIMP than to me after all. Thanks for your attention and all the hard work you guys do on the GIMP. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request for a spot healing brush
Hi, On Mon, 2007-11-05 at 19:29 -0500, Daniel Falk wrote: Since we don't know how this works in detail, there is not much point in suggesting that we add such a feature. I could find a video for anyone interested, but that really wasn't my point. I suggested the feature not simply to ask for someone to copy photoshop in detail, but to solve the same problem that photoshop has managed to solve. Namely, figuring out an effective, efficient, and time-saving way of cleaning up a photo with a lot of marks or a dusty scan. A video wouldn't help. In order to implement this, one would have to know exactly how Photoshop somehow guesses what it should use as source material. Of course if someone has solved the problem you outlined above, then we would be happy to help him/her to implement it as a GIMP tool. That's a shame, but I do understand there is a lot of work to be done on the gimp and only so much expertise to go around. Still, can it be logged as a valid feature request somewhere in the event that someone with the interest in improving the gimp might choose to implement this request? No. It is pointless to keep an enhancement request for something that doesn't have a known solution. It would even be a waste of developers time since this bug would only make our long list of feature requests even longer. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Feature request for a spot healing brush
Photoshop has a tool that works like the healing brush except that it doesn't require a source region to be specified before using the tool. When there are a lot of quick touch-ups to do, this is very convenient. Photoshop somehow guesses what it should use as source material and is often accurate. When it's not accurate, users can undo it, and then fall back on the healing brush and manually specify that information. It might be a better idea to make this an option to the healing tool rather than creating a separate tool, but the functionality this provides can save a lot of time and mouse strokes. So what do you think? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request, - liquid resize
On 8/22/07, Thomas Lytje [EMAIL PROTECTED] wrote: I am not sure you take feature requests like this, - but try to take a look. It seems quite cool. I don't know enough about image processing (but I am a software engineer) but to me it looks like it wouldn't be to hard to implement. Hopefully there isn't a lot of patens making it impossible Looks like a resizer in which the amount of source pixels per output pixel varies spatially, rather than being roughly constant. It seems to have a few requirements: a) Resizing can only be done on one axis at once b) two scalers would be needed, one iterating over X axis, one over Y. Basically the only change relative to normal accumulators is that the number of pixels resulting in a final pixel would need to be inversely weighted by the significance mask (that is, read more input pixels to produce an output pixel in insignificant areas.) There is also one coefficient involved that would need some experimentation with to get right: the exact ratio of scaling between completely significant pixels and completely insignificant pixels. (I mean, when you shrink that image, the significant features must also shrink somewhat -- at least once they begin to push up against each other.) Anyway, if you give a link to a paper describing the exact workings of the algorithym, then it's much more likely that something will get done in relation to it. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request, - liquid resize
David Gowers ([EMAIL PROTECTED]) wrote: Anyway, if you give a link to a paper describing the exact workings of the algorithym, then it's much more likely that something will get done in relation to it. It seems to be fairly straightforward and the results are beautiful. The related paper is available at http://www.faculty.idc.ac.il/arik/imret.pdf - but since this page is pretty slow try these URLs: http://www.faculty.idc.ac.il.nyud.net/arik/imret.pdf http://www.faculty.idc.ac.il.nyud.net:8080/arik/imret.pdf Would be cool if someone would tackle this. 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
[Gimp-developer] Feature request, - liquid resize
I am not sure you take feature requests like this, - but try to take a look. It seems quite cool. I don't know enough about image processing (but I am a software engineer) but to me it looks like it wouldn't be to hard to implement. Hopefully there isn't a lot of patens making it impossible See: http://www.youtube.com/watch?v=vIFCV2spKtgeurl=http%3A%2F%2Fwww%2Emilkandcookies%2Ecom%2Flink%2F66481%2Fdetail%2F Thanks Thomas Lytje ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] feature request
On Wed, Jul 05, 2006 at 09:33:45PM +0200, Sven Neumann wrote: Hi, On Sun, 2006-07-02 at 10:38 +0200, Marco Ciampa wrote: Why not to bring all the GIMP windows up over all the others windows when I clic on to one of the many GIMP windows? Because it isn't trivial to do that. You can try the transient windows option in the Preferences dialog of a recent 2.3 development release. See http://svenfoo.geekheim.de/index.php/2005-05-12/transient-docks/ for more info. I'm veeery sorry, I've totally missed this! This is exactly what I was asking for (and what some gimp users asked me for gimp). I tested cvs gimp with last kubuntu/debian kde desktop and it rocks! Many thanks! -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] feature request
Hi, On Sun, 2006-07-02 at 10:38 +0200, Marco Ciampa wrote: Why not to bring all the GIMP windows up over all the others windows when I clic on to one of the many GIMP windows? Because it isn't trivial to do that. You can try the transient windows option in the Preferences dialog of a recent 2.3 development release. See http://svenfoo.geekheim.de/index.php/2005-05-12/transient-docks/ for more info. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] feature request
Tim Jedlicka writes: On 7/2/06, Marco Ciampa [EMAIL PROTECTED] wrote: Why not to bring all the GIMP windows up over all the others windows when I clic on to one of the many GIMP windows? While in the image window - try a Shift-Tab (it may just be my window manager (gnome/gdm)), but this works well for me. Doesn't work here in fvwm. It makes the Toolbox and dialogs disappear; then another shift-tab brings them back, on top of other windows. In neither case does it affect the stacking order of any gimp image windows. I wouldn't want to see a click on any window bring all the others forward. That would be really annoying, since there are many reasons for clicking in a window and most of them don't involve any of the other windows that might be open. But I agree it would be quite useful to have some way of bringing all gimp windows to the front, ideally via a menu item (which could then be bound to a keystroke). There are definitely times when I would use and appreciate that. (As a workaround, what I do is tell my windowmanager to move whatever window is hiding gimp down to the bottom of the stack. I'm not sure all windowmanagers offer a way to do that, though.) If this gimp function was implemented, it would have to loop over the image windows and bring each one forward ... in what order? Order by last access time? Does gimp even keep information about the last time at which each currently open image window was accessed? I suppose it isn't that critical as long as the one most recently accessed image window ends up on top along with the Toolbox and dialogs. -- ...Akkana Check out my book, Beginning GIMP: From Novice to Professional. Now shipping! For more information: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] feature request
On 7/2/06, Marco Ciampa [EMAIL PROTECTED] wrote: When I use GIMP, if I temporarly open another program, when I want to returnto GIMP, I have to manually re-clic on to every gimp windows (toolbox,images,layers, etc.) that I covered with the windows of the other program Why not to bring all the GIMP windows up over all the others windows when Iclic on to one of the many GIMP windows?This behaviour could be disabled by default in the preference window ifyou find it too much customized. While in the image window - try a Shift-Tab (it may just be my window manager (gnome/gdm)), but this works well for me.-- Tim Jedlicka, [EMAIL PROTECTED] , http://www.galifree.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] feature request
This is my first post here and I'm a newbie in english language and gimp too so, please do not bite me! :-) I'm writing here because I'm thinking to post a feature request on the gimp bugzilla but I'm not shure. It seems too simple a request so I'm asking myself if there is a really stupid reason for which gimp is behaving in this way... Now the problem. I use GIMP usually with many GIMP panels opened all together. GIMP remembers windows position already and this is a good thing (TM). When I use GIMP, if I temporarly open another program, when I want to return to GIMP, I have to manually re-clic on to every gimp windows (toolbox, images,layers, etc.) that I covered with the windows of the other program Why not to bring all the GIMP windows up over all the others windows when I clic on to one of the many GIMP windows? This behaviour could be disabled by default in the preference window if you find it too much customized. TIA -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature Request for 1.3
[EMAIL PROTECTED] writes: Hello Gimp Devel. First off, I started playing with GIMP 1.3 last night and it is awsome. The 1.4 stable series is going to be amazing. Thanks ;) I wanted to take this oppertunity, early in the devel work on 1.3 to restate an old nagging feature request of mine: The only feature I miss when I use GIMP is that of Photoshop's brush cursors. In Photoshop, when you choose a 12pixel brush, your cursor becomes a 12pixel sphere (or whatever shape of the brush) to illistrate where your paint is going to drop. This is, IMHO, a very very useful image editing tool. I'd requested this type of ability in the 1.1 and 1.2 development stage but was asked to wait for 1.3. I do alot of image cleanup and when editing an image border (say, painting out a background) its really helpful to know exactly which pixels are going to be changed. This has been requested several times, has been an issue on irc and everybody seems to agree that we want this feature. Why don't you go ahead and add it as an enhancment bug to http://bugzilla.gnome.org with 1.4 as target milestone? Just to make sure it won't get lost... ciao, --Mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature Request for 1.3
[EMAIL PROTECTED] (Raphael Quinet) writes: On 08 Jan 2002, Michael Natterer [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: The only feature I miss when I use GIMP is that of Photoshop's brush cursors. In Photoshop, when you choose a 12pixel brush, your cursor becomes a 12pixel sphere (or whatever shape of the brush) to illistrate where your paint is going to drop. This is, IMHO, a very very useful image editing tool. I'd requested this type of ability in the 1.1 and 1.2 development stage but was asked to wait for 1.3. I do alot of image cleanup and when editing an image border (say, painting out a background) its really helpful to know exactly which pixels are going to be changed. This has been requested several times, has been an issue on irc and everybody seems to agree that we want this feature. Why don't you go ahead and add it as an enhancment bug to http://bugzilla.gnome.org with 1.4 as target milestone? Just to make sure it won't get lost... There is already a bug report about this feature, so there is no need to submit a new one: http://bugzilla.gnome.org/show_bug.cgi?id=32498 Its current title is Pointer should reflect toolsize and it already has the target milestone 1.3.x. I am going change the title of this bug report so that it includes at least the word brush (easier to find). Thanks, I searched bugzilla because I was sure it was there but didn't find it ... :) --M ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Feature Request for 1.3
Hello Gimp Devel. First off, I started playing with GIMP 1.3 last night and it is awsome. The 1.4 stable series is going to be amazing. I wanted to take this oppertunity, early in the devel work on 1.3 to restate an old nagging feature request of mine: The only feature I miss when I use GIMP is that of Photoshop's brush cursors. In Photoshop, when you choose a 12pixel brush, your cursor becomes a 12pixel sphere (or whatever shape of the brush) to illistrate where your paint is going to drop. This is, IMHO, a very very useful image editing tool. I'd requested this type of ability in the 1.1 and 1.2 development stage but was asked to wait for 1.3. I do alot of image cleanup and when editing an image border (say, painting out a background) its really helpful to know exactly which pixels are going to be changed. Thanx for any consideration. [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature Request for 1.3
On Mon, 7 Jan 2002 [EMAIL PROTECTED] wrote: The only feature I miss when I use GIMP is that of Photoshop's brush cursors. I'll second that one. It's a pain not knowing where your brush will land - ESPECIALLY because when the image is zoomed in or out, the brush size can be much larger or smaller than you expect. If you say 'gimp *.png' and have a bunch of images - some larger than the screen - some smaller, they can each have a different image resolution - so you tend to pick a brush suitable for a very high res image - then move over to a lower res image and discover that now you are painting with something *much* larger than you expect with very little visual cues as to what's going on. Of course, this isn't necessarily an easy feature to implement. It's not as simple as setting the X cursor to the right thing because when you are zoomed right in and painting with a huge brush, you can end up with a cursor that covers half the screen! What might be interesting would be a 'preview cursor' that shows you what the pixels would look like *if* you clicked the mouse button right then. Thanx for any consideration. Indeed. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature Request for 1.3
Stephen J Baker [EMAIL PROTECTED] wrote: [...] It's not as simple as setting the X cursor to the right thing because when you are zoomed right in and painting with a huge brush, you can end up with a cursor that covers half the screen! For X11, using the ordinary cursor up the maximum size is obvious; whether then to use a masked pixmap or chain of line segments is a matter of benchmarking under different circumstances (remote vs local X server, different server cleverness etc). For instance, a masked pixmap requires little bandwidth once it has been transferred to the server, but might be slow if the server handles sparse masked blits in a bad way. Line segments need more bandwidth per mouse motion but are potentially cheaper to render. Implementing either is not hard, but I (being primarily an Xlib programmer) don't know how if gdk/gtk have the necessary primitives ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature Request for 1.3
On Mon, 7 Jan 2002 11:44:09 -0800 [EMAIL PROTECTED] sent: Hello Gimp Devel. First off, I started playing with GIMP 1.3 last night and it is awsome. The 1.4 stable series is going to be amazing. I wanted to take this oppertunity, early in the devel work on 1.3 to restate an old nagging feature request of mine: The only feature I miss when I use GIMP is that of Photoshop's brush cursors. In Photoshop, when you choose a 12pixel brush, your cursor becomes a 12pixel sphere (or whatever shape of the brush) to illistrate where your paint is going to drop. This is, IMHO, a very very useful image editing tool. I'd requested this type of ability in the 1.1 and 1.2 development stage but was asked to wait for 1.3. I do alot of image cleanup and when editing an image border (say, painting out a background) its really helpful to know exactly which pixels are going to be changed. Thanx for any consideration. [EMAIL PROTECTED] As soon as a I saw benr, I though Brush size request. Seems that you and Tammy both want that feature ;) (tammyspeech.mp3) -- __ UNIX gives you | l i n u x - b a s h - g i m p enough rope to shoot | s y n g i n @ g i m p . o r g yourself in the foot | s y n g i n @ g i m p . n o ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
