Hello everyone.

I've been using G'MIC for a while now but as I want to work on something more complex now, I thought I'd better join the group.

What I am really looking for is some more info on the math expression evaluator.

Is there a specific forum I should be posting in for this kind of stuff?

At the moment, I'm only looking for something fairly simple, which I might as well post here.

If the following is run:

$ gmic 100,100,1,3 -fill <some functions here>

does the "some functions here" get run 10,000 times (100x100) or 40,000 times (100x100x4)? Is this per pixel or per channel of each pixel?

Simple stuff huh...

Souphead...

Souphead
I'm not an expert on the G'MIC commands, but you're in the right spot for a reply from someone who is. My suggestion is have a look at the G'MIC tutorial, Command Decorations.

Thanks for the quick response Odinbc. That section defines how the pipelines work but not how the math parser works. From the online doc, I am leaning toward the 40,000 answer as that fits in with the general way that G'MIC deals with arrays. In this specific case I would prefer to work at the pixel level rather than the channel of the pixel level.

Being able to choose which level I work at would be even better (hint, hint), though I can see that that could be quite a bit of work to implement.

Souphead.

Welcome to Gimp Chat. I am sure David will be along shortly to answer all your G'MIC questions

Hello Souphead,
in your case, the function is evaluated 3x100x100 = 30,000 times, for each value composing the image.
Maybe you can say a bit more about what you want to achieve ? I'd be glad to help before starting my holidays.
I admit we miss some documentation about the math expression evaluator, so it's not really easy to know how to start (particularly because you can do a lot of different things with it!).

Cheers,

David.

30,000 times? Can you explain why it's not 40,000 times. So if i had a alpha channel I would have to start with 100,100,1,4 before the fill command?

As to what I'm doing, I'm looking at converting something from MATHMAP which works at the pixel level. Since I'm looking to move pixels here rather than work with the channels of the pixels, the math I need t do will be exactly the same for each pixel channel and will take four times longer than it really needs.

I suppose I can still continue though I now have some concerns how long my process will take. I can certainly see some benefits of working at the pixel channel level though I can also so some benefits of being able to work at the pixel level too.

Any other hints at how you intend to extend the math evaluator would be nice if you are willing to talk about it now. The recent addition of the init() function implies to me that you want to take this at least somewhat in a MATHMAP like direction.

Souphead

Yes exactly, when you write 100,100,1,3, it means you are creating a new image with 3 channels (which probably means a 'RGB color image' in your case).
If you want an alpha channel, then you need to define a 4-channels image instead (so, 100,100,1,4).


If you just want to do some warping operations, it could be easier to define first a warping field (a 2-channel image in your case) that says for each pixel (x,y) of your image from where the value must be taken. Then use the command '-warp' afterwards. Something like :



I don't really know how the Mathmap expressions are working, so I can't tell much about the differences or similarities

Thanks for another quick reply.

I guess warp is an option and allows me to cut the processing down. I guess I'll have to look at the MATHMAP code and see if it can work that way. Much to do there. Hopefully the wife will give me the time to look at this over Christmas

As to how MATHMAP works, it really isn't so different from your math evaluator, they really aren't that different. The real big difference is that it works at the pixel level and handles RGBA channels together by using their tuple variables which is really just a 4x1 array of values. I can see that your math evaluator can see the other channels via i0 thru i3 variables but only one of them can be changed at a time.

I can see that you are not trying to build something MATHMAP-like, though that is actually what you are sort-of heading toward.

Anyway, let me look again at what I have and see if a warping field gives me what I want. There's about 100 lines of code, so I'm not looking at a simple warp here.

Thanks again,
Souphead.

Thanks for the clarification.
In fact, it is possible loop over (x,y) and set the (R,G,B) pixels at the same time, using a small trick:
You apply the '-fill' command, only one one of the channel (let say R for instance), and you use the pixel access operator to fill the G and B values at the same time. For instance, you can define this G'MIC command file :

and apply the new command '-foo' on your image like this :


That's the same trick if you have an alpha channel as well.
Images in G'MIC may have more than 4 channels, that's one reason why you don't want to be limited to a loop over (x,y) only. Sometimes you want to loop ober the 'c' dimension too (channels).

That's useful and sneaky! I guess the documentation doesn't say that the values of iN can be directly changed, though from your example they clearly can. The only other thing I have to deal with is handling complex numbers but I guess I can handle them in the long winded way.

Thanks for your time and thoughts,

Souphead.