The Big Bad G'MIC Thread of Silly Questions

image

Have fun!

1 Like

Lol. Color me depressed.
I was looking in the scripting tutorial…

Not sure that I understand. The cited URL in the help text is among those pages making up the scripting tutorial, because “tutorial” is a part of the URL. One of these days I shall have to learn French, so that I can confuse you in your native language, rather than resorting to an Americanized form of English with Brooklynese variants…

Perhaps you want the pure web-browser path, for those adverse to using command shells.

  1. From the G’MIC home page (gmic.eu), choose “Scripting Tutorial”, second item down, with the “?” icon.
  2. That brings one to Start Here, the home page (“root”) of Tutorial Land, with the fake CRT G’MIC prompt animation.
  3. Scroll all the way down to the bottom, where the Tutorial Land header resides (“If all else fails, read the manuals.”).
  4. From that table, click on Command Guide, 8th entry down (“Tutorials written around not nearly enough commands.”).
  5. That brings one to Command Tutorials, where there are vast tables of G’MIC commands listed, but somewhat out-of-date, and mostly back-pointing to Technical Reference URL’s (Availability=Ref.).
  6. However, some antediluvian pages are in the radioactive Old Tutorial space (Availability<2.0), but a very few are almost, nearly, kind of, current (Availability>2.0). Scroll down and find input with an Availability ≈ 2.9x. Ah! That’s as good as it gets!
  7. That link brings you to the page that gmic -h input does rather more directly.
  8. One of these days, I’ll complete this section. Possibly after I learn French.

Have fun!

1 Like

I can’t really ping you at github, so I mentioned you on this feature idea - (Feature Idea) Literals to affect inputs · Issue #42 · GreycLab/gmic · GitHub . Did not want to PM you just for a small message.

Lol ok. Well I struggled because I lost my way to the input tutorial page. I was very tired it seems, considering it was right under my nose all this time. But it was because I usually use sample or an existing image to work on, and never create images from scratch, unless it’s white or black.

A post was merged into an existing topic: Fun with prawnsushi

Now that i have added tree seeds in underwoods

  • It works for the preview, moving the light doesn’t change trees shape or position.
  • It works for the output, but the output doesn’t look anything like the preview.

Probably because i 'm using image width as a repeat loop, and the preview image width is different. Looking for a solution…

1 Like

Maybe use full preview?

From stdlib:

#    '#@gui Command name : command, preview_command (zoom_factor)[*|+] [: default_input_mode]
#    '#@gui : parameter1 = typedef(arguments1...), parameter2 = typedef(arguments2...)'
#    '#@gui : parameter3 = typedef(arguments3...),
#
#   where :
#
#      'command' is the G'MIC command name called to process the image.
#
#      'preview_command' is the G'MIC command name called to process the preview.
#
#           Note that you can optionally specify a float-valued factor>=0 between parentheses at the end of
#           the 'preview_command' to force the default zoom factor used by the preview for this filter.
#           Use (0) for a 1:1 preview, (1) for previewing the whole image, (2) for 1/2 image and so on...
#           You can put an additional '+' sign after the parenthesis to specify the rendered preview
#           is still accurate for different zoom factors. Use '*' instead to tell the plug-in that the preview filter
#           must get the entire image rather than a thumbnail.

I’ve already tried, it’s extremely slow for a preview.

I also changed the loop, now it’s just a number of trees, but it’s the same thing.

Hi,

i’m looking to sort images in my list.
How can i move the last nth images every nth image so i get something like this:

[A] [B] [C] [D] [E] [F] [G] [H] [I] [INT] [INT] [INT]
becomes:
[A] [B] [C] [INT] [D] [E] [F] [INT] [G] [H] [I] [INT]

Note that the last images are part of the same named selection, so selecting [INT] will select them all.

I’ve used selections like this in the past [0--1:3] but it seems i need to reverse the effect? Like mv[-3--1] 0--4:3 or mv[INT] 0--4:3 or something. Or maybe i just fail to see the syntax. Or should i use sort_list but on which criteria?

If I remember correctly, move has a quirk moving the last item. I made a command to deal with that, but I do not know if it still works after so many G’MIC updates. (Just a quick response, so may not be completely helpful.)

Yes, you need to ‘revert’ the effect, as you say. And the bad news is that you cannot do that ine one go, but use an explicit loop to do this. Something as:

foo :
  1x12 => A,B,C,D,E,F,G,H,I,INT,INT,INT
  repeat 3 { mv[-{1+$<}] {4*$>+3} }

Best i can do for now is this :


    INT:=round(($!-1)/3)
    repeat $INT {
     place:=$INT*($>+1)
     if $place<=$! [BG] =>. INT mv. $place fi
    }

That’s fine. But it looks quite complex. i don’t know it move or sort_list could be modified to allow a syntax like sort_list -5,-1,%3 or something like that? Where the command would be applied to the whole list minus the range from -5–1 and would place 1 image from -5–1 (the last one i guess) every 3 images? Maybe i’m just overcomplicating things lol

Or something that would interleave 2 images selections/list with a given offset?
Just throwing ideas in the air cause i know i can’t do it :stuck_out_tongue:

Ah forget it, i just give up on this, the more i do it the worse it gets.

David’s solution seems to work. I modified it so you can do steps:

foo:
  1x12 => A,B,C,D,E,F,G,H,I,INT,INT,INT
  repeat 3 { mv[-{1+$<}] {($1+1)*$>+$1} }

And my test:

C:\Windows\System32>gmic foo 3 echo ${lof\ n} rm
[gmic]./ Start G'MIC interpreter (v.3.3.6).
A,B,C,INT,D,E,F,INT,G,H,I,INT
[gmic]./ Remove images [0,1,2,(...),9,10,11] (0 images left).
[gmic]./ End G'MIC interpreter.

lof returns a list of specified features along images. n is name, so you can see names here.

Your code can use this:

foo: repeat $1 { mv[-{1+$<}] {($2+1)*$>+$2} } # $1 = number of times. $2 = step size.

Also, I would look into different solution. I almost never need to use move in arbitrary order. Actually, literally never now that I taken a check at reptorian.gmic.

Also, there could if break rule in case there’s issues or other things.

Wanted to make underwoods faster by generating everything first, so i had to rewrite everything and in a different order, and then use ap. That was working but then i got stuck on this damn list part. Sorting was kinda random, and sometimes i would get ‘out of range’ errors. Just gave up and deleted everything. Thanks anyway.

Well, that happens. Don’t worry though, sometimes working ideas do come later. Some of my changes involved ideas that came after a year in fact. For example, the 11.6x speedup to Lavander Binary Map were the results of two different ideas, and these were replacing vector with binary operation mathematics and lookup table, and I didn’t think of those nor could back then.

I am sure that is what @prawnsushi meant by

It takes a lot of discipline to be familiar enough with G’MIC to be able to do interesting things, not to mention the coding and mathematics chops to make algorithms and optimization work. I only have imagination working for me. :blush:

If you come to a point where you need to manage a large number of images simultaneously in your list, then I strongly advise you to start naming your images with variable names (command name), and refer to them by their name rather than by their position in the list.
By doing this, you can often completely ignore the position of each image in the list when coding, making it much easier to find your way around.

It’s something I do personally (and more and more often, in fact), for example whenever I have more than 4 or 5 images to manage simultaneously.