On the road to 3.3

Here is a running list of changes done on the G’MIC project since the latest (stable) 3.2.0 release.

New features:

  • [core-321] Optimize evaluation of empty boolean expressions (commit).

  • [math-core-321] New function csqrt() computes the square root of a complex number (commit).

  • [stdlib-321] Add new command line_aa: draws anti-aliased lines in images, using Xiaolin Wu’s line algorithm (commit).

gmic_line_aa

  • [stdlib-321] New command da_freeze allows to freeze several dynamic arrays at the same time (commit).

  • [stdlib-321] New command lof returns the list of specified features (separated by commas) for each selected images (commit). For instance: sp lena,eagle,cat,dog ${"lof [w,h]"} returns 512,512,520,480,600,550,1024,685.


Improvements / Changes:

  • [core-321] Command foreach: Add copymark to resulting image names when +foreach is used (commit).

  • [math-core-321] Add detection of the not operator for faster pre-evaluation of some math expressions.

  • [stdlib-321] Convert commands mode3d, moded3d, double3d, focale3d, specl3d, specs3d (aka m3d, md3d, db3d, f3d, sl3d, ss3d), as well as sphere3d, as custom commands rather than native ones (commit).

  • [stdlib-321] Command sphere3d is now able to generate 3D spherical mesh using three different methods: icosahedron subdivision, cube subdivision and spherical angle discretization.


Bug fixes:

  • [core-321] Fix command name when empty argument is specified (commit).
1 Like

Bonjour,

Thank you for this new command (line_aa).
Many pixels of the original color are lost with this new command.
It is very visible on a black background.
Is this normal?

‘line_aa’ vs ‘line’ :

line_aa

line

Code used for the test :


test_lines :
512,512,1,3
512,512,1,3
repeat 16
 srand $>
 line. {round(u([w,h,w,h])-1)},1,${-RGB} 
 srand $>
 line_aa.. {round(u([w,h,w,h])-1)},1,${-RGB} 
done
text. "line",20,20,16,1,127,127,127
text.. "line_aa",20,20,16,1,127,127,127

That may be the nature of antialiasing. Perhaps allow smudging as opposed to blurring of corners…?

Sometimes it might be helpful to have

PRERELEASE = $(shell date +%y%m%d%H%M)

in the gmic Makefile, if that is accepted in gmic?

I think the anti-aliasing should apply only on the alpha channel if no alpha has been detected, and apply on color if alpha has been detected.

I don’t understand the question, this is exactly line 181 of the current Makefile.

No no %H %M is added!

Ah I see. What would be the point of adding the hour/minute to the prerelease name?
Manage several prerelease done the same day?
Does it happen that often that we need it?

Yes exactly, as I follow your changes/additions!

@afre

line_aa : A simple analysis is enough to see that the result is very different from what is presented on the page

@samj Now I remember the solution. You divide the alpha by 255 if the Alpha(1) is equal to 255. Then divide the color channel by the alpha ignoring zero (just wish G’MIC has a special case of div which ignores 0), then change the alpha back to normal value. This works if and only if your image has an alpha value.

I wonder what would prevent someone needing it to actually write it as a new command.
This seems pretty straightforward :wink:

Concerning the anti-aliased drawing, it may need some update, I’ve just implemented the algorithm as described in the wikipedia page. Any good improvement is welcome.

It depends heavily on each case what you want to happen, I tend to include specific handling per command. Having said that, here’s what I use in my own local testing when required:

gcd_divnz : skip ${1=};
  l[] is_image_arg=${"is_image_arg $1"} onfail is_image_arg=0 done
  if $is_image_arg pass$1 1 +eq. 0 add. .. rm.. div[^-1] . rm.
  else +eq. 0 add[-2,-1] div[^-1] . rm. noarg fi

It handles either gcd_divnz[-2,-1] or gcd_divnz.. . which is convenient for me.

2 Likes

Anyway, another remark on anti-aliased line.

The classical way of doing anti-aliasing is rendering an image at 200%, then reduce its resolution by half when your rendering is finished.
If you do this for the line drawing over a black background, and you compare with the use of line_aa:

foo :
  256,256,1,3
  512,512,1,3

  repeat 100
    coords:=round(u([w,h,w,h]-1))
    col=${-RGB}
    line_aa.. {[$coords]/2},1,$col
    line. $coords,1,$col
  done
  r2dx. 50%

Then you already see that line_aa (left) artificially adds some thickness to the drawn segments, compared to the standard way of doing anti-aliasing rendering (right).

I’m really not sure at which point you want your drawn line pixels having exactly the specified color.
it seems to be in opposition with making anti-aliased rendering.

Nice discussion here: https://diglib.eg.org/xmlui/bitstream/handle/10.2312/14944/025-032.pdf?sequence=1&isAllowed=y

This part pretty much echoes my thoughts on the matter (manual being what a pixel artist would do - automatic/Superpixelator being their method):

image

PS - Wu’s method is fine but I don’t like its ropey appearance.
PPS - Iterative guided filter or rolling guidance may be a dirty way to solidify the line.

It is a trial to improve the visibility of ‘line_aa’.
The result of the rendering is ‘line_aa_plus_matrice’
The original rendering is ‘line_aa’

line_aa_plus_matrice

line_aa

Code :

test_lines_2 :
512,512,1,3
repeat 16
 srand $>
 line_aa. {round(u([w,h,w,h])-1)},1,${-RGB}
done
(0.2,0,0.2;0,1,0;0.2,0,0.2)
convolve[-2] [-1]
rm.
text. "line_aa_plus_matrice",20,20,16,1,127,127,127

@Reptorian
@garagecoder
Thank you for research and the idea.

1 Like

The Cascading Self-Glitching filter in the Gimp GMIC 3.2.0 (stable) GUI at Testing > Joan Rake > Degradations works fine however in the Windows cli latest stable 3.2.0 I get this error:

‘’’
C:\Users\me>gmic v -99 in.png fx_self_glitching_cascade 5,1,0,50,50,3,3,1,55,55,0,45,45,0.75,3,0,0,0,0,1,0,0,256,1,19,0 o out.png

 [gmic] *** Error in ./fx_self_glitching_cascade/*repeat/*local/(...)/*if/modf/*if/modular_formula/ *** Command 'fill': Function 'if()': Missing argument, in expression 'if(!skip; if(0>3, if(!(0%2) ,calc(a)=mf(a+var3_mod); ,calc(a)=amf(a+var3_mod); ); ,if(0>1, if(!(0%2) ,calc(a)=mf(a*(abs(256)/var3_mod)); ,calc(a)=amf(a*(abs(256)/var3_mod)); ); ,if(!(0%2) ,calc(a)=mf(a); ,calc(a)=amf(a); )'.
 [gmic] Command 'fill' has the following description:

fill (+):
value1,_value2,… |
[image] |
‘formula’

Fill selected images with values read from the specified value list,
existing image
or mathematical expression. Single quotes may be omitted in 'formula'.
(equivalent to shortcut command 'f').

Example:
  [#1] 4,4 fill 1,2,3,4,5,6,7
  [#2] 4,4 (1,2,3,4,5,6,7) fill[-2] [-1]
  [#3] 400,400,1,3 fill "X=x-w/2; Y=y-h/2; R=sqrt(X^2+Y^2); a=atan2(Y,X);
   if(R<=180,255*abs(cos(c+200*(x/w-0.5)*(y/h-0.5))),
   850*(a%(0.1*(c+1))))"

‘’’

In Windows cli Version 3.2.0 (pre-release #221102) it works perfectly well, so somehing broke along the way.

I know there’s a perfectly usable Self-Glitching filter under normal Degradations, however I prefer the multiple x,y positional shifts available in the broken one.

Cheers!

line_aa

@David_Tschumperle

Bonjour,

For information I compared the rendering of line_aa with the program of the page Anti-aliased Line | Xiaolin Wu's algorithm - GeeksforGeeks
The results are identical (attached file : comparaison_Xiaolin-Wu.xcf.bz2).
For me there is too much loss of quality using this algorithm on lines :smiling_face_with_tear:
Merci quand même pour la programmation de cette commande :grinning:
comparaison_Xiaolin-Wu.xcf.bz2 (6.2 KB)

I’ll have a look at it. Modf is my command.

1 Like

line_aa

There may be an error in the Wikipedia code:

There is a very clear difference between the rendering of Wikipedia and line_aa visible on test4_Xiaolin-Wu.xcf.bz2 (Gimp image)
test4_Xiaolin-Wu.xcf.bz2 (92.8 KB)

Code :

test_lines_4 :
Larg=394
784,510,1,3
fill_color 255,255,255
repeat 16
 line_aa. 394,5,$Larg,510,1,0,0,255
 Larg+=21
done