[Gimp-developer] Re: Script-Fu procedure blurb review
0 In article [EMAIL PROTECTED], 0 saulgoode URL:mailto:[EMAIL PROTECTED] (saulgoode) wrote: saulgoode 2. In a couple of places I employed the term selection saulgoodeframe in order to differentiate operations that affected the saulgoodeselection mask versus those that affected the selection's saulgoodecontents (e.g., 'script-fu-selection-rounded-rectangle' is saulgoodedescribed as Round the corners of the current selection saulgoodeframe). I feel that selection frame is more intuitive saulgoodethan selection mask in these contexts. Other ideas: selection boundary, selection bounds, selection outline, selection edge. Do any of these make more sense? saulgoode 3. Many scripts will operate on the non-transparent portion saulgoodeof the active layer (i.e., where the alpha channel is not saulgoodeBLACK) if there is nothing selected. I have termed these saulgoodealpha objects and consistently employed the phrase an saulgoodealpha object or selection to describe this situation. If saulgoodea better terminology is proposed to describe this, it saulgoodeshould be a simple matter to change these using sed. Opaque is the natural opposite of transparent. Does that help here? saulgoode 4) I do not understand what is happening with the saulgoode'script-fu-gap-dup-continue' portion of the patch. I saulgoodeonly changed the blurb but for some reason the entire saulgoodefile is shown as added lines. (The patch works, I just saulgoodedon't understand why.) Wild guess, without looking at it - line-end conversion? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Script-Fu procedure blurb review
On Wed, 02 Aug 2006 11:38:01 +0100, Toby Speight [EMAIL PROTECTED] wrote: 0 In article [EMAIL PROTECTED], 0 saulgoode URL:mailto:[EMAIL PROTECTED] (saulgoode) wrote: saulgoode 2. In a couple of places I employed the term selection saulgoodeframe in order to differentiate operations that affected the saulgoodeselection mask versus those that affected the selection's saulgoodecontents (e.g., 'script-fu-selection-rounded-rectangle' is saulgoodedescribed as Round the corners of the current selection saulgoodeframe). I feel that selection frame is more intuitive saulgoodethan selection mask in these contexts. Other ideas: selection boundary, selection bounds, selection outline, selection edge. Do any of these make more sense? I would go for selection outline or selection edge. It looks like most users think about the outline of the selection rather than its contents. This can easily be explained by the fact that the outline (the marching ants) is the only visible part of the selection (without quickmask). From a technical point of view, referring to the selection as a mask is more appropriate especially for heavily feathered selections for which the outline is taken arbitrarily at 50%. But even if selection mask would be more appropriate, it may be less confusing to use selection outline because this is understood immediately and there is less risk of confusion with other terms like layer mask, channels and maybe future clipping masks, etc. The terms selection bounds should be avoided because of the confusion with the function gimp_selection_bounds() which returns the bounding box of the selection instead of the selection itself. I did a quick google match between these terms with the following results (in square brakets you have the numbers for gimp + selection term and for photoshop + selection term): - selection outline [1050/609] is the most popular combination of terms for gimp users but not for photoshop users. It is found in tutorials, various articles, in the manual, etc. - selection mask [565/830] is mainly used by gimp developers and by photoshop users. For gimp, selection mask can be found in the archives of this mailing list, in scripts and in the PDB. - selection boundary [478/648] is used in the book Grokking the GIMP, in some tutorials and in archives of this mailing list. - selection frame [350/631] is used mainly in the context of XSane, in the new manual (gimp-help-2) and in a number of false positives from RPM(?). - selection edge [154/1150] is not used much in the gimp context but is the most popular term for photoshop users. For gimp, it can be found in the old manual (GUM) and in the new one (gimp-help-2). -Raphael ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: script-fu gimp-flip problems? procedural database execution failed
On Tue, 10 Aug 2004, Alan Horkan wrote: Date: Tue, 10 Aug 2004 22:26:39 +0100 (BST) From: Alan Horkan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: script-fu gimp-flip problems? procedural database execution failed I'm trying to port a script from gimp 1.2 to gimp 2 here is the currently slightly broken gimp 2.0 version, you can find the relevant part of the file by searching for gimp-flip and it is clearly marked by cursing in block caps which some may find offensive http://matrix.netsoc.tcd.ie/~horkana/dev/gnome/gimp/script-fu/scripts/pattern-swirly.scm and here is the perfectly working gimp 1.2 version http://matrix.netsoc.tcd.ie/~horkana/dev/gnome/gimp/script-fu/scripts/gimp-1.2/pattern-swirly.scm there is a commented out line ;(gimp-flip temp-drawable2 0) as well as (script-fu-transform temp-image temp-drawable2) which is simply a wrapper for (gimp-flip drawable 0) because I was trying various differnt things (invert, rotate, and I eventually decided on flip). I did try various combinations (gimp 1.3.x and gimp 2.0.x on windows). I haven't yet tried gimp 2 on linux becuase I do not have a copy conveniently available at the moment. everything else works fine except gimp-flip procedural database execution failed Any ideas? thanks for the suggestion Simon. Sincerely Alan Horkan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: script-fu gimp-flip problems? procedural database execution failed
Hi, Alan Horkan [EMAIL PROTECTED] writes: On Tue, 10 Aug 2004, Alan Horkan wrote: Date: Tue, 10 Aug 2004 22:26:39 +0100 (BST) From: Alan Horkan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: script-fu gimp-flip problems? procedural database execution failed I'm trying to port a script from gimp 1.2 to gimp 2 here is the currently slightly broken gimp 2.0 version, you can find the relevant part of the file by searching for gimp-flip and it is clearly marked by cursing in block caps which some may find offensive I just had a quick look but it seems that your script is trying to flip a drawable that hasn't been added to any image yet. GIMP 1.2 let you get away with such things but GIMP 2.0 is more strict. You absolutely need to add a drawable to an image if you want to perform further actions on it. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: script-fu gimp-flip problems? procedural database execution failed
Alan Horkan ([EMAIL PROTECTED]) wrote: everything else works fine except gimp-flip procedural database execution failed Any ideas? The script for gimp 2.0 differs in an important detail from the script for 1.2: The newly created layer (gimp-layer-copy temp-drawable TRUE) does not get added to the image. The old script does this (within copy-add-offset). You might want to try doing this in the new script as well. When I changed it here gimp-flip seems to work (although the pattern is probably not yet the desired one...). Hope this helps, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Script-Fu template - really this time...
Simon Budig ([EMAIL PROTECTED]) wrote: The script is attached as well as available at http://www.home.unix-ag.org/simon/files/script-fu-template.scm /me feels stupid. Now it really is attached... :-) Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ; ; Script-Fu template, fill in the blanks and have fun :) ; ; (C) 2004 Simon Budig [EMAIL PROTECTED] ; ; This template is in the public domain, I'd like to encourage you to ; place your script under the GPL. ; ; define the function that does the actual work. Choose a name that ; does not clash with other names in the PDB. It starts with script-fu ; by convention. ; functions that should be registered in the images context menu have ; to take the image and current drawable as the first two arguments. (define (script-fu-template image drawable color) ; the let* environment allows you to define local variables. ; It is considered good style to define all variables used ; in the script here, so that the global namespace does not ; get polluted. (let* ( ; calls to PDB functions always return a list. We have ; to pick the first element with car explicitely, even ; when the function called returns just one value. (width (car (gimp-drawable-width drawable))) (height (car (gimp-drawable-height drawable))) (x0 (car (gimp-drawable-offsets drawable))) (y0 (cadr (gimp-drawable-offsets drawable))) ; - here we pick the second element of the ; returned list... (old-fg-color (car (gimp-palette-get-foreground))) ) ; Ok, we are about to do multiple actions on the image, so ; when the user wants to undo the effect he should not have ; to wade through lots of script-generated steps. Hence ; we create a undo group on our image. (gimp-image-undo-group-start image) ; Here you'd implement your own ideas. For now we ; just select and fill a rectangle centered on the ; currently active drawable. (gimp-rect-select image (+ x0 (* width 0.25)) (+ y0 (* height 0.25)) (* width 0.5) (* height 0.5) CHANNEL-OP-REPLACE 0 0) (gimp-palette-set-foreground color) (gimp-edit-fill drawable FOREGROUND-FILL) ; it always is a good idea to restore the state of the ; GIMP. This makes it easier for the user who uses gimp, ; since e.g. his foreground color does not change ; unexpectedly. Thats why we saved it in a variable, ; now we restore it again. (gimp-palette-set-foreground old-fg-color) ; We are done with our actions. End the undo group ; opened earlier. Be careful to properly end undo ; groups again, otherwise the undo stack of the image ; is messed up. (gimp-image-undo-group-end image) ; finally we notify the UI that something has changed. (gimp-displays-flush) ) ) ; Here we register the function in the GIMPs PDB. ; We have just one additional parameter to the default parameters: ; the user can choose the color for the script. For more available ; script-fu user interface elements see the test-sphere.scm script. (script-fu-register script-fu-template Image/Script-Fu/Render/Rectangle... script-fu template (right now renders just a rectangle) Simon Budig [EMAIL PROTECTED] Simon Budig 2004/2/10 RGB* GRAY* SF-IMAGE Input Image 0 SF-DRAWABLE Input Drawable 0 SF-COLOR Rectangle Color '(10 80 256) ) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Script-Fu - Batch Mode Problem
I posted this to the users group and unfortunately did not read the reply-to correctly. I meant to send it over here. Here is the original message, reply and corrected attachment (for those who are also on the gimp-users list) --Matt -- Forwarded message from [EMAIL PROTECTED] -- On Thu, 19 Dec 2002 04:32:07 - (GMT), pcg( Marc)@goof(A.).(Lehmann )com wrote: On Thu, Dec 19, 2002 at 07:35:36PM -, [EMAIL PROTECTED] wrote: image resizing from the command line. I know that many of you out there are going to point out that ImageMagick will do what I am looking for. I have already gone down that path and the image quality of the scaled images is not up Then you probably have done sth. wrong, as ImageMagick's algorithms are way superior (and way slower ;) to the mere cubic interpolation gimp uses. Are you sure you tried sth. like: convert sourcefile -filter mitchell -geometry newgeometry destfile ok, I tried thisand I got an image that was not up to par with what can be done with Adobe's Image ready doing a similiar process. However, with Gimp, I can produce an image that is better and smaller than what Image Ready and ImageMagick can do.The mitchell filter was better than the cubic filter by far...but they were still pixelated when you started to look at the images closely. I personally think the images are good enough for the webhowever, the client that I am working for is accustom to having an image of a very high quality. also, other filters than the mitchell filter (which is usually best) are also worth a try, cubic for example should rather closely match gimp's quality. Well, I am no scirpt-fu expert, but I get a lot of mail that tells me that scirpt-fu simply doesn't work noninteractively, or at leats not correctly, or returns too earfly etc.. etc.. Ok, if script-fu is not meant to be run from the command line without interactionthen why the batch mode option? from the gimp man pages -b, --batch commands Execute the set of commands non-interactively. The set of commands is typically in the form of a script that can be executed by one of the Gimp scripting extensions. Based on the documentation I have seen, I should be able to call a script-fu function and everything should work. That is not the case. Attached is a cut down version of the script that I am attempting to call. I am calling this script from the command line as follows.. gimp -b '(script-fu-test-script 1 200 200 /export/home/matt/toprocess/W-49M01_ven.jpg /export/home/matt/toprocess/W-49M01_ven_n.jpg)' When this is run...I get back batch command: executed successfully. However, there is no outputted image to be found. If I change the 1 to 0 to run interactivly, it pops up the prompt for me to enter in the values needed for the script and runs successfully. Is there any way of outputting what has been passed into a script? Thoughts? Comments? Matt Patterson [EMAIL PROTECTED] -- end forwarded message -- test-script.scm Description: Binary data ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Script-fu opendir function
[EMAIL PROTECTED] (2002-02-14 at 1120.28 +0100): Is opendir function implemented in Gimp 1.2.x ? If not, how can I do to parse a directory in script-fu ? Tried http://people.delphi.com/gjc/siod.html? GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Script-fu opendir function
Guillermo S. Romero / Familia Romero wrote: [EMAIL PROTECTED] (2002-02-14 at 1120.28 +0100): Is opendir function implemented in Gimp 1.2.x ? If not, how can I do to parse a directory in script-fu ? Tried http://people.delphi.com/gjc/siod.html? Hmmm, AFAIK all the functions marked 'U' are missing in script-fu. But maybe it has changed? Jarda Benkovsky ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Script-fu
[EMAIL PROTECTED] (2001-05-23 at 2056.32 +0200): As far as I know, there is no Script-Fu coding style described anywhere. I tried to find some references when I modified many of the logo scripts in order to add support for Alpha to Logo, but I did not find anything. I wanted to clean up all scripts, but I did not do it because I did not know what style to follow. I would like to suggest: - use spaces, not tabs. - for comments use (left, heading, optional), ;;; (left), ;; (code level) and ; (right). - use headers in comments, so you give some info, not just the code. - files start with ;;; filename.scm --- description. - files end with ;;; filename.scm ends here. - put ) at the end of something, not in a new line. - and ( just before the text, not in the line above. - if the script launchs a dialog, write ... in the path. Mainly, Emacs Lisp rules. We can read them fully and use what we think that applies, writing a new doc for Gimp site (and start patching as time allows). TOC http://www.gnu.org/manual/elisp-manual-20-2.5/html_node/elisp_toc.html Tips and Conventions http://www.gnu.org/manual/elisp-manual-20-2.5/html_node/elisp_652.html I have not checked all the Gimp scripts, but I know some follow the rules quite good, and others not at all (not even just what you think about lisp languajes). GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
