- Add filter Testing/Iain Fergusson/PNG Processing, to help with compressabilty and/or visual quality when creating indexed images.
Managed to squash a bug with the gradient norm filter which made large round objects like the Earth disappear. Spot the difference between the old one and the new one:
#@gui Gradient norm : fx_gradient_norm, fx_gradient_norm_preview(0) #@gui : Smoothness = float(0,0,10) #@gui : Linearity = float(0.5,0,1.5) #@gui : Min threshold = float(0,0,100) #@gui : Max threshold = float(100,0,100) #@gui : Negative colors = bool(0) #@gui : sep = separator(), Preview type = choice("Full","Forward horizontal","Forward vertical","Backward horizontal","Backward vertical","Duplicate top","Duplicate left","Duplicate bottom","Duplicate right","Duplicate horizontal","Duplicate vertical","Checkered","Checkered inverse"), Preview split = point(50,50,0,0,200,200,200,0,10,0) #@gui : sep = separator(), note = note("<small>Author: <i><a href="http://ow.ly/wpsV30fzhdI">David Tschumperlé</a></i>. Latest update: <i>2010/29/12</i>.</small>") fx_gradient_norm : b $1 gradient_norm c 0,255 ^ $2 c $3%,$4% if $5 negate fi n 0,255
A similar bug occurs with Gradient RGB but I don’t know how to fix that yet.
There is a
cut in the next line; I don’t see the point of another
cut. I would be great if you could provide an example of your issue.
@Joan_Rake1, I like your neon filter very much. thank you.
Also your colour space swap is nice. Maybe something to try: Swapping multiple seperate channels from different colorspaces.
Perhaps this Wordpress blog from " Neural Outlet" gives nice ideas?:
It’s a little bit sad the YouTube videos don’t work anymore.
This particular cut sorts out image values before they’re squared so that when the image is normalised later on, G’MIC doesn’t have to deal with a really high value which makes the rest of the image too dark. Running
fx_gradient_norm 1.01,0.79,0,100,0,0,50,50 on the Earth sample image without the normalisation and my fix yields this:
The bright band is actually associated with values which are much greater than 255, hence normalisation will punch everything else down to squash everything into the usual range.
I would simply copy the gradient norm code with the cut command into your filter.
Just saw your post. I found something similar a long time ago: Curves+ for Paint.NET. Curves+ seems like it’s much more powerful.
Done that now but I think that I have a more general fix for the command which would be helpful elsewhere. I can make a separate command with the fix but the original
fx_gradient_norm is still called by other filters so there would need to be some refactoring.
Krita already has Curves+ built-in. You can adjust Saturation Curves, Hue Curves. If you want to adjust in CMYK or LAB or XYZ, it’s possible by either converting layer color space or document color space. GIMP however does not have something similar.
Curves+ is still more powerful because it is also able to convert between two individual channels and correlate between two individual channels - for example, one can have a curves profile where hue values are taken as input and alpha values are output so that the opacity of an image is dependent on its hue channel. Curves+ doesn’t appear to have XYZ but it also has straight lines, custom line drawing and even histograms.
As for my first test of Krita’s G’MIC plugin, it seems to run into segfaults a lot where the GIMP version doesn’t. Some loops just don’t seem to be closing. It also confused me as unlike the GIMP plugin, it reads my local .gmic first rather than the latest update2xx.gmic file (which is actually a bug in the GIMP plugin!)
Also I’ve found another bug which is easy to explain. Before hue smoothing:
After hue smoothing:
Simply blurring hue values produces this artefact because values between 0 and 360 result from blurring the red areas of an image. Ideally blurring the hue channel on an image like this should have no effect whatsoever. When I try to fix it using:
+gcd_hsv_select 0,0.5,1,15,0.5,0.5,5,5,1,0,0,0 rgb2hsv f "[(i0+180)%360,i1,i2]" hsv2rgb repeat $! l[$>] rgb2hsv s c b 5% a c hsv2rgb endl done rgb2hsv f "[(i0+180)%360,i1,i2]" hsv2rgb blend alpha
That’s something that’s already in Cross-color adjustment curve filter in Krita. You can adjust L* by Alpha or other values. The only advantage I see in Curves+ is that it offer curves form manipulation. Krita wins with color adjustment filter, and cross-color adjustment, and the fact that Krita offers non-destructive editing with other color models.
Yeah, that’s what I observe with some filters on Krita G’MIC.
I missed that, it’s nice and powerful. GIMP users like me will have to wait for this sort of stuff to get upgraded a lot in GIMP when 3.x comes along.
I think those things are more a case of “by design” rather than a bug. G’MIC will only do exactly what you tell it, most of the time in some concise mathematical way.
If values go out of display bounds it’s usually up to the filter maker to deal with it (many functions will cause out of display bounds problems, such as blurring/sharpening) and this is not a problem specific to G’MIC. Internally it will only see it as data…
I see what you mean but I don’t know of any workaround for this for the hue channel (your HSV select command is very useful but it just doesn’t seem to be enough for this particular case). Smoothing the Cb and Cr channels seems to have a very similar effect to what I actually want to achieve where the main artefact matters a lot less:
Ahh I think I see what you’re aiming for
You possibly noticed the many topics on pixls regarding colour blending - depending on what you want, that could be surprisingly difficult. I advise starting a new topic for it (or find a more relevant one to add to) because once again that’s not only a G’MIC problem!
I’m sorted for now (since this method is very accurate at smoothing hues in a perceptual-ish way). I’m using it in my Neon filter (which I’ll update on GitHub shortly).
My initial thought about how to do it was to blur the image in RGB space and then pull the hue channel out of the blurred image.
That works perfectly well too.
+b 10% rgb2hsv f.. "[i(#1)]" hsv2rgb rm. returns the hues and
values perfectly so that the image is almost the same besides some almost unnoticeable artefacts at the edges (which are inevitable due to boundary conditions):
Here’s the difference between the original and the new image (magnified a lot using GIMP curves):
Would it be possible to extend boundary and generate pixels based on algorithm, and then crop it?
- Update filter Repair / Local Similarity Mask , added an interactive point and also a steps control in place of ‘fast’ setting.