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

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 (

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

Code License: 
GIMP Version: 
Scripting Engine: 


ok i am new to using actions and for the life of me I can't figure out how to "download" these so i can use them in GIMP someone please help lol

Right click the link and then save Link as, browse to your .gimp-2.6/scripts folder and save.

thanks - I've been using it a lot!

Hello, I'm running my own script by command:
gimp --console-messages --no-data --no-interface -b '(once-vintage-look "test.jpg")' -b '(gimp-quit 0)'

and receive this message:
batch command: executed successfully.

but image has only new time stamp, but not edited. Please help me with batch processing of my images using this script. Thanks.

This is my own script:
(define (once-vintage-look filename)
((image(car(gimp-file-load RUN-NONINTERACTIVE filename filename)))
(drawable (car (gimp-image-get-active-layer image)))
(mm1-vintage-look RUN-NONINTERACTIVE image drawable 17 20 59 TRUE)
(gimp-file-save RUN-NONINTERACTIVE image drawable filename filename)
(gimp-image-delete image)


You need to merge the layers before saving, else only the original layer will be saved.
Add these lines to the end of the script:
(gimp-image-merge-visible-layers image EXPAND-AS-NECESSARY)
(set! drawable (car (gimp-image-get-active-drawable image)))
(gimp-file-save RUN-NONINTERACTIVE image drawable filename filename)
(gimp-image-delete img)

I will expound, since this has bitten me also.

gimp_file_save() saves a *drawable* not an *image*. You might expect it to save all layers (drawables) of the image, but it doesn't always. Exactly what parts and what format it saves depends on the extension (suffix) of the filename parameter. (If the extension is .xcf would it save all layers of the image?? I haven't tried that. If another format supports layers, like .xcf does, would it save all layers?) In other words, the image parameter is not used, since the drawable knows which image it is part of.

I have tried a call to gimp_file_save(aimage, adrawable,... ) where adrawable did not even belong to aimage, and it works, saving the drawable, without throwing an exception.

The Gimp Library documentation is not clear about this.

An aside, a followup about gimp_display_new():
See other parts of this thread.
The following code does work to keep a Python plugin from aborting if called NONINTERACTIVE with a call to gimp_display_new()

# Show the new image
try :
except gimp.error:
pass # If runmode is NONINTERACTIVE, expect gimp_display_new() to fail

Another aside, about scripts returning values:
Scheme plugin scripts don't have return values. If a Scheme script creates a new image, there is no easy way to pass the new image to subsequent scripts (say in a larger script, or a batch command)???
In a Python plugin, you can declare return values in the registration call e.g. :

....[(PF_IMAGE, "new_image", "New image.")], ....

and return them:

return new_image

Or for example you can return a drawable that the plugin has created.

It doesn't seem like many plugins are returning values, somewhat limiting their use as NONINTERACTIVE commands.

When a Script-fu script calls another Script-fu procedure, you should not specify a 'run-mode'. So the short answer is to remove the "RUN-NONINTERACTIVE" from the following line of your code.

(mm1-vintage-look RUN-NONINTERACTIVE image drawable 17 20 59 TRUE)

Going a little deeper, creating a Script-fu script typically entails two parts: 1) providing the Scheme definition for the function, and 2) registering the function with GIMP's Procedural DataBase.

PDB registration makes the script available to plug-ins and allows for the function to be added to GIMP's menus -- but PDB registration is not actually needed in order to make the function available within Script-fu (the function becomes available within Script-fu when it is defined).

Even though a function such as 'mm1-vintage-look' is registered with the PDB, within Script-fu the function appears as just a normal Scheme definition. When the function is invoked within Script-fu, the PDB interface is ignored and there is no need to specify a run-mode. (When plug-ins invoke the function, they do so through the PDB and the plug-in specifies a run-mode to the Script-fu interpreter.)

The reason that no error was generated when you ran your batch is owing to happenstance in the values used for 'image' and 'drawable' identification. When you first open GIMP both image and drawable IDs get uniquely defined starting at "1" and increasing. In addition, the constant RUN-NONINTERACTIVE is pre-defined as "1" (RUN-INTERACTIVE is "0").

Therefore, when you invoke 'mm1-vintage-look'
with the arguments:

RUN-NONINTERACTIVE image drawable 17 20 59 TRUE

the arguments passed to the function are:

1 1 2 17 20 59 TRUE

of which the first two arguments ("1 1") are treated as the image and drawable respectively. While the first (only) layer in your newly-opened image has an ID of "2", there is indeed a "drawable" that has an ID of "1" -- i.e., the image's selection.

The net effect is that your batch process is running the Vintage filter on the selection (with CMY values of [2 17 20]), but the layer itself is unchanged.

You can pass run-mode to another script by calling (gimp-proc-db-call...) instead of the script itself.

I can't find any way to determine the run-mode in a Scheme script? So how can you avoid calls that require interaction such as gimp-display-new() ?

Its different in Python plugins: run_mode is an optional keyword parameter that you can pass and refer to. It is still hidden from view most of the time, but its there if you need it. Also, a call to another plugin DOES go through the PDB, and since you can't import another plugin, you can't call it directly.

The way run-mode and inter plugin calls are implemented IS very confusing and not consistent among C, Scheme, and Python plugins.

(I had a longer post but the spam filter prevented it.)

> I can't find any way to determine the run-mode in a Scheme script?

By the time your Script-fu code starts executing, all interaction has already completed (if the script was run interactively, the dialog appeared, the user changed the settings, the dialog was closed, and your script called with the chosen values). As far as your script is concerned, it is running non-interactively.

> So how can you avoid calls that require interaction such as gimp-display-new() ?

I don't know if that can be done (I've encountered this problem before when running scripts from the console). Will investigate. To my knowledge, 'gimp-display-new' is the only PDB function which is problematic in this sense.

If you want to run a plug-in (which accepts a run-mode) interactively then the best way to do so is to pass the SF-RUN-MODE "constant" to the plug-in: "(plug-in-gauss SF-RUN-MODE image drawable 5 5 RLE)".

What SF-RUN-MODE does is pass the run-mode with which your script was initially invoked to the plug-in. The reason using SF-RUN-MODE is better than using RUN-INTERACTIVE is because your script can then be used non-interactively (by other scripts or plug-ins).

EDIT: combining the above two concepts, a plug-in could be written which only accepts 'run-mode' and only opens a new display if it is called interactively. This is something of an abuse of the 'run-mode' argument but maybe if the plug-in and its argument were named properly this wouldn't be a problem.

Plug-in's RUN function (incomplete):

run (const gchar      *name,
           gint              nparams,
           const GimpParam  *param,
           gint             *nreturn_vals,
           GimpParam       **return_vals)
        GimpRunMode       run_mode;
        run_mode = param[0].data.d_int32;

        if (run_mode != GIMP_RUN_NONINTERACTIVE)
          /* return a status */

Script-fu invocation (assuming the plug-in is registered as 'safe_display_new'):

(safe-display-new SF-RUN-MODE)

I accept your explanation that Script-fu does all the user interaction (if there is any) before the script main() runs.

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. In that case, the script IS running noninteractive, hence impossible to new display.

I think this is another case where the punishment doesn't fit the crime: gimp_display_new should return success in this case and NOT abort the script. One way of looking at it is: if the script is running non-interactively, then gimp_display_new creates a None display. Maybe that can't be done because you can't pass a None display to any other Gimp procedures that take a display?

> pass the SF-RUN-MODE "constant" to the plug-in: "(plug-in-gauss SF-RUN-MODE image drawable 5 5 RLE)"

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. 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.) Why wouldn't SF-RUN-MODE be taken as the image parameter, as explained earlier? It seems like more magic.

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

To be clear, you are suggesting that someone should write a C plugin, that you call safe-display-new that returns True if the current run mode is RUN_INTERACTIVE .
Then, in a scheme script, if you want to avoid calling gimp-display-new if the run-mode is interactive (sorry, I am not fluent in Scheme):

if (safe-display-new SF-RUN-MODE) : # if RUN_INTERACTIVE

A web search reveals that SF-RUN-MODE is fairly new (2007) and seems rather undocumented.


Subscribe to Comments for "vintage look"