Release of G'MIC 3.4

Software G'MIC
81

Done. pushing to gmic-community.

Point() were placed into burst mode, so that rendering is deferred until the mouse-up event. That lays most of my interactive sluggishness qualms to rest. I’m doing a flurry of default value adjustments to accommodate the preview display. Code could use some refactoring now, but that is a later chore. Thanks for insisting; your request makes good sense. Chalk it up to however many hundreds of filters you’ve written to my — um… four? five? three?

This just in — the width in one quadrant is somewhat, sometimes markedly, thinner than in the quadrant 180° displaced from it. seems a function of tilt_strength and becomes more markedly apparent as tilt_strength => 1. Not sure what is going on within the innards of curve or whether I am doing something peculiar in rendering its set up. Something to check — but later for me. The City of New York is calling me…

1 Like
82

FYI, I’ve uploaded new binary packages for G’MIC 3.3.3_pre.

83

Now I am having trouble reproducing the phenomenon. Maybe your release fixed it. Off to the city; see if I can make it happen in the leisure of the evening.

84

Hello Garry,
I also get a “centering” problem with the preview when the input image is not square :

image
image1783×942 127 KB

1 Like
85

Noted. Far away from home at the moment; a TODO for this evening.

1 Like
86

I tested the some of the new functions, and they are great so far with only one issue I noted. Only tested rand() and permute().

Issue: The srand() before rand doesn’t seem to do anything to rand. I don’t see that the values are “seeded”. I tested with one srand(), and two rand(), and then I tested with srand(),rand()x2 to see if srand() can change instances of rand().

Issue #2: permute() could have been allowed on a image indexes. However, I think as it is now, I can create a simple command to reorder color according to channels value with crop(#-1).

Also, I think performance has returned back to old G’MIC. That’s appreciated.

Finally, I got something with the new math parser feature:

#@cli rep_sort_colors_by_channels_values:
#@cli : Sort images accordingly to channel values.
rep_sort_colors_by_channels_values:
    foreach {
        eval "
            new_image=permute(crop(#-1),w#-1,h#-1,d#-1,s#-1,'cxyz');
            new_image=sort(new_image,1,whd#-1,s#-1);
            new_image=permute(new_image,s#-1,w#-1,h#-1,d#-1,'yzcx');
            copy(i(#-1,0,0,0,0),new_image[0],whds#-1,1,1);
            "
    }
87

So. How about another whirl on the Wurlitzer?: 1791890

88

Something mysterious in the land of widths…

circtest: -skip ${1=30},${2=0},${3=34}
   foreach {
             thick,tstren,angle=$*
             =>. canvas
	     # 100 Circular plots,
	     # centered on w/2,w/2
             100,1,1,2,cexp([0,2*pi*x/(w-1)])
             =>. plots
             f[plots] ">
                        begin(
                        mat=eye(3);
                        scale=0.375*w#0;
                        mat[0]=scale;
                        mat[2]=w#0/2;
                        mat[4]=-scale;
                        mat[5]=w#0/2
		                     );
	     (mat*[I(#$plots,x),1])[0,2]"
	     # curve plot
             curve[canvas] [plots],$thick,$angle,$tstren,1,1,255
	     rm[plots]
   }

Test run. Change tilt strength

gosgood@bertha $gmic run '-m circtest.gmic                         \
                          version                                  \
                          256,256,1,1 =>. canvas                   \
			              +circtest[canvas] 60,0,45    \
			              +circtest[canvas] 60,0.25,45 \
			              +circtest[canvas] 60,0.50,45 \
			              +circtest[canvas] 60,0.75,45 \
			              +circtest[canvas] 60,1.00,45 \
			              keep[^0] append x r2dx. 50%  o. /dev/shm/circtest.jpg'

Obtains:
circtest

Reading the test images backwards, with lessening tilt_strength I would expect a gradual infilling of the two thin areas as the edge of the virtual pen grows thicker/less elliptical, arriving at the image on the left. Two endpoints are fine (tilt_strength = 0/1) but fractional strengths seem strange, with the strangest response at tilt_strength= 0.5.

Have done no spelunking (too busy cleaning up my own messes). Might have time to do traces today. The City calls, but not as stridently as yesterday.

1 Like
89

Hi,

it seems i don’t get the expected result when applying the filter :

1
11920×1040 174 KB

2
21080×1080 45.8 KB

Is there a workaround?

And i tried the same settings on my laptop ( previous settings were on desktop ) and got something different :

image
image2561×1535 411 KB

1 Like
90

You are perfectly right. I’ll check and try to fix that.
Also, I’ve already fixed the ‘hole’ in the curve happening in the first case (w/o tilt), that was due to a rounding error in the computed point coordinates.

1 Like
91

Related to what I posted immediately before you – the thinning pattern is irregular for fractional tilt_strengths. Immediate workaround is to work with tilt strengths of zero or one.

The key bit that I am contemplating stems from remarks in post 16 in the ABN thread. For ±N in the pink area for tilt_strengths<0.5, we obtain thickness indirectly from the green quadrilateral whose height has not entirely vanished. But that configuration still admits the segment P–Pp aligning with ±N at some other orientation, in particular orientations that approach tilt_angle+90° as tilt_strength approaches 0.5.

For tilt_strength > 0.5 ±T orientation dominates and the thin parts thicken, but only at one orientation, tilt_angle+90° and at tilt_strength = 1.0 ±N wholly coincides with ±T and the calligraphic effect is turned off.

Not clear to me yet the reconfiguration approach that needs to be worked out. A cuppa coffee or two, and a few relaxing meetings with assistant commissioners, and it might be clear to me.

92

Try running ABN Filigrees at reduced opacity, say 0.2, and just one spinner, rather large and look at the preview image. Because of slight overlap between successive plotting of quadrilaterals (two triangles, actually, but same difference) you can actually see how the orientation of ±N varies. You may get a eureka insight from it.

93

Here’s a better problem statement (maybe). This entails a circular dataset and we are plotting it clockwise. Have the diagram in front of you.

  1. For tilt_strength<0.5 ±N is almost, but not quite, aligned with S and so too is the segment P–Pn.
  2. Say, for successive segments, P–Pp rotates clockwise a certain angle ψ. Necessarily, the perpendicular ±T also rotates at ψ.
  3. But ±N will only rotate at a fraction of ψ, being a blend of (mostly) of the fixed orientation S and (a little bit of) rotating ±T — ±N rotates at a slower angular rate than either P–Pp or its perpendicular ±T.
  4. Because of this, at some new orientation, P–Pp will “catch up” and align with ±N. That makes a new thin region. This is the issue which is tossing a spanner into the works.

Won’t be able to touch any of this until evening descends on the American North Atlantic seaboard.

94

OK, not totally fixed, but I’m progressing in the right direction.
I’ve partially recoded command curve to fix a few additional problems your example made me realize (like when curve has very close consecutive points, normal estimation can go really wrong).

Probably some work remains, but this looks better than before.

image
image1920×1200 311 KB

1 Like
95

Feature request for v2s(). Can there be a option to set where the numbers goes? Default seems to be starting from the left, but what if I want to set to the right instead? The reason I’d like it is to add {_'0'} or 48 onto 0s, and have the numbers start on the right as a option. So, I can print the remaining zeros.

Also, srand() before rand() still don’t work. Different values every time.

96

OK @grosgood , I think the tilt issue is now fixed for real!

Lot of things were not being done correctly, that was a very nice trip to find all the quirks.
Now, the tilt angle corresponds to what’s expected (so you won’t need to add 90° to your tilt parameter in your filter).

If you have some time to test and tell me what you think about it, that would be cool :slight_smile:

97

Not right now, but a couple of hours from now.

Of course. Bugs are almost always more interesting than production code. I’ve frequently felt a let-down after deploying a solution. I’m not talking about routine bugs that are sins of omission or commission, but the kind that force some sort of paradigm shift in how I’ve modeled a problem and conceived a solution. “I’ve found the bug. It’s in my head.” Those are the most entertaining kind.

1 Like
98

circtest

Yes!

test_abn

As you noted, a few minor adjustments in ABN Filigrees, and that would be that.

2 Likes
99
  • 2024/01/12: Release of version 3.3.3.
2 Likes
100

I forgot to mention this, but remember the conversation about u() in the math parser, and you added the _include_(min/max) thing?

I wonder if that needs to be done with rand() as well. Also, there’s the issue of srand() not affecting rand() though.

C:\Windows\System32>gmic echo {srand(50);rand(#5,0,1);}
[gmic]./ Start G'MIC interpreter (v.3.3.3).
0.13243688389948496,0.0086219562237667743,0.93690020589551426,0.34747295043139553,0.34000822746660753
[gmic]./ End G'MIC interpreter.

C:\Windows\System32>gmic echo {srand(50);rand(#5,0,1);}
[gmic]./ Start G'MIC interpreter (v.3.3.3).
0.51519300009012059,0.03471523361157515,0.49972651910496096,0.77842243103739395,0.88865798406504515
[gmic]./ End G'MIC interpreter.

C:\Windows\System32>gmic echo {srand(50);rand(#5,0,1);}
[gmic]./ Start G'MIC interpreter (v.3.3.3).
0.60273454375628721,0.096547843910881281,0.0002792875748777966,0.92015480876903855,0.98068178584349386
[gmic]./ End G'MIC interpreter.

C:\Windows\System32>gmic echo {srand(50);rand(#5,0,1);}
[gmic]./ Start G'MIC interpreter (v.3.3.3).
0.77207849192714284,0.12469581587349433,0.8424506082298352,0.10056414387667648,0.31335092808896464
[gmic]./ End G'MIC interpreter.