Mmmm so I guess I have to rearrange them as a square to make it more readable:
($1,$4,$7^\
$2,$5,$8^\
$3,$6,$9)
Mmmm so I guess I have to rearrange them as a square to make it more readable:
($1,$4,$7^\
$2,$5,$8^\
$3,$6,$9)
At some point in time, try to absorb Input - 4. Prescribed Values if you have not already done so. This section covers inputting an image by way of a stream of numeric values.
Various non-numeric delimiters partition streams into column (,
), row (;
), slice (/
) and channel (^
) regions.
In this stream that you have written:
(50;0;0^50;25;0^100;100;0)
It probably is not obvious, but the absence of delimiters indicates as much about the organization of an image as their presence. There are no slashes or commas. So, at the outset, the image has at most one column and at most one slice. For if were otherwise, the presence of commas would delimit the stream into two or more columns, and the presence of slashes would delimit the stream into two or more slices.
Semicolons and carets are present, so the image is delimited into more than one row; rows are what semicolons delimit; and more than one channel; channels are what carets delimit. Taking into account the presence and absence of delimiters, this particular stream first fills row 0, 1, and 2 of column 0 (and there can only be one column). As these data precede the first caret, the flow necessarily is into channel 0 (we think of this channel as “red”; G’MIC could not care less). That first caret delimits channel 0 from channel 1; data following it flows into row 0, 1, and 2 of channel 1 (“green”). The second and final caret separates channel 1 from channel 2; data following it flows into row 0, 1 and 2 of channel 2 ("blue). This is how a stream flows into a 1,3,1,3 image. Homework: how would the flow go if all of the semicolons change to commas (Hint: since there are no semicolons, the flow would go into at most one row, but more than one columns)?
The color of the pixel in row 0 necessarily must be [50,50,100]
because these three values are each the first items in each of the three channel blocks. and these first items successively flow into channel 0 - the block before the first caret, channel 1 - the block before the second caret, and finally channel 2 - the trailing block. Similarly, the three values that are the second items in each of the three channel blocks compose [0,25,100]
, the pixel in row 1. What is the pixel in row 2 (Can it be any blacker)?
Make various small images and observe how G’MIC prints them out in the console log.
gosgood@lydia ~ $ gmic run 'v 2 (50;0;0^50;25;0^100;100;0)'
[gmic]./ Start G'MIC interpreter (v.3.3.6).
[gmic]./run/__run/ Set verbosity level to 2.
[gmic]./run/__run/ Input image at position 0, with values (50;0;0^50;25;0^100;100;0) (1 image 1x3x1x3).
[gmic]./ Display image [0] = '(50;0;0^50;25;0^100;100;0)'.
[0] = '(50;0;0^50;25;0^100;100;0)':
size = (1,3,1,3) [36 b of float32].
data = (50;0;0^50;25;0^100;100;0).
min = 0, max = 100, mean = 36.1111, std = 41.6667, coords_min = (0,1,0,0), coords_max = (0,0,0,2).
Ah thanks, i’ve been looking for this page for hours today…
Couldn’t find the link, all input
links i found in the tutorials point to the reference page, which is less detailed. I knew this page existed, seen it last year lol. Could you tell me which page has the link? It’s hidden too well.
Anyway, i’ve finally noticed how the values were ordered in between the (), wasn’t sure if it was supposed to be this way, or if i did it wrong ( without your link, hard to figure this out). I’m used to write RGB colors as 255,0,0 for red, etc. , so you can guess how it can confuse me to split colors like you described.
In the end i wrote it this way for the “forest” gradient:
(2;2;2;2;0\
^0;0;1;2;0\
^0;0;0;2;0)
More readability for me this way, i don’t have to “jump” over 2 values to guess a color.
I had to use very dark colors though, since with all the effects it would quickly become very bright.
3,1,1,3. I wanted a vertical image though, hence the use of ;
But i will allow a gradient along x axis too.
0,0,0. I wish it could be “more blacker” but anyway no screen could display it.
Thanks a lot.
Have fun!
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.
gmic -h input
does rather more directly.Have fun!
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.
Now that i have added tree seeds in underwoods…
Probably because i 'm using image width as a repeat loop, and the preview image width is different. Looking for a solution…
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
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.