You are here

Silly arbitrarily limited Ripple function... Any workaround?

Is there a way to remove the arbitrary wavelength limit of 200 on the Filters -> Distorts -> Ripple function?

I'm trying to get a vaguely rippling flag effect on a 1700x941 pixel image, but the limit of 200 on the wavelength makes it look totally wrong. I need a longer wavelength... What can I do? Is there a better filter somewhere? I'm not a coder, so I doubt I'd have a clue how to write my own filter... Is there a configuration file somewhere that I can edit the silly hard-coded limit to be larger and get the actual effect I need rather than being limited to the scope of the imagination of the original coder?

I'm guessing by how it looks currently that I probably need to be able to Ripple at a minimum of 300-400 wavelength to get as few ripples as I want (just a couple over the course of the entire image...)

In the interim, I guess I'll "make do" with 'curve bend' instead... Though, I'd honestly rather use Ripple since it uses a 'regular' sine wave rather than the imprecise 'irregular' curves. *Sigh* For now, I'll justify using curve bend by the notion that rippling flags are inherently 'unpredictable,' 'irregular.' But, I'd still rather have a somewhat 'idealized' image.


You could invoke the plug-in from the Script-fu Console.

First, find out the numeric ID of your layer: open up the "Layer->Scale layer..." dialog and notice that at the top of dialog is the layer's name followed immediately by a hyphen and a number (for example, "Background copy-7"). The number is the ID of the layer. Once you have the ID, you can cancel the dialog.

Next, open up the Script-fu Console ("Filters->Script-fu->Console") and type in the following command:

(plug-in-ripple 1 0 ID WLEN AMP VERT 0 1 1 0)

ID is the layer ID
WLEN is the wavelength you want (you are not restricted to <=200)
AMP is the displacement amplitude of the wave
VERT is "1" for vertical waves, "0" for horizontal.

For example: "(plug-in-ripple 1 0 7 400 35 1 0 1 1 0)"

"Ripple Texture" FencePost posted at gimpdome has widgets with period 1..400 and amplitude -200..200, so yeah, the only really important limitation seems to be period>=1.
according to procedure browser, full parameters are:
run-mode [normally RUN-NONINTERACTIVE]
drawable [layer]
orientation [0 = Horizontal, 1 = Vertical]
edges [0 = smear, 1 = wrap, 2 = blank]
waveform [0 = sawtooth, 1 = sine wave]
antialias [boolean]
tile [boolean] (Retain tilability)

My understanding of the problem is: the GUI interface to the plugin imposes more constraints than the actual algorithm used. That is, the GUI widget (say its a slider or a thumbwheel, I haven't actually directly used the ripple plugin) stops at 200, but the algorithm will accept a greater number.

Saule suggested a work-around. Here is another: use GIMPscripter, which is a point-and-click interface for programming shortcuts to plugins. I just tried it. It allowed me to enter constants for most of the parameters to ripple. I let the wavelength (actually called the period) and the amplitude parameters be deferred, i.e. not constants for the shortcut I was creating. When I invoked the shortcut, a control panel GUI appeared and let me enter 400 for the wavelength, and seemed to work. I could be wrong.

I am not REALLY suggesting you use GIMPscripter, since it is work in progress, not complete. So this is hijacking your thread.

GIMPscripter and GIMP itself is stupid about defaults and limits for parameters to plugins. The defaults and limits for parameters (which is valuable metadata) is more or less lost in GIMP. (Its not lost for Python language plugins, just obscure how to get it. Definitely lost for other plugins and probably for GIMP internals. Many GIMP developers know this should be improved in a future version of GIMP.) But GIMPscripter in its current state does not show you the defaults for the parameters for the plugins that it calls, and does not try to enforce any limits. So in this case it lets you enter any value for the wavelength parameter of the ripple plugin. This is bad for the user because you have to know what parameter values are acceptable. It is good in this case because it lets you get around a deficiency in the plugin GUI.

If a future GIMP keeps the defaults and limits that a plugin registers with, and a future GIMPscripter enforces those limits, then GIMPscripter might not improve your problem with ripple. (I agree with you that it is a deficiency in the ripple plugin GUI.)

Also, shouldn't the ripple plugin deal in wavelength as a percentage of the image size, instead of pixels? That is, it should be "Wave count" instead of wavelength. So for example, if you want 3 ripples in the image, you enter 3 instead of 400 for a 1200 pixel wide image. In general, more parameters of plugins should be in percent, instead of in pixels.
Thats something I learned while coding GIMPscripter: many of the parameters to GIMP and GIMP plugins are in pixels but it would be easier for a user if they were in percent. That is something GIMPscripter would help fix. For example, a GIMPscripter macro could implement "Grow selection by percent" instead of the current "grow selection by pixels". (This is just off the top of my head, grow might not be in pixels.)

Subscribe to Comments for "Silly arbitrarily limited Ripple function... Any workaround?"