Smooth[anisotropic] in G'MIC 1.7.9

adam933 · **Joined:** Dec 10, 2012 **Posts:** 32

I'm trying to install Crazy Hedcut, and it errors out on the anisotropic step.
I noticed that the name is actually Smooth [anisotropic] in 1.7.9.

Can I fix this in the py script? Using Gimp 2..8.18.
If so, I would appreciate some guidance, or any other solution.

Thanks in advance,

adam933

HuertaAmber · **Joined:** Nov 21, 2016 **Posts:** 2

I noticed that the name is actually Smooth [anisotropic].

dinasset · **Posted:** Mon Nov 21, 2016 1:24 am **(#3)**

Unfortunately G'MIC does not guaranty compatibility among releases even when the change is just done for (let me call this one) "aesthetical" reasons; in fact the name has changed but the use and the parameters are the same.
So please do the following:
1.open the python source
2.locate line 251
3.change it from

Code: Select all

+"-gimp_anisotropic_smoothing 330,0.36,1,0.5,7.38,0.8,30,2,0,1,1,2,0,24,0")

to

Code: Select all

+"-gimp_smooth_anisotropic 330,0.36,1,0.5,7.38,0.8,30,2,0,1,1,2,0,24,0")

But this is not the only change needed:
hence please:
4.locate line 268
5.change it from

Code: Select all

+"-gimp_bilateral 10,12,2,2,0,24,0")

to

Code: Select all

+"-gimp_smooth_bilateral 10,12,2,2,0,24,0")

Save/Close. Rerun the filter.

Thanks

dinasset · **Posted:** Mon Nov 21, 2016 2:06 am **(#4)**

if you feel uncomfortable editing the source by yourself, here the amended version

Attachment:

DIEGO_ARTISTIC_CrazyHedcut.zip [5.32 KiB]
Downloaded 292 times

Ronounours · **Joined:** Jan 03, 2011 **Posts:** 1656

dinasset, what you call "aesthetical", I call it "coherence".
Improving the coherence of a software, slightly, step by step, even by breaking some compatibility sometimes, ensures you don't end with a software like Windows, that is a nightmare for every user.

dinasset · **Posted:** Mon Nov 21, 2016 4:10 am **(#6)**

David, there is also another aspect of any software package: compatibility as much as possible (which someone may call also friendliness).
In this particular case, if you aimed to have a more "coherent" set of filters, so that all the smoothing filters start with the word "smooth", you could have guaranteed also the backward compatibility by creating an "equ" statement, such that the previous name was still accepted and automatically converted, given that the effects are the same.
Different views of the important characteristics of software packages....

Ronounours · **Joined:** Jan 03, 2011 **Posts:** 1656

"Compatibility as much as possible" is indeed not my primary goal, as you noticed.
I don't want to keep old bits of code, like a ball and chain for several years to come.
This is not a disrespect of users, or anything like that. I say it again, but the users of the plug-in *do not loose features*, as the concerned filters are still here for use.

I understand this can cause issues to developers of scripts though.
But, it's exactly like when I use the OpenCV library in my C++ code : when they decided to change the API a few years ago. I had to update my codebase to take these new modifications into account. I cannot complain. As a developer, when I use an external library, it's because it saves me a lot of time and efforts, so I accept the possible 'maintenance' work I have to do in my own code using these libraries. Yes, it's a bit of work, but it's still nothing compared to the entire coding of the functionalities provided by those external libraries.
As a script writer, you use the G'MIC plug-in as an external library, so you have to accept as well that there are risks of changes in the API.
That is particularly true for all G'MIC commands whose name starts with 'gimp_*', as I explained in a previous message, because those commands are intended to have a very versatile API : the filter can be updated, some parameters can be modified/added/removed.

In your particular case, if you would have used the more general '-smooth' command, you wouldn't have faced this issue. This command is a 'native' one and its API hasn't changed for years. That's the only thing I can ensure : a native command API won't be changed during the lifetime of one particular G'MIC version.
As I said, if you want to be sure you keep the API for a particular 'custom' command, then just copy/paste it into a .gmic file, and includes it when you invoke G'MIC (with command '-command your_file.gmic'). Thus, you become a maintainer of these new custom commands, and you decide if and when the API must change for these particular commands.

dinasset · **Posted:** Mon Nov 21, 2016 4:57 am **(#8)**

This script writer who was using G'MIC interface almost everywhere -hence promoting it- for a (long) while will change his (simple) mind...and forget it.
GMIC is great to be used interactively and fully supported in this use, as you explained, but is poor as far as the gimp interface is concerned IMHO, as you admitted ("compatibility as much as possible is indeed not my primary goal"): adieu to its rich library.

Ronounours · **Joined:** Jan 03, 2011 **Posts:** 1656

That's your choice, even if I'm sorry to read that.
Ensuring a stable API for G'MIC commands starting with 'gimp_' is really not possible from my side. The primary reason of the embedded update mechanism in the plug-in is exactly doing the contrary (breaking the API of these commands, by adding new options / improving a filter). Maintaining a stable API for these would mean no filter updates anymore, for anyone.

I'd recommend you look at the 'native' commands instead (like '-smooth') in the future, so you could keep writing your appreciated scripts that won't break after each filter update.

iarga · **Posted:** Mon Nov 21, 2016 2:22 pm **(#10)**

Dinasset, perhaps you can (try to) make/script filters for/in G'MIC? :bigthup

adam933 · **Joined:** Dec 10, 2012 **Posts:** 32

Thank you Dinasset !

Being both clumsy and lazy, I downloaded the zip you provided and fixed both my Win7 Gimp, and my Manjaro Gimp.

I very much appreciate your help.

adam933