Copy Visible & Paste Script
Posted 20 December 2007 - 03:45 PM
You can download it here: http://fence-post.de...Script-72552828
These steps can be done quite easily in GIMP (Copy Visible > Paste > Add New Layer > Anchor Floating Selection), but this really speeds things up.
Essentially, it is GIMP's version of Photoshop's Apply Image option (although I believe the PS version has more options....not sure on that though).
The inspiration for this script is from kward (http://kward1979uk.d...e-copy-28607825) who wrote the original version, but I've updated it to run in GIMP version 2.4. I've also modified the script to work on Grayscale and Indexed images.
Just download the zip file, double-click the zip file to open, and place the script (scm file) in your GIMP scripts folder (ie....C:\Program Files\GIMP-2.4\share\gimp\2.0\scripts)
Then, go to the main GIMP window (not the image window) and choose the Xtns Menu > Script-FU > Refresh Scripts and it should appear in the Image Window under the Edit Menu > Copy Visible & Paste as Layer
Posted 20 December 2007 - 04:56 PM
I have a potential suggestion regarding the placement of the option within the menus. This may just be my personal preference, and it doesn't affect the functionality as such, so this would just be a personal preference choice. With my modified version of kward's script I have the command appearing amongst the other copy commands. See this:
If you think this is a good idea and want to implement it you just need to alter the menu registration as follows:
"/Edit/Copy/Copy Visible & Paste"
But anyway, an excellent script.
Posted 20 December 2007 - 05:17 PM
Off-topic: I wasn't aware that you're no longer Insanity-Prevails here....just figured that out! :w:
Posted 20 December 2007 - 05:22 PM
i was hoping for something alike, i used very often that script, and the new options are cool
Did you already posted your version of "copy merge" somewhere ? ...could you give me the link?
Posted 20 December 2007 - 07:04 PM
i didn't know you know how wright script fu, a very nice surprise (same i could say for Fatal Edge :h:)
My suggestion is just for the name i think something as "Visible2NewLayer" may give a better hint of what the script does
But well also the actual name is clear...no so much for the original script name "copy-merged"
Posted 20 December 2007 - 09:46 PM
@greentunic: glad you like it!
Posted 20 December 2007 - 11:08 PM
From the opening post:
I would assume the desired behavior is that the pasted layer appears in the same position as the original selection; however, your script will run into problems of the pasted layer being offset (from its original location) in certain situations. One situation is caused by the fact that GIMP tries to ensure that whenever something is pasted, the result lies within the view window so the user does not have to go looking for it. Another is that, in the event that the pasted buffer exceeds the boundaries of the active drawable, GIMP will center the pasted buffer over that drawable (horizontally, vertically, or both; as necessary).
Also, your script creates a new layer in the 'let*' block. This lies outside the UNDO group so the layer will not be "uncreated" if the user performs an UNDO. While there will be no apparent problem with this, the memory from that created layer will remain tied up until you close the GIMP (this is called a "memory leak"). For this reason, you should avoid creating layers (selections, masks, paths, etc) in your 'let*' block. Just declare 'theResult' variable in the 'let*' block and then create the new layer from within the UNDO grouping.
You probably should perform a 'gimp-displays-flush' at the end of your script. This will ensure that the image view and associated docks are updated.
Posted 20 December 2007 - 11:21 PM
@saulgoode: Thanks for reviewing it and providing me with the feedback. I need all I can get! :w: I'll study your explanation a bit more tonight and modify the script accordingly to fix as you suggested. Being a non-programmer, even the simple stuff has been a challenge. I'm trying to read up on Scheme & Script-Fu programming resources (I've got tons of links), in hopes to put together tools that are not only functional, but are properly written. Your suggestion is one small step to a more properly written one! LOL (ok, I'm not really LOL'ing, but I always wanted to type that.)
BTW, do you have some suggestions for resolving the selection issue you addressed in your first paragraph? That part I'm not sure on how to fix.
Posted 21 December 2007 - 12:43 AM
A good approach would be to save the selection to a channel, select none, copyvisible-n-paste to a new layer, then restore, invert, and clear the selection. This will work because the copy buffer (and resultant floating selection) will be the same size as the image, and not be offset. I wrote a similar script a couple of months back ("Image->Merge Visible to New Layer") that basically takes that approach, except that I don't actually invert and clear the selection (it is, of course, retained so that I can do that afterwards, should I wish).
Make sure that you "clean up" after you finish by restoring the original selection and removing the channel that your script created. My script used a named buffer (which I had to remove afterwards) because I did not want my default copy buffer to be affected by what I viewed as a merging of layers. It is reasonable that your script should modify the default copy buffer because it is viewed as a copy operation.
Can I ask why you ZIP your files? It would be preferable (to me) if I could just view it as a text page without downloading and UNZIPping -- I wouldn't even mind waiting those endless milliseconds for all those extra kilobytes. :l:
Posted 21 December 2007 - 04:03 PM
Well, crud. I guess it really makes mine un-necessary. If I knew that one was available, I wouldn't have posted this one. But, nonetheless, it's a good learning experience, so all is not lost.
Force of habit! At work, we're sending stuff back and forth between clients and everything's got to be zipped up due to filesize restrictions. Plus, I'm trying to do my part to preserve bandwidth. :l:
If you feel so inclined, you could take a look at my powertoning script and see if I've done anything incorrectly. I looked it over and but didn't see anything glaring, but after reviewing your above suggestions, I wonder if 2 of the variables I declared in the let* block are wrong. (I mean the script works fine on the surface, but from a programming standpoint it could create "problems".) That script can be found here: http://fence-post.de...Script-71897344. I've checked that one out and it's in scm format. Maybe you could brew some coffee while waiting for it to download!
Thanks for all the help. What a learning experience.
Posted 22 December 2007 - 05:07 AM
you may guess who requested that script ? :w:
Was something on top of my wishlist, ...and i was really happy then Kward wrote copy-merged
And i'm even more happy for copy visible & paste , i really missed something alike for gimp 2.4
to me should be bundled in Gimp,perfectly replace a missed feature equivalent to PS "Apply to Image" .
a perfect Christmas gift for my Gimp...:h:really welcome
Posted 26 December 2007 - 04:11 AM
@PhotoComix: Merry Christmas!! :l:
@saulgoode: Thanks again for the suggestions and letting me see your version, as that was a good learning opportunity in itself.
I noted that you used the procedure (I guess these a called procedures?):
gimp-edit-named-copy-visible & gimp-edit-named-paste whereas I used gimp-edit-copy-visible & gimp-edit-paste. In the procedure browser, I noted that your version stores the operations for later use regardless of cut or copy operations. Is there an advantage to using your way or is it a matter of preference?
I also like the way you didn't define a new layer in the script to which you would paste/anchor the contents, but used the gimp-floating-sel-to-layer float procedure to handle that in one step. Seems a lot easier/cleaner. But I just left my script as is, since there's no reason to make my script identical to yours.
Thanks a bunch.
Posted 26 December 2007 - 05:53 AM
Indeed. Such an approach is also simplified if you have a script which will clear everything except the selected region. This was one of the first Script-fus I ever wrote and I find myself using it almost as much as I use "Edit->Clear" (http://flashingtwelv...ect-isolate.scm).
I tend to call them "functions" since they can return values (in programming terminology, procedures do not generally return anything; they just "do" things), but "procedures" is fine (they are listed as such in the Procedural DataBase). To all the strange denizens of the world of lambda calculi, they are neither functions or procedures; they are semantically referred to as "closures" since they encapsulate a mutable environment space at the point of evaluation (and they don't really return values, they "evaluate to abstractions"). This is probably why nobody understands functional programming, including functional programmers.
The difference is that the default, unnamed copy buffer (often called a "clipboard") will not be modified as a side effect. It should not be assumed that a copy will be immediately followed by a paste, the user might very well do other things in the interim. Imagine if you performed a copy and then ran a script which, for example, pixelized your image; you would expect your clipboard contents to be unchanged. Since my script "merged layers", I wished the clipboard to be unchanged. Since your script performed a "copy" to a new layer, it might be expected to affect the clipboard (it might also be argued that it should not).
Posted 26 December 2007 - 09:49 PM
Makes perfect sense! Thanks for all your help.