[Gimp-developer] make healing brush and clone tool use one source and possibly involve shift modifier
Working with healing brush in 2.3.11 I've found it very useful. But sometimes it is required not only to change the texture, but also to change color of the image part while retouching with clone tool. So I switch between tools with C and H hotkeys. It could be even smoother if these tools use the same source: if a source for healing brush is selected, and user switches to clone tool, the clone tool should already have the same source and be ready to work. And vice versa. Furthermore, as shift modifier is not used (as I can see), it can be used for switching between these tools if one of them is used. -- With respect Alexander Rabtchevich ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] make healing brush and clone tool use one source and possibly involve shift modifier
I'll try to describe my workflow. When I'm retouching (humans skin) there are two types of defects from color point of view: 1. the ones which have rather large smooth area and which color differs from skin color and 2. small ones with the texture other than nearby skin and possibly but not necessary different color. The difference is rather narrow and is based on defect size compared to nearby face features: foldings, lips... I use scalable round brush mostly with 50% opacity which fades to edges. Also 2 modifiers are used: [] for quick and for exact brush resizing. So if a defect has different (reddish) color, it can even have the same texture as the nearby skin. The healing brush doesn't change the color, but it is required here! The clone tool is just in place for this action. So I switch to it with C, select the source again and apply it. Making a conclusion, sometimes it is required to replace the destination color with the source one, not only to flatten or copy the texture of the source. That's why I use the clone tool consequently with the healing brush. Sven Neumann wrote: That said, let's get back to your suggestion. It would help if, instead of proposing a solution, you could outline what exactly you cannot achieve using the Heal tool. There are most probably better ways to solve the problem. Sven -- With respect Alexander Rabtchevich ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] make healing brush and clone tool use one source and possibly involve shift modifier
Hi, On Wed, 2006-09-13 at 10:32 +0300, Alexander Rabtchevich wrote: Making a conclusion, sometimes it is required to replace the destination color with the source one, not only to flatten or copy the texture of the source. That's why I use the clone tool consequently with the healing brush. The heal tool needs to change anyway. The current state where it only works if you click, but not if you paint with it, is not acceptable. So perhaps we can take your points into consideration when changing the tool. Currently the idea is to make the Heal tool work just like the Clone tool and apply the healing magic after released the mouse button. Perhaps there could be a modifier key that suppresses the healing so it would work just like a clone tool. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] soc-2006-healing-brush branch merged and closed
Hi Kevin, a while ago I wrote to the list with the following questions and I don't remember to have gotten answers to them. Will you please consider to answer these questions? On Tue, 2006-09-05 at 07:55 +0200, Sven Neumann wrote: Of course optimizing the Laplacion solver is still desirable. Have you done any profiling on this yet? Is there a way to benchmark it? A regression test would also be nice to have for this purpose. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp python
Hi, the internationalisation of the Gimp Python bindings and plug-ins is still pending: http://bugzilla.gnome.org/show_bug.cgi?id=351287 Does this mean that noone is interested in having the existing Python scripts in GIMP 2.4? It should not be difficult to make the plug-ins use the existing gettext module for Python (http://docs.python.org/lib/module-gettext.html) and that's basically all that needs to be done. Perhaps someone can look over the strings in the meantime and make sure that there are no typos or other errors? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP plug-in disabled.
On 9/13/06, Sven Neumann [EMAIL PROTECTED] wrote: Hi,On Wed, 2006-09-13 at 00:13 +0930, David Gowers wrote: Your plugin needs to take an image as its first input in order to be repeatable.What do you mean when you say repeatable? What you are saying here doesn't make any sense to me.So that it can be rerun.. as in 'Repeat Despeckle', 'Re-show Despeckle' ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
RE: [Gimp-developer] GIMP plug-in disabled.
Thank you very much Simon. That is a very
nice suggestion. If I make the RGB* string ,I
could make the plugin repeatable. Thanks again..
From: Dream Artist
Aspiring [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 12, 2006
9:52 PM
To: David Gowers
Cc:
gimp-developer@lists.xcf.berkeley.edu
Subject: Re: [Gimp-developer] GIMP
plug-in disabled.
Thank you very much. That
worked for me. But, my initial idea for this plugin is that, if I select this
option from menu; it will create a new image and layer and draw a circle on
that layer. Now, it looks like I will have to create an image and just draw a
circle on it. Thanks again for the help..
On 9/12/06, David
Gowers [EMAIL PROTECTED]
wrote:
On 9/13/06, Dream
Artist Aspiring [EMAIL PROTECTED] wrote:
Hi, Thank you very much for the reply. Here is the registration code.
If not in Xtns, where should I put this?
static void
query (void)
{
static GimpParamDef args[] =
{
{
GIMP_PDB_INT32,
run-mode,
Run mode
},
{
GIMP_PDB_INT32,
image,
Input image
},
{
GIMP_PDB_INT32,
drawable,
Input drawable
}
};
gimp_install_procedure (
plug-in-testp,
TestP,
A Test
Plugin,
,
,
2006,
_testp,
RGB*,
GRAY*,
GIMP_PLUGIN,
G_N_ELEMENTS
(args), 0,
args, NULL);
gimp_plugin_menu_register (plug-in-testp,
Toolbox/Xtns/Plugins/Misc);
That all looks OK, except the path. I suggest something like
Image/Test/Testplugin. I think that plugins have to be
registered in the image menus to be repeatable, too.
Certainly the ones of mine that reside in the toolbox are not repeatable.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] RE: help writing plugin
Hi Simon, thanks again for the help. I
will read through these and try to write my plugin
From: Dream Artist
Aspiring [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 12, 2006
8:53 PM
To:
gimp-developer@lists.XCF.Berkeley.EDU
Subject: help writing plugin
Hi all, I am new to gimp and trying to learn plugins. I wanted to start
by drawing a circle. So basically,
for(t=0; t 360; t++)
{
x(t) = cos(t);
y(t) = sin(t);
col(t) = black;
paint col(t) at x(t), y(t) or better; draw a black line from
x(t-1),y(t-1) to x(t),y(t).
}
So, how do I proceed in general. Right now, I created a new image, created a
new layer and added to image, filled the background color. After this I know
how to compute x(t), y(t) and col(t). I dont know how to do the last step:
paint col(t) at x(t), y(t) or better; draw a black line from
x(t-1),y(t-1) to x(t),y(t). Can any one suggest how to do the last step.
Thanks very much in advance
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] soc-2006-healing-brush branch merged and closed
In regard to: Re: [Gimp-developer] soc-2006-healing-brush branch merged and...: Hi Kevin, a while ago I wrote to the list with the following questions and I don't remember to have gotten answers to them. Will you please consider to answer these questions? My guess is that Kevin isn't listening right now, because of the move and internship he mentioned at the bottom of this email: https://lists.xcf.berkeley.edu/lists/gimp-developer/2006-August/016152.html On Tue, 2006-09-05 at 07:55 +0200, Sven Neumann wrote: Of course optimizing the Laplacion solver is still desirable. Have you done any profiling on this yet? Is there a way to benchmark it? A regression test would also be nice to have for this purpose. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Customizing GIMP windows and behavior
From: Des [EMAIL PROTECTED] I am new GIMP. We are looking to extend GIMP to fulfill some functionality required by our users, and one of the them is to be able to open an image in three windows, where one window will be the active image which allows the users to add additional paths, and other objects. Adding anything to this image will also add the paths and objects to the second window. On the second window, if the user add any paths or other objects, it just remains in this window. Hmm. It probably wouldn't be incredibly difficult to modify gimp to allow opening an image with multiple views -- but it would be *very* difficult to make those views share some objects but not others. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Customizing GIMP windows and behavior
The users are mark inclusions that they analyze on a stone. The three views are used as follows: 1 view serves as a working view or scratch pad 1 view serves as a view that will be printed on a report 1 view serves as internal view, i.e. includes additional markups that is not in the report view. Desmond - Original Message From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: gimp-developer@lists.XCF.Berkeley.EDU Sent: Wednesday, September 13, 2006 3:20:56 AM Subject: Gimp-developer Digest, Vol 48, Issue 16 Send Gimp-developer mailing list submissions to gimp-developer@lists.XCF.Berkeley.EDU To subscribe or unsubscribe via the World Wide Web, visit https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of Gimp-developer digest... Today's Topics: 1. Customizing GIMP windows and behavior (Des) 2. Re: GIMP plug-in disabled. (Sven Neumann) 3. Re: Customizing GIMP windows and behavior (Sven Neumann) 4. make healing brush and clone tool use one source and possibly involve shift modifier (Alexander Rabtchevich) 5. Re: make healing brush and clone tool use onesource and possibly involve shift modifier (Sven Neumann) 6. Re: make healing brush and clone tool use onesourceand possibly involve shift modifier (Alexander Rabtchevich) 7. Re: make healing brush and clone tool use onesource and possibly involve shift modifier (Sven Neumann) 8. Re: soc-2006-healing-brush branch merged and closed (Sven Neumann) 9. Re: healing brush hanging X11 (Sven Neumann) Hi, I am new GIMP. We are looking to extend GIMP to fulfill some functionality required by our users, and one of the them is to be able to open an image in three windows, where one window will be the active image which allows the users to add additional paths, and other objects. Adding anything to this image will also add the paths and objects to the second window. On the second window, if the user add any paths or other objects, it just remains in this window. Regards, Desmond __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Hi, On Wed, 2006-09-13 at 00:13 +0930, David Gowers wrote: Your plugin needs to take an image as its first input in order to be repeatable. What do you mean when you say repeatable? What you are saying here doesn't make any sense to me. Sven Hi, On Tue, 2006-09-12 at 22:45 -0700, Des wrote: I am new GIMP. We are looking to extend GIMP to fulfill some functionality required by our users, and one of the them is to be able to open an image in three windows, where one window will be the active image which allows the users to add additional paths, and other objects. Adding anything to this image will also add the paths and objects to the second window. On the second window, if the user add any paths or other objects, it just remains in this window. I don't think such a thing can be implemented without massive changes to the internals. But why would your users want such a behaviour? And what are your users? Sven Working with healing brush in 2.3.11 I've found it very useful. But sometimes it is required not only to change the texture, but also to change color of the image part while retouching with clone tool. So I switch between tools with C and H hotkeys. It could be even smoother if these tools use the same source: if a source for healing brush is selected, and user switches to clone tool, the clone tool should already have the same source and be ready to work. And vice versa. Furthermore, as shift modifier is not used (as I can see), it can be used for switching between these tools if one of them is used. -- With respect Alexander Rabtchevich Hi, On Wed, 2006-09-13 at 09:28 +0300, Alexander Rabtchevich wrote: Working with healing brush in 2.3.11 I've found it very useful. But sometimes it is required not only to change the texture, but also to change color of the image part while retouching with clone tool. So I switch between tools with C and H hotkeys. It could be even smoother if these tools use the same source: if a source for healing brush is selected, and user switches to clone tool, the clone tool should already have the same source and be ready to work. The only reasonable way to implement this would be to remove the Heal tool and integrate healing as an option in the Clone tool. But we decided against this because the clone options are already quite complex. This is similar to the Pencil and Paintbrush tools. There could be a toggle for Hard edge in the Paintbrush tool instead of a dedicated Pencil tool. This would result in a more
Re: [Gimp-developer] soc-2006-healing-brush branch merged and closed
Hi, On Wed, 2006-09-13 at 10:52 -0500, Tim Mooney wrote: My guess is that Kevin isn't listening right now, because of the move and internship he mentioned at the bottom of this email: https://lists.xcf.berkeley.edu/lists/gimp-developer/2006-August/016152.html Sorry, I missed that. Thanks for reminding me. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] heads up to translators
Hi, not sure if I can reach a lot of translators here, but the ones who are reading the gnome-i18n list should already be aware of this issue... We have started to use translation contexts in GIMP. Only in a couple of places so far, but we will probably extend this to more strings. The idea of translation context is that one string can have different meanings depending on the context it is being used in. And this string is likely to have different translations depending on the context. The solution to this problem is to add some context for the translators. You will find strings such as: gradient|Linear interpolation|Linear The first is a linear gradient as used with the Blend tool. The second is linear interpolation as used in the Scale dialogs. Now if you are translating such a string, you must not include the translation context in the translation. There are several translations in CVS that got this wrong. For example: #: ../libgimpbase/gimpbaseenums.c:388 msgid gradient|Linear msgstr degradado|Lineal #: ../libgimpbase/gimpbaseenums.c:563 msgid interpolation|Linear msgstr interpolación|Lineal This needs to be changed to: #: ../libgimpbase/gimpbaseenums.c:388 msgid gradient|Linear msgstr Lineal #: ../libgimpbase/gimpbaseenums.c:563 msgid interpolation|Linear msgstr Lineal So please review your translations and take care that these issues are fixed before 2.4. Oh, and please, don't start a discussion about this. This is the established technique for adding context to translations. It is supported by GLib and used throughout the GNOME project. Sven PS: Perhaps someone wants to update the README.i18n file for this? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Customizing GIMP windows and behavior
0 In article [EMAIL PROTECTED], 0 Des URL:mailto:[EMAIL PROTECTED] (Des) wrote: Des The users are mark inclusions that they analyze on a stone. The Des three views are used as follows: Des Des 1 view serves as a working view or scratch pad Des 1 view serves as a view that will be printed on a report Des 1 view serves as internal view, i.e. includes additional markups Des that is not in the report view. What is lacking if you use layers to contain this additional markup that is not to be in the report, and adjusting the visibility appropriately? I can see that it would be nice to have layer groups and read-only layers available, but I don't think that they would be essential. P.S. please trim your quotes appropriately! ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu procedure blurb review
I feel bad for not updating this project but I have been experiencing difficulty getting my CVS to compile owing to some glib-2.0 problems (I have version 2.10.3 but for some reason 'configure' fails to recognize this and the test program fails to compile if I use the --disable-glibtest switch). I successfully accomplished a compile about a month ago but broke something since then. If necessary, I could generate a blind patch which someone else would need to test. As Sven stated, there is not a great deal left to do. I think that the result of discussions in the previous thread (http://www.mail-archive.com/gimp-developer%40lists.xcf.berkeley.edu/msg11301.html) amount to: 1) Remove any non-blurb patch code: mainly concerning 'gimp-layer-set-preserve-trans' and color specifications. 2) Change the instances where I employed the term 'selection frame' (mainly the distress selection script, if I recall). 3) Address the changes which employ the term alpha object to describe an operand which is defined by the alpha channel not be zero. There are several of these but the term is consistently used so that a simple substitution would work. I am still unsure what term should be used, my preference at this point would be to alter the wording from (for example): Fill an alpha object or selection ... to Fill a selection (or an alpha) ... The parenthetical serves as an indication of additional functionality; although the functionality is not very well described. 4) Remove the patches that marked the menu path for language translation (by prepending an underscore). I will of course try to get my CVS working again but do not wish to hold things up and I am skeptical as to whether I could provide a tested patch within even a week's time (I have other things occupying my time this week). Hi, we still need the Script-Fu blurbs reviewed for GIMP 2.4. http://bugzilla.gnome.org/show_bug.cgi?id=351283 Come on, guys, this is almost done. Someone just needs to pick up the patch from Saulgoode (http://flashingtwelve.brickfilms.com/GIMP/Bugzilla/patch-script-fu-new-blurbs) and port just the changes to the blurbs to the CVS HEAD branch or the 2.3.11 release. This would really help us a lot to get ready for 2.4. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu procedure blurb review
I feel bad for not updating this project but I have been experiencing difficulty getting my CVS to compile owing to some glib-2.0 problems (I have version 2.10.3 but for some reason 'configure' fails to recognize this and the test program fails to compile if I use the --disable-glibtest switch). I successfully accomplished a compile about a month ago but broke something since then. If necessary, I could generate a blind patch which someone else would need to test. As Sven stated, there is not a great deal left to do. I think that the result of discussions in the previous thread (http://www.mail-archive.com/gimp-developer%40lists.xcf.berkeley.edu/msg11301.html) amount to: 1) Remove any non-blurb patch code: mainly concerning 'gimp-layer-set-preserve-trans' and color specifications. 2) Change the instances where I employed the term 'selection frame' (mainly the distress selection script, if I recall). 3) Address the changes which employ the term alpha object to describe an operand which is defined by the alpha channel not be zero. There are several of these but the term is consistently used so that a simple substitution would work. I am still unsure what term should be used, my preference at this point would be to alter the wording from (for example): Fill an alpha object or selection ... to Fill a selection (or an alpha) ... The parenthetical serves as an indication of additional functionality; although the functionality is not very well described. 4) Remove the patches that marked the menu path for language translation (by prepending an underscore). I will of course try to get my CVS working again but do not wish to hold things up and I am skeptical as to whether I could provide a tested patch within even a week's time (I have other things occupying my time this week). Hi, we still need the Script-Fu blurbs reviewed for GIMP 2.4. http://bugzilla.gnome.org/show_bug.cgi?id=351283 Come on, guys, this is almost done. Someone just needs to pick up the patch from Saulgoode (http://flashingtwelve.brickfilms.com/GIMP/Bugzilla/patch-script-fu-new-blurbs) and port just the changes to the blurbs to the CVS HEAD branch or the 2.3.11 release. This would really help us a lot to get ready for 2.4. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu procedure blurb review
I feel bad for not updating this project but I have been experiencing difficulty getting my CVS to compile owing to some glib-2.0 problems (I have version 2.10.3 but for some reason 'configure' fails to recognize this and the test program fails to compile if I use the --disable-glibtest switch). I successfully accomplished a compile about a month ago but broke something since then. If necessary, I could generate a blind patch which someone else would need to test. As Sven stated, there is not a great deal left to do. I think that the result of discussions in the previous thread (http://www.mail-archive.com/gimp-developer%40lists.xcf.berkeley.edu/msg11301.html) amount to: 1) Remove any non-blurb patch code: mainly concerning 'gimp-layer-set-preserve-trans' and color specifications. 2) Change the instances where I employed the term 'selection frame' (mainly the distress selection script, if I recall). 3) Address the changes which employ the term alpha object to describe an operand which is defined by the alpha channel not be zero. There are several of these but the term is consistently used so that a simple substitution would work. I am still unsure what term should be used, my preference at this point would be to alter the wording from (for example): Fill an alpha object or selection ... to Fill a selection (or an alpha) ... The parenthetical serves as an indication of additional functionality; although the functionality is not very well described. 4) Remove the patches that marked the menu path for language translation (by prepending an underscore). I will of course try to get my CVS working again but do not wish to hold things up and I am skeptical as to whether I could provide a tested patch within even a week's time (I have other things occupying my time this week). Hi, we still need the Script-Fu blurbs reviewed for GIMP 2.4. http://bugzilla.gnome.org/show_bug.cgi?id=351283 Come on, guys, this is almost done. Someone just needs to pick up the patch from Saulgoode (http://flashingtwelve.brickfilms.com/GIMP/Bugzilla/patch-script-fu-new-blurbs) and port just the changes to the blurbs to the CVS HEAD branch or the 2.3.11 release. This would really help us a lot to get ready for 2.4. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] soc-2006-healing-brush branch merged and closed
Hi Sven, Regarding your questions: Of course optimizing the Laplacion solver is still desirable. Have you done any profiling on this yet? Is there a way to benchmark it? A regression test would also be nice to have for this purpose. At the moment I haven't done any profiling. I haven't thought of any benchmarking except for total time spent. The inner loop runs until convergence so we may have to change that to run for a specific number of times for profiling purposes. Kevin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] healing brush hanging X11
Hi Sven, I haven't had any time to try this. I depart this Saturday and don't anticipate having more time to devote to the healing brush in the near future. Once I get settled I'll set up a work environment and try and work on the code some more. Kevin On 9/13/06, Sven Neumann [EMAIL PROTECTED] wrote: Hi Kevin,a while ago we discussed how to change the heal tool so that it doesn'tdo it's time-expensive calculations while the user is painting but to delay it until after the mouse has been released. Have you tried tochange the code in this direction? Do you need more help with this?Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
