You are here

vintage look

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
Rate this item!

This script-fu for The Gimp is a attempt to simulate a vintage look.
For Examples see http://www.mmip.net/articles/2-gimp-script-vintage-look

This Script is based on the deviantart tutorial from CrazyMurdock1 (Vintage look in Gimp)
Optional sharpness and contrast layer

Version 0.2 - Optional sharpness and contrast layer
thanks to elsamuko (http://sites.google.com/site/elsamuko/gimp)

Version 0.3 - Move to Filters -> Artistic, changes in Bleach Bypass

Code License: 
GIMP Version: 
Scripting Engine: 

Comments

> What I am doing is calling a Scheme script
> from another Python script and explicitly
> passing run_mode = RUN_NONINTERACTIVE.
> And a call in the Scheme script to
> gimp_display_new() fails.

Are you running on a headless server? My recollection is that doing a 'gimp-display-new' *on a machine that has a GUI interface* results in new display window, even though the script is being run non-interactively. In other words, I wonder if the failure you are experiencing is an actual "system" error when GIMP attempts to create the dialog window (and not that GIMP is refusing to create the dialog).

If the failure is owing to a system error, you should be able to ignore it in your script by wrapping the 'gimp-display-new' call in a catch/throw block. This would allow Script-fu to run your script non-interactively on headless machines, however, should you have a GUI interface then the new display will be created on it.

> That is interesting because the earlier
> discussion said you CAN'T pass a
> run_mode parameter to a script!!
> Now you seem to say there is a
> magical "constant" that you CAN
> pass to a script.

I'll try to clarify. When a script is executed via the PDB (e.g., it is being called from a Python plug-in), it is not invoked directly. Instead, the Python plug-in calls (via the PDB) a Script-fu invoker function which is passed the name of the script plus all of the PDB arguments (including the run-mode).

The Script-fu invoker function ('script_fu_script_proc()') tests the run-mode and if RUN-NONINTERACTIVE, runs the script with the arguments specified by the Python plug-in -- except the run-mode, which is not passed as an argument to the script (but it does set the SF-RUN-MODE constant).

If the run-mode passed to the Script-fu invoker is RUN-INTERACTIVE then the arguments supplied by the Python plug-in are ignored, and an interactive dialog is created to obtain the values of the arguments with which to run the script. Once the dialog has been closed, the Script-fu invoker runs the script (non-interactively) with the arguments that were specified in the dialog.

As a final (side) note, whenever a Script-fu script is invoked from another Script-fu script, the PDB invoker is bypassed altogether and the script run directly (and no run-mode should be supplied).

> You quote "constant" because it has a
> different value depending on the
> current run-mode (so it's not constant
> in the sense of always having the same
> value.)

Well, it's a constant in the sense that the script can't change its value. It might have been more intuitive to have implemented it as Scheme function (but that too would be somewhat odd).

> And if SF-RUN-MODE is a pseudo-constant,
> can you use: (equals SF-RUN-MODE
> RUN-NONINTERACTIVE)
> to determine the current run mode?
> (I should test that myself.)

After further testing, it appears this is possible. Sorry for having stated otherwise.

Thanks, this is educational.

Re headless: No, I am running a typical Ubuntu PC/workstation. I will have to test again to make sure that it was gimp_display_new that failed when run mode was NONINTERACTIVE. Probably I just assumed that was what failed.

Re (plug-in-gauss SF-RUN-MODE image drawable 5 5 RLE)": You seem to be saying that from a Scheme script, you CAN pass a run mode to another Scheme plugin in this fashion, whereas previously I thought you said you CANT and that the first parameter would be perceived as the image parameter. I understand your explanation of Python calling Scheme script. Its not important to me, as I won't be using Scheme to call Scheme.

My conclusion is that in order for scripts to be called with run_mode NONINTERACTIVE, the onus is on the author to insure that is possible, for example by not calling obviously GUI related functions like gimp_display_new.

I was trying to automate the testing of certain plugins by calling them noninteractively from a Python harness. I will have to rewrite some of the plugins. But now I know how to find out in Scheme whether the run_mode is NONINTERACTIVE.

> You seem to be saying that from a
> Scheme script, you CAN pass a run
> mode to another Scheme plugin in
> this fashion, whereas previously I
> thought you said you CANT ...

I do not consider Script-fus to be plug-ins (they are scripts). By the same token, filters written in C, Python, Perl, etc are all plug-ins (they are external executables that are placed in GIMP's plug-ins folder). A Python plug-in might be considered a "script" from the command line's point of view, but to the GIMP it is just an executable program (which invokes the Python interpreter and interfaces with libgimp).

When a script calls a plug-in, it needs to provide a run-mode as the first argument. When a script calls a script, it should not provide a run-mode (the run-mode of the called script is always RUN-NONINTERACTIVE).

A script can never invoke another script interactively. A script can invoke a plug-in interactively (e.g., call 'plug-in-gauss' and the Gaussian blur dialog will appear); but not another script (your script can't call 'script-fu-drop-shadow' so that the Drop Shadow dialog will appear).

> and that the first parameter would
> be perceived as the image parameter.

Basically, yes. Though not necessarily an image, but the first specified "SF-parameter" (SF-DISPLAY, SF-IMAGE, SF-DRAWABLE, SF-LAYER, SF-CHANNEL, SF-VECTORS, ...).

> My conclusion is that in order for
> scripts to be called with run_mode
> NONINTERACTIVE, the onus is on
> the author to insure that is possible,
> for example by not calling obviously
> GUI related functions like
> gimp_display_new.

I believe 'gimp-display-new' is the only PDB function that does not accept a run-mode yet still results in a GUI window being created. None of the other PDB functions create a dialog (or other window) except for the plug-ins and scripts (all which accept a run-mode argument when called via the PDB).

To expand on that, When you use script-fu there IS a plugin running. That is the script-fu interpreter.

This interpreter then runs scripts.

-Rob A.

I've been following this conversation with much interest, and curiosity got the better of me. You said:

"A script can never invoke another script interactively."

I'm curious as to why this is the case. Is it because no two scripts can be active at the same time due to scheme's structure? Is it a permission issue within GIMP's code, itself? What separates this ability between scripts and plug-ins? Not sure if I am asking this in the right way. Hopefully, you'll have an idea of what I am trying to get at.

> I'm curious as to why this is the
> case. Is it because no two scripts
> can be active at the same time
> due to scheme's structure?

This limitation is not owing to Scheme itself, nor the Script-fu interpreter, but with the way the Script-fu invoking code was originally written. To change this behavior, it would not only be necessary to re-write the dialog generating and PDB interface code, but all scripts calling 'script-fu-*' functions would need to be modified to add the run-mode.

Pages

Subscribe to Comments for "vintage look"