Yes, they should be the same.
Hey, the cli version has no concept of new-layer, right?
And what is the default color profile for you in GIMP?
Yup, color management at play.
I didn’t have sRGB-elle-V4-g10.icc profile.
I was using default color management in GIMP.
Trying with the same profile gives me results exactly similar to that of yours.
Output was set to New Layer.
Can you do the difference analysis between this and _circle-nl.png?
Hardlight won’t work in linear RGB, it expects grey at 50%. Maybe try addition, substraction or multiply instead.
Indeed, the color mode and the blend mode are to blame. I ran out of time to comment on that. In any case, the fact that in-place and new layer are different is confusing for the user. It is not just the color and blend mode combination that is a contributor but also G’MIC’s modes being different from GIMP’s.
Thanks for the tip. 
Hey, can you share the shading layer generated with G’MIC cli?
I am getting banding in the shading layer that G’MIC generates, for both G’MIC-Qt standalone and G’MIC plugin for GIMP and Krita.
If the shading layer is flawed then the artifacts will be passed onto the final image no matter the blend mode.
I have tried different color modes, blending modes, tools.
I have not tested the cli-version.
And we saw that it produces a different composite image than the plugin version.
The cli version being color-space independent can be a good tie-breaker.
Let me know your thoughts on this.
Note that this filter was coded with GUI in mind, as are all commands denoted by fx_*, though you could use it in CLI but you won’t get a shading layer.
It would be helpful for us to discuss each facet separately: blending mode, colour space, precision and linearity; and may I add, aliasing, boundary conditions and gradients.
The main problem we have identified is the banding. It comes from going from high precision to low precision, where all of the sudden, you have less possible values to describe a gradient. Then we have spacial artifacts where gradients or illumination patches interact, generating interference patterns and blending issues where they end or begin. The transitions may work mathematically but perceptually they don’t, or vice versa. It really depends on how the illumination is drawn. 3d modelling apps like Blender are better at this.
Yes, you are right.
For me personally the results are good enough for background objects in animations.
Dynamic lighting with motion blur can help with hiding the artifacts.
And since these objects are going to be much smaller in size, the artifacts will be barely noticeable.
But I would love to see the filter improve with time.
Let me know if I can be of any help.
Hold up, can you share more info on this? I use gui_ to differentiate between cli and gui filter.
In the scheme of things, it doesn’t matter. The old way was gui_*; now it is fx_*. In afre.gmic, I don’t differentiate, unless the GUI uses the CLI and so needs a separate designation, which I use afrx_* (i.e., afre_softlight, afrx_softlight, which I will unify later once I decide how).
