# How to access RGB values for calculation?

#1

Hi,

I’m doing my first steps in Gmic programming, and I want to use the R, G and B values of a photo for some basic math, like R-(B+G)/2 and then save the result as a new layer. Now I was able to actually do that last formula using the -split command and then blending the RGB channels accordingly. But this seems awkward and very unpractical for doing more calculations.
I have searched the reference and some tutorials but couldn’t find how to acces the values directly. Can somebody help me here?
Thanks
(BTW, I’m on Win10 using Gmic in Gimp)

#2

It depends what you mean by directly. You can avoid having to split by use of “-shared” buffers, but use with caution

If you want to manipulate per pixel (x,y) then check out the math parser combined with the -fill command. Note that’s generally slower than dealing with whole buffers, depending on the operation of course.

#3

I have a photo in RGB and I want to take each pixels R, G and B value, do the math and save the result in a new image (same size) at the same pixel position. So with directly I mean I want to just get the RGB values at every position (x,y) of the image. I’ve been using RGB channels and blending modes up to now, but it is not very comfortable.

Thanks, found the pixel manipulation stuff in the mathematical expression list!

(David Tschumperlé) #4

@garagecoder is right: when you want to manipulate image pixels directly instead of creating a pipeline, using the math parser could make things easier. In your case, I guess this should work :

``````\$ gmic input.jpg -fill "R-(B+G)/2"
``````

and probably better, if you want a 1-channel image instead as the result:

``````\$ gmic input.jpg 100%,100%,1,1,"R#0-(B#0+G#0)/2"
``````

G’MIC has been primarily designed to create pipelines of image processing operators, and I’ve quickly found that this was not always a practical way of thinking, for a custom-made pixelwise operator. So that’s why I’ve started implementing the math parser a few years ago, and I can say that it reached a state where it is extremely powerful I personally use it more and more in my G’MIC commands !

#5

Thanks @David_Tschumperle,

This is what I was looking for and @garagecoder pointed me in the right direction. Yes the math parser seems extremely powerful from what I’ve seen so far. So I’m looking forward to what my experiments will lead to.

(David Tschumperlé) #6

Just a note : I know that @grosgood has started a complete documentation about the use of the G’MIC math parser a few months ago. I wish I have kept the draft he sent me once, but unfortunately I haven’t.
This was a very good piece of documentation (as always with Garry). Unfortunately I got no news from him for a while, all I can hope is he is doing well.

#7

Glad you found what you needed, I had to leave for work in a hurry this morning so the reply was shorter than I wanted

The pipeline method seemed utterly bizarre when I started using G’MIC, many others treat operations as per pixel sets of commands and that’s hard to unlearn. It’s really worth trying though, it forces you to realise many equivalent methods that turn out faster or simpler.

I also really hope Garry is doing OK!

#8

It was perfectly fine reply and pointed me to exactly what I was searching.
I will also be using the pipeline method. It is just for this that I needed working on pixels.

(Garry R. Osgood) #9

Thank you, David & Andy. I am fine. 2016 and the first quarter of 2017 were busy times for me. I’m coming up for air now (I think).

Pertinent to this thread, David & I had correspondence this morning/yesterday evening about the -fill command, which will mirror at gmic.eu in the wholeness of time (say, a day or two). Since it is a command that furnishes an entry point to math expressions, a good bit of the document David spoke about finds it way into that. It is still not Math Expressions 101; it is more of a Whitman sampler of toys, but with a little study it will serve as an informal introduction until something better comes along.

To amplify on McCap’s original post, I’ve bought along my \$0.02 USD. With the New And Improved Math Parser, one may write an expression to return either scalar pixel components or the entire pixel as a vector, which can have consequences on how your color computations appear. To follow along, you may want to augment your basic stock gmic installation with an update:

`\$ gmic -update`

so that you get a bunch of toys, including -colorwheel, a utility that paints a colorwheel. If you have a stock installation, and have never invoked an -update, then you won’t have -colorwheel or a few other nice things. So do it. Life will be so much better.

Assuming you’ve done such a thing and have such a toy, then running:
`\$ gmic -colorwheel 512 -fill 'R’`
produces a gray-scale-like image where the red wedge of the colorwheel renders in shades of gray. But if you look at the banner of the display window, gmic will report that you have a three channel image. Why is that?

What this script does is return a scalar, the current contents of the red component of the visited pixel. Since the math expression parser notices that the expression returns a scalar, it will duly run this expression for every pixel component in the image - that is it iterates over the red, green, and blue channels and, for each pixel component, transcribes the value of the red component into the visited component. In effect, this expression transcribes the red channel into the red, green and blue channels, iterating over the image in three passes.

Now let’s write a slightly different math expression.

`\$ gmic -colorwheel 512 -fill ‘[R,0,0]’`

This expression returns a vector, so constructed by the square brackets. This change alters how iteration occurs. The math expression parser iterates over over the entire image just once, and at each column-row location, x,y, writes the entire three channel pixel in one go. So in this variation, you fill the colorwheel image with a bunch of pixel vectors that transcribe only the red channel to the red channel, the G and B channels are set to zero. The colorwheel appears not as gray, but as blood red.

Of course, this template can be extended to any one of a bazillion color remappings, such as:

`\$ gmic -colorwheel 512 -fill ‘[0.5R+0.2B,B+G/2,R-B]’`

These are all in-place approaches where the math parser over-writes pixels of the colorwheel. David and Andy take a non-destructive transcription approach by creating a target image and then writing a transcription expression as a part of the image creation process. The # suffix enables a math expression in the target image to access channels in the source image, which can be any image on G’MIC’s list.

#10

Welcome back! I’ve had the same problem this year, all my “gmic time” gets eaten by other things these days

The math parser had so many improvements I feel quite out of touch with it. Any guides will be most appreciated! The tutorials on tensors were a great help to me.

(David Tschumperlé) #11

@grosgood, I had some time today to update the tutorial pages on the G’MIC server. You should be able to find the latest page on `-fill` here. Thanks again

(Garry R. Osgood) #12

Hello David,

All alive and well at the -fill command, gmic.eu, with side
commentary ranging from Thangka paint pots to the Japanese Ikebana
school of floral arrangement, not to mention those Newton-Raphson weeds.
No help for you if you find such in your front yard, however. G’MIC is a
wonderful tool, but for some things there is no substitute for a good
lawn care specialist.

More to come. The topic Generating mid-tone masks_ promises a nice,
simple math expression example, for a variety window functions defined
on the interval [0,…,1]. It is still early Sunday morning here on the
Eastern seaboard of North America. The Canadians have granted us a
lovely, dry, temperate air mass, there is nothing on my day calendar and
I am in the mood to write.

Take care,

Garry