Re: [Gimp-developer] Creation of a "set of operations" item
Hi folks, I wanted to offer some comments about the macro discussion. While I would agree that macros are not a single solution to a problem, they can be a real convenience and what I feel is more important, have a positive contribution to the quality of the work. If for example, you use a macro to create a layer, and assign it's name and position in the layer stack, then the name and position are reliable (no misspellings / forgot to name it) if you are going to access that layer with another macro. I actually find that associating a set of commands with the 'state' of the editing process makes the difference between a 'macro' that I use occasionally verses a 'step' that I use for ever image that I process with Gimp. There are a couple of advantages to associating a 'step' with the sate of the editing process: You can apply the 'step' to many images at a time instead of one at a time. (for each image in the directory - bump it to the next step) You don't have to keep track of the order in which you apply steps, in the case of a macro, if it wants to access of use a layer that hasn't been created yet the results can be counterproductive. As a user, the types of things that I do with 'steps' are the preparation work for something that I would do by hand and they are the things that I would do on every image (in a particular order). As an example, the first - by hand - operation that I am going to do is see if I need to use the rotate, transform or crop tool. My personal workflow is to do these operations before I create any new layers. The automated preparation work is: 1st Step Set the grid spacing to be 24 squares (based on long side) and centered on the image Expand the canvas by 25% (of long side) Rename the 1st and only layer "Original" Following this example, the next step would be to get the image ready for using the 'curves' tool. 2nd Step Shrink the canvas to fit the layer "Original" Set the grid spacing - one grid = image perimeter, essentially turning grid off Extract the Color information from "Original" to a new layer "ColorLayer" & push it to bottom of layer stack Create a copy of "Original", name it "DynRange" & push it to the top of the layer stack The sets of commands whether they are macros or steps aren't the big decisions, but being able to package all of the little decisions and apply them to several (whether it is 2 or 3 - 20 or 30) has a dramatic impact on the time that it takes to edit the images, produces consistent results, and does not negatively impact the part of the process where creativity or human judgment is desired. Of course there is no one workflow that will be the right one for every one, or even a modest percentage of the people who use Gimp, but if it is fairly easy to record steps and associate those steps with the state of a workflow that an individual wants to set up, it can be a real nice thing. I don't know where the development team would want to draw the line how much to provide, but it seems that good set of tools for people to customize their own workflow would be a good goal. Stephen Kiel On Fri, Mar 21, 2014 at 1:33 PM, peter sikking wrote: > hi all, > > Joao asked me personally to comment here, so here I am. > > I will do some horrible top-posting because I think > I can summarise quite a bit what you wrote. > > I believe what you refer to below are 'macros.' > > simple enough: at any point in GIMP where an operation > can be applied, a macro can also be applied. > > I intent to help GIMP users to make/edit macros in many ways: > record them; grab a bunch of operations from the operations > stack and put a name on it; write some source text in a file. > > do keep in mind that macros are nothing but a convenience > for some GIMP users, not all GIMP users. a macro is never > the single solution to a problem. > > first working with operations (see > <http://blog.mmiworks.net/2012/01/gimp-full-gegl-ahead.html> > for an old sketch, will be updated at lgm) has to work in > a sufficient fashion before we can think of introducing macros. > > ps: first we would have to start supporting 'export pipelines' > where users can define a series of operations for each pipeline, > and save these to be used in different xcf files, before macros > could be used in these pipelines. > > users should not have to learn macros to make use of these > pipelines (a macro is never the single solution to a problem). > > > Hi, > > I would like to discuss about the possibility > > of a "Set of operations" GIMP item - > > > > In the current state of GIMP, I think one > > nice thing to have would be the
Re: [Gimp-developer] Creation of a "set of operations" item
Joao, I would like to comment that this suggestion seems like it would be a real enhancement for gimp. I did a writeup on combining commands for the current / older version of gimp using the python interface at: http://www.gimp.org/tutorials/Automate_Editing_in_GIMP/. The tutorial talks about combining commands, and in the second part orgainizing them into workflows. It may be possible to use it as a prototype or the start of a list of possibilities. As I have not really been tracking the GEGL development, I can't offer any to the point comments, but I am sure wishing you luck with this idea. Stephen Kiel On Sat, Mar 15, 2014 at 7:27 AM, Joao S. O. Bueno wrote: > Hi, > I would like to discuss about the possibility > of a "Set of operations" GIMP item - > > In the current state of GIMP, I think one > nice thing to have would be the ability to > specify sets of GEGL operations that could > be re-used across the UI in some different places. > > One example of such "Set of operations" could be, > for example, a gaussian blur filter - the set > includes the parameters as well. Another > example could be a "Resample to 50% size, Unsharp mask" > set. > > Where could those be used? > I thought of primarily two places - with more potential > nice places to come along: > > 1. As an "adjust layer" - just that - have > a special Layer class that encapsulates a set > of Gegl operations, and apply then to the > rendering of the layer imediatelly bellow. > This would give us "Adjustment layers" > as they are called in other software, > essentialy "for free" > > 2. Attached to an image, as a set to be > automatically applied before exporting the > image to an specific format. > Currently, the "merge-visible-layers" action > is performed at this stage, for most formats. > But in some mail-threads here it became clear that > the ability to resize an image to an specific > size, among other things, could greatly > simplify the current workflow for keeping > a high-quality XCF image, and exporting > incremental versions of down-sampled/filtered > versions for production. (Like in edit, save, > resize to 50%, export as PNG - undo to further > editing the image, and the resize is lost, and must > be reapplied when exporting the new version) > > And there could be some "bonus places" to attach these > "sets of operations": > 3. To patterns, before applying them - so > that rotation and scaling of patterns would > be easy > 4. To brush masks, as part of the painting dynamics. > > > Can we discuss this further along? > I know Mitch is experimenting with > operations attached to layers, but I don't > know wether they are along thse lines, or more > like recording all operations mad in a layer, > in an early quest to "non destructive editting". > > Maybe there is a roadmap for a similar > thing already, that I am not aware of - but > having the "sets of operations" behave > as regular GIMP items that can be used - and > being able to pick/create then at the layers dialog > bucket fill tool options, export dialogs, could > be a nice way of enabling the possibilities > of GEGL and non-destructive editing to end users. > > Regards, > > js > -><- > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > List membership: > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list > -- Stephen Kiel 26602 Strafford Mission Viejo, CA 92692 *Mobile/SMS (949) 702-1993* Home (949) 367-2915 snick.k...@gmail.com http://stephenkiel.blogspot.com/ ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gimp-docs] [Gimp-web] Proposed gimp tutorial
Marco, Thanks for all of the help! I don't really have any direct suggestions for why there would be a problem with the git clone. There is a limitation that I ran into with testing which was the index.htrw files work almost like an index.html file would except it did not seem to follow the links completely. For example the 'index.htrw' file under tutorial references the directories that hold all of the tutorials: GIMP Script-Fu Write Scheme for GIMP. GIMP Script-Fu 2 Write More Scheme for GIMP. Automated Jpg to Xcf Import Xcf Images a Directory at a Time. All of these links simply showed a directory of files in the index.htrw, I just followed the same pattern as the existing tutorials. I concluded that there is a downstream process that defines the styles, fonts, colors, and how to follow the links. My conclusion could be wrong, but I did not see how to display any of the gimp web with the same 'look' as I see on the gimp web site. Just to be sure I was clear with my intent, there should have been the following in the share export_to_gimp_web [stephen@localhost export_to_gimp_web]$ ls -R .: AutomatedJpgToXcf index.htrw ./AutomatedJpgToXcf: example-jpeg-to-xcf.py gimp_jpg_to_xcf_popup.jpg gimp_menu_compare.jpg index.htrw script-fu-example-jpg-to-xcf.scm The directory AutomatedJpgToXcf and file index.htrw should go into gimp-web/tutorials. The index.htrw would replace the older index.htrw and has a link to the new tutorial in AutomatedJpgToXcf. There are index.htrw files in several places, just wanted to be clear about which I was trying to modify. I am not sure if I addressed your questions or issues or not. As I said there are some limitations to what I was able to test, I did try to stitch my tutorial into the tutorials section following in the same technique as the existing tutorials. I do appreciate your testing the changes, I would hate to be know as the guy who broke everything. I am going to be leaving in a few minutes and will be on the road for about a week. I will have very limited access to the internet, so perhaps if there is something that I need to fix, I can look at it next week. Thanks for the help and suggestions. Stephen Kiel On Wed, Jul 24, 2013 at 2:59 AM, Marco Ciampa wrote: > On Tue, Jul 23, 2013 at 07:32:57PM -0700, Stephen Kiel wrote: > > > I did format the tutorial into web format > > Here you can help me a lot. I have tried to test your tutorial before > committing it to the git-web repo but I was unable to test it. > > I have started with trying to test the actual web site without any > additions directly from a git clone command. I have tried both with > makefile and with Apache SSI directly. > > Same results: it keeps to create into the git dir a bunch of html files > and install just a few of them into the right installation dir. > > There must be something wrong here. > > I use Linux Ubuntu 13.04 wich comes with python-2.7 (could be a problem > the python version?) > > Any hint? > > -- > > > Marco Ciampa > > ++ > | Linux User #78271 | > | FSFE fellow #364 | > ++ > ___ > gimp-docs-list mailing list > gimp-docs-l...@gnome.org > https://mail.gnome.org/mailman/listinfo/gimp-docs-list > -- Stephen Kiel 26602 Strafford Mission Viejo, CA 92692 *Mobile/SMS (949) 702-1993* Home (949) 367-2915 snick.k...@gmail.com http://stephenkiel.blogspot.com/ ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] [Gimp-docs] [Gimp-web] Proposed gimp tutorial
Roman & Pat, I spent quite a bit of time fiddling round with git-bz and after downloading it, configuring it, and trying to use it to send in the differences from checking my tutorial into git (local check out / check in *seems* OK), I have come to the conclusion that this is probably not what you guys are using because it sure seems to be - broken. After trying to send in a patch with git-bz it told me that I did not seem to be logged into bugzilla.gnome.org in firefox - I am. It does not seem to be able to read the cookies (Firefox V22 on Fedora). Is there a set of instructions written down anywhere that indicates what format and method someone should use to send in changes, updates and new content like a tutorial? I did format the tutorial into web format and do a checkout / check in into the repository, but not being able to get any farther with it is beginning to take a lot of time. The files I am trying to check in are in a share (should be easy to download) at: https://spideroak.com/browse/share/Stephen_Kiel_Pictures/Stephen_Kiel_Gimp_Tutorial I would appreciate any help you could give me. I will be on the road for about a week, so I may be slow getting back to you. Thanks, Stephen On Mon, Jul 22, 2013 at 7:22 AM, Stephen Kiel wrote: > Roman and Pat, > > I have made some progress toward getting my tutorial ready for release, > but I am at a point now where I have hit a wall, and I would like to ask > for some advice on how to proceed. > > I did do a final edit of the tutorial, format it into xhtml, and add a > couple of pictures. I downloaded a copy of Bluefish and used it to format > the material into an xhtml file adding the boilerplate provided in the > tutorial template by hand. It seemed to render well in the Firefox browser. > > I did find a procedure for adding content through git web at > https://wiki.gnome.org/Git/Developers and followed it as best as I could. > I was able to clone the gimp-web, check out a branch, make local changes > and commit them, but then my progress stopped. My questions are: > > 1) when I performed a 'git branch -r' several branches were listed. I > guessed and picked HEAD as it appeared to link to origin/master. When I did > a 'git status' and 'git commit -a' I got a warning message that “refname > 'HEAD' is ambiguous”. Did I pick the wrong branch? Is there another > problem, or is this warning normal? > > 2) The guidelines I was looking at seemed to be saying I could either > use 'git-bz' or 'git push' to get my changes back to the main repository. > Neither worked, so I was wondering which technique I should focus on. Would > rather not debug them both at this time (could use quite a bit of time, > since I don't know what either is trying to do). > > The error message that I go with git-bz was: > > > bash: git-bz: command not found... > > The error message from git push –dry-run was: > > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > > and the repository exists. > > A git pull –rebase right before trying the push seemed to find the > repository and verify that my current branch is up to date. > > I would appreciate any pointers you could give me. I am attaching a copy > of the transcript from my shell session. I am also attaching a copy of the > files I was trying to add & modify in case it is relevant or you would like > to take a look at them. > > In the mean time, I will start looking at git-bz in case that is the > write way to go. It looks like there may be some setup issues, even though > the error message make it look like it is an installation issue. The > options for the bz command were not clear to me. The wiki page indicated > the syntax should be: > > git-bz file product/component HEAD > > I am guessing the product should be 'gimp-web', but when I look at > https://bugzilla.gnome.org/buglist.cgi?quicksearch=gimp-web I see the > component listed as both gimp-web and www.gimp.org. Do you know which it > should be, or whether it matters? When it asks for 'file' I am assuming it > is looking for the results of the local 'commit'. In my case the feedback > was > > [HEAD a97ce5a] Added tutorial Automate Creation fo XCF from JPG" > > Are they looking for a97ce5a as the file? > > Thanks, > > Stephen Kiel > > > On Wed, Jul 10, 2013 at 10:49 PM, Roman Joost wrote: > >> Dear Stephen, >> >> On Tue, Jul 02, 2013 at 12:37:33PM -0700, Stephen Kiel wrote: >> > Roman, >> > >> > I did browse through some of the tutorials & looked at they way they >> were >> > marked up. I don't think porti
Re: [Gimp-developer] [Gimp-docs] Proposed gimp tutorial
Andrew, Thanks for your reply and feedback. The answer to your first question is yes, I would like to to be able to post a tutorial or tutorials on the site http://www.gimp.org/tutorials/ or somewhere like it. I understand that the gimp-doc group might not want to post every tutorial the general public might submit, there might be a lot of repetition and the quality might not be sufficient. On the other hand, I think there are many areas where expanding the range of topics covered with tutorials or other forms of documentation could benefit Gimp. I would be happy to write a couple of tutorials or if someone wanted to co-author the tutorials that would be fine as well. Sometimes when two people are working on documentation one person can spot what is not clear in the other person's explanation. Going back and forth can make a better end product. The dilemma is there is no point in writing a tutorial if you don't have a venue to publish it. I do not have access to a website where I can post tutorials, and if I did I would imagine it would be so obscure no one would see it. I suspect there are other Gimp users who would be willing to share ideas but don't have a venue to publish them. About your comments on the text, the way you specify the image type is more of a means of control rather than an issue. The attached jpegs are small shots of the menu from my automation scripts with and without an image open. The scripts that are intended to run on a directory of images are on all of the time, the scripts that are intended to run on a single file / image are grayed out (image type "*") unless an image is opened. The four items I identified in the tutorial were things that I had to do more research on and work harder at when I wrote the scripts to automate my flow. I thought they might be good things to point out in a more advanced tutorial. The script is pretty handy, saves time, and when you get past the less commonly understood aspects it is pretty straightforward. It seemed that if the four little "tricks" were widely understood, something like this script should have been written 10 years ago (maybe it was I I just could not find it). Anyway, thanks for the feedback. Sincerely, Stephen Kiel On Thu, Jun 20, 2013 at 2:59 PM, Andrew Douglas Pitonyak < and...@pitonyak.org> wrote: > > Hello Stephen, > > Disclaimer: I have no particular ability myself to integrate these.. > > Having read these, I see that you have much that is useful to say. In > other words, I found automated-jpg-to-xcf.odt to be informative. > > That said, are you saying that you would like to create content that is > published here: > > http://www.gimp.org/tutorials/ > > It looks like you chose the correct lists (doc, web, and developer) to > obtain appropriate feed back. > > I recommend (and other feedback may negate what I say) that you identify > what you would like to have as topics in the tutorial; for example: > > "How to write a script that is available when an image is not open" > > I was not aware that this was an issue until I read your document. > > I expect that this tutorial would be "Change all JPG files in a directory > to XCF". > > > > On 06/20/2013 02:29 PM, Stephen Kiel wrote: > > Gimp Doc Guys, > > One of the listed methods to contribute to the Gimp project, listed on > the website, is to write a tutorial. I tried sending in a tutorial for > basic scripting (it was probably too long) about a year and a half ago. I > did not hear back, but since the scripting tutorial did make some > improvements I hope that it did have some positive contribution. > > I did have another area where I thought that a few tutorials might be of > interest and helpful to others, and that is in the area of Automation. > This is an area that is nearer to my interests anyway (closer to my career > interests). I think Gimp is unique in its capability as a platform for > automating the image editing process. I am talking about Automating the > process of custom edits not just using an "I feel lucky" button on a photo > manager. > > I think there is room in the area of automation for a couple of > tutorials, I wrote up an example for one (importing a directory of images / > jpg -> xcf). I think other tutorials could cover reading & writing > parasites, parasites as flow control variables, how to build & execute a > recipe / process / flow. I touched on these possibilities in the included > file "Introduction". > > Anyway, here is my dilemma. I would be happy to write a draft for > tutorials on some or all of these topics, or better yet, co-author them > with a member(s) of the gimp-doc team. I have no where to publish a > tutorial, and it seems pointless to
[Gimp-developer] Proposed gimp tutorial
Gimp Doc Guys, One of the listed methods to contribute to the Gimp project, listed on the website, is to write a tutorial. I tried sending in a tutorial for basic scripting (it was probably too long) about a year and a half ago. I did not hear back, but since the scripting tutorial did make some improvements I hope that it did have some positive contribution. I did have another area where I thought that a few tutorials might be of interest and helpful to others, and that is in the area of Automation. This is an area that is nearer to my interests anyway (closer to my career interests). I think Gimp is unique in its capability as a platform for automating the image editing process. I am talking about Automating the process of custom edits not just using an "I feel lucky" button on a photo manager. I think there is room in the area of automation for a couple of tutorials, I wrote up an example for one (importing a directory of images / jpg -> xcf). I think other tutorials could cover reading & writing parasites, parasites as flow control variables, how to build & execute a recipe / process / flow. I touched on these possibilities in the included file "Introduction". Anyway, here is my dilemma. I would be happy to write a draft for tutorials on some or all of these topics, or better yet, co-author them with a member(s) of the gimp-doc team. I have no where to publish a tutorial, and it seems pointless to write something that no one will read. Take a look at the attached documents and scripts. Let me know if this idea is something that sounds interesting. The *.odt format files are open office writer format. Thanks, Stephen Kiel -- Stephen Kiel 26602 Strafford Mission Viejo, CA 92692 *Mobile/SMS (949) 702-1993* Home (949) 367-2915 snick.k...@gmail.com http://stephenkiel.blogspot.com/ ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
