Error with updated Neon command

(dumb) #1

I feel as if this is important enough to warrant a topic on its own. I cannot fix this for the life of me: I’m trying to make my Neon filter work with the alpha channel but it keep spitting errors of the following sort at me. When I shove this in the local custom command filter:

+split_opacity rm[1]
fx_solidify_td[0] 100,0,10,2,0 +invert_rgb[0]
blend[1,2] difference
a[0,1] c

…I get this (boosted alpha channel for emphasis using GIMP curves):


But when I put the following code in my .gmic file:

#@gui Neon alpha: fx_neon_alpha()
#@gui : sep = separator(), note = note("Gradient norm")
#@gui : 1. Smoothness = float(0,0,10)
#@gui : 2. Linearity = float(0.45,0,1.5)
#@gui : 3. Min threshold = float(40,0,100)
#@gui : 4. Max threshold = float(60,0,100)
#@gui : 5. Negative = bool(0)
fx_neon_alpha :
+split_opacity rm[1]
fx_solidify_td[0] 100,0,10,2,0 +invert_rgb[0]
blend[1,2] difference
gradient_norm[1] ${1-5}
a[0,1] c

…this happens:



Even if I empty the command so that it’s just GUI variables doing nothing, it persists. When I scrub all of the GUI variables, it suddenly works. I don’t know why it’s messing up so badly.

G'MIC fun with afre
(G'MIC staff) #2

Why did you add parentheses to the command name here ?

(dumb) #3

I wanted to do without the preview command. Even if I add in the preview command or get rid of the parantheses it doesn’t work, giving me the same error.

(G'MIC staff) #4

If you really don’t want a preview, then use special command name _none_ for the preview command. About the error: maybe try running the equivalent command from a shell, it’s more easy to debug a filter as you get more detailed logs.

(dumb) #5

I wanted a preview but I didn’t want it to go through a special preview command like all the other GUI filters.

Now I’ve tested it with the shell (v2.3.4 but here it should do the same job) and it’s even less clear as to what’s going on. On some images the gradient norm stuff doesn’t work in the shell whereas it does in GIMP with the plugin.

Edit: I might have gotten somewhere by using fx_gradient_norm instead of gradient_norm. I don’t know yet.

(dumb) #6

Right, the code works but it looks absolutely terrible. Compared is the original Neon with the newer alpha-compatible Neon:

image image

The second one looks nowhere near as striking and has all manner of artefacts such as sharp changes in colour which aren’t obscured by the highlights like in the first one. I’ve burned myself out over several hours trying to make something that works. I gave up before starting with the boost glow. If anyone can salvage anything out of this, here’s the code.


Do you have a working script to compare against? I had difficulty making it correct (some problem with invert_rgb - is that a command? I replaced with negate to get it to do something).

And don’t give up, I think it’s worth keeping :slight_smile:


1. gradient_norm does not take in any parameters. It is fx_gradient_norm that you want.
2. I would place displays and prints to step through the filter to see where things go wrong.

(dumb) #9

I’ve been running the command while showing the end outputs at every stage, that’s worked for me. For now I’ve given up with the command as although my initial problem is fixed, it looks terrible for what it’s meant to be.


Just a hunch here, but I think it could be something to do with either cut or normalize (two commands for restricting value range). Maybe try using cut to limit it…


@Joan_Rake1 Do you have a copy of the original neon filter? That way we could compare the code of that one with your current code.

(dumb) #12

Both versions are bundled with G’MIC. I made a successful pull request.

(dumb) #13

Turns out that all I had to do was add this into the original command:

rgb2cmyk s c a[0-2] c invert_rgb a c

Here’s the updated filter but I won’t submit another pull request yet because I want to add some more options.