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:
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:
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.
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.
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.
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.
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.
For tilt_strength<0.5 ±N is almost, but not quite, aligned with S and so too is the segment P–Pn.
Say, for successive segments, P–Pp rotates clockwise a certain angle ψ. Necessarily, the perpendicular ±T also rotates at ψ.
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.
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.
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.
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.
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
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.
About this: I’m actually a bit to blame for agreeing to implement this feature.
in practice, if you want to have a random value in an open range ]a,b[, it’s better (and faster) to write for instance u(a+eps,b-eps) with eps=1e-5 rather than u(a,b,0,0).
At the end, what the algo does is indeed add/subtract an epsilon to the specified bounds, but it does this every time you call the function, while the bounds can often be precalculated as constant values.
So in practice it’s not that interesting to use.
I prefer not to add these options to the new functions rand() then.
Concerning the srand() problem. I will see what I can do, but in any case, remind that for large vectors, the filling with random values will be done in parallel, and in this case, there are no ways to ensure the ordering of the filling is always the same.
So, in the multi-threaded case, srand() is practically useless.
Regarding epsilon value. Wouldn’t it be nice to implement C++ nextafter, and the backward version of that? There’s also use in case of modulo operation here, so you can preserve the value to modulo by.
So, my advice here is not to apply a patch that will make srand() works only for small vectors but not for large ones. There is clearly an undefined behavior here, and it’s the kind of nightmare a developer don’t want to have to deal with.
Searching for ‘0x’ yields no result on Math Expression documentation. It would be nice if there was some points about hexadecimal literal, and binary literal there.
