Hah, you did catch me. Off to replace it now.

graechan, I haven't used G'MIC but on line 62 of your script (rel 3), you have:



I do not understand why the third argument is 'layer' and not 'copy'. Could you double-check or explain, please?

Wow, in just a few days you've taken this from a casual suggestion to a fully-realized, very capable filter. Like I always say, every day is like Christmas morning around here. And the toys keep getting better. Thanks, Santa!

Yes! A most opportune tutorial .... I'm playing with filters at the moment and your suggestions will be really helpful.

I downloaded the updated script, set the spikes to 6, the length to 100, iterations to1 and it's been going for about 5 minutes now and it's up to 84 layers. Is that supposed to happen?

No, it is not. There are a few different ways to remedy the problem.

@graechan, the problem is caused by the SF-ADJUSTMENT returning a non-integral number, even if you have the precision set to "0" (see the second part of this posting for a description).

You can remedy this by one of the following methods:

• Change the SF-ADJUSTMENT from a slider to a spinbox (i.e., change last argument from "0" to "1"). (You might also change the step value to "1"; I can think of no reason to disallow an odd number of spikes.)
• Add "(set! spikes (truncate spikes))" to the start of your procedure.
• Change the test in your spike loop from "(unless (zero? cnt)" to "(when (>= cnt 0)".

.

note: whatever you do may have to be done twice in the script, once for the G'mic version and once for the plug-in version.

I had to force close gimp to get stop. I gave it another test leaving it set to default and it worked fine. Then I adjusted # of spikes up 1 and it went buggy again.

Saulgoode I can change to a spin box and the reason I have disallowed an odd number of spikes is that Gmic's Linear blur blurs in both directions e.g when set to 90 degrees it also blurs at 180 degrees so if was set to 5 spikes it would actually return 10 spikes (I'll try something else from Gmic)

Graechan: I get the same result as Charlie .. if any adjustment is made to the "Spikes" slider the script goes awol.

The problem is as saulgoode indicated ..ie. the slider is defined with precision=0 (meaning that only the integer part of the value is displayed in the dialog box) but the value passed to the script is a full float value (accurate to about 10 decimal places) representing the actual position of the slider as set by the user. That float value will never decrement to precisely zero ..it goes past zero and just keeps on going negative! (The "(zero? cnt)" condition never retruns true.)

Since the "spikes" value is also used to determine the spike-angle you also get some very strange angles ..again accurate to about 10 decimal places.

The simplest solution is to insert the line: at the top of the procedure ..it works fine then.

For good measure you could also change the "(unless (zero? cnt) .." to "(while (> cnt 0) ..)" ..the same as the "iterations" loop later in the script.

Further thoughts and observations:
1.
You have set step=2 to eliminate odd numbers but it is still possible to enter an odd value by manually dragging the slider ..and yes you do get double the number of spikes expected!

2. You set the initial angle as half the inter-spike angle (eg. if spikes=4 inter-spike angle is 90 degrees and therefore initial angle is 45 degrees). User has no control over angle. Surely the initial angle could be set with an "offset angle" slider (as is done in many other scripts and plug-ins) so that the user can decide.

3. a minor typo in the "soft" filter registration:
Methinks it should read "Spikes" (although I suppose "spokes" is actually a close synonym in this case!)

Thanks Saulgoode and Jontait2 I have ammended the script and posted 3.1

@Graechan:
Two problems:

Firstly, your script gets confused if the input image has any layers ABOVE the active layer. This is caused by the way the "copy" layers are created below the first ("layer") layer:
Using imagestack layer number = 1 assumes that the first layer created is now top of the imagestack (ie. layer 0) - if the user has any layers above the active layer it all gets horribly confused and the final merge-down fails.

This can be corrected by stacking the layers upwards, remembering the topmost copy layer's reference and then merging-down from that uppermost copy layer. This code works okay in the "soft" filter: [The same applies for the "hard" filter, of course.]

Secondly, the length of spikes produced by the "soft" filter varies with direction (and hence with the number of spikes chosen):

In each case above the spike-length was set to 100 and the red circle is of radius 100.

This seems to be an "unpublished feature"/functional drop-off/bug in the motion-blur plugin, not your script. It looks like the plugin is producing trails out to the sides of a square of the specified size ..which can be up to 40% longer than intended.
Cheers.

Your scripts are making my CG art look really good. I used your GC Lens flare and Star Effect on this one. Thank you again Graechan, and thank you for the bug fixes.

Your image looks great Charlie.

What "atmospheric conditions"? The input image in the results I posted above was just a quick test image I made in Gimp (while I was trying to work out what the f*** was going on with one of my real pics!) consisting of a pure white circle, diameter 20px, on a pure black background. No extraneous factors at all. What you see in those result pics is what comes out of the motion blur plug-in.

The fundamental problem is that the motion blur plug-in produces streaks by simply copying the input image N times over (where N is the specified length) and shifting the layers a little each time along the specified angle. This is okay if the direction is parallel to one of the axes (x or y) ..the resultant streak is the length you specified, N. But at any other angle ..the resultant streak length is N/cos(angle) ..which can be up to N*sqrt(2) at 45 degrees.

You can try this yourself: create a test image with just a white spot on black say, then in the SFC:

..and you'll get something like this:

The streak is formed 100px to the left AND 100px upwards and therefore has length 100*sqrt(2) ..ie 141px (ish).

As far as I can see this is a functional drop-off ..the plug-in should adjust its iteration count according to the specified angle such that the resultant streak will be of the length specified (or close as possible).
Cheers

Edit: just had another look at the plug-in source (blur-motion.c) and it DOES try to compensate for the angle: but for some reason this doesn't appear to work properly.