Capture RGB Values

Good idea Michel

This is quite a good little learning experience.
I have 1 question:

Although the code used is - rgbs = p.RGBSurface, the TextField seems to display a Hexadecimal Triplet Code, with alpha values. Is there a way to modify the line of code above (so it displays the RGB value, and without transparency) - or is that not possible - In which case I need to convert the hex to rob?

Thanks.

[quote=123932:@Richard Summers]
Although the code used is - rgbs = p.RGBSurface, the TextField seems to display a Hexadecimal Triplet Code, with alpha values. Is there a way to modify the line of code above (so it displays the RGB value, and without transparency) - or is that not possible - In which case I need to convert the hex to rob?[/quote]

RGB(x,y,z) and RGBSurface are two different things. The first is a way to express a color, the second is an object representing a picture. Search RGBSurface in the LR to see all the possibilities it offers.

The RGB way of expressing a color is best explained at http://documentation.xojo.com/index.php/Color

You can display a color value the RGB way by using its Red, Green and Blue properties. `Color.Blue` for instance gives you the numeric value of the last term.

Thanks Michel.
I already often convert hex to RGB etc, I was just curious to know if it was possible to do it automatically

[quote=123933:@Michel Bujardet]RGB(x,y,z) and RGBSurface are two different things. The first is a way to express a color, the second is an object representing a picture. Search RGBSurface in the LR to see all the possibilities it offers.

The RGB way of expressing a color is best explained at http://documentation.xojo.com/index.php/Color

You can display a color value the RGB way by using its Red, Green and Blue properties. `Color.Blue` for instance gives you the numeric value of the last term.[/quote]

I had already done this procedure but the value does not match the captured values converting HEX to RGB is different for some reason I am unaware, I opened the image in Photoshop and are different for my project and this precision is required, am I doing something wrong?

My code is:

[code]dim c as color = rgbs.Pixel(system.Mousex, system.mousey)
'Break //c is the color under the mouse

theColor = c

dim g as Color

g=RGB(c.Red, c.Green, c.Blue)

TextField2.Text=str(c.Red)+str(c.Green)+str(c.Blue)[/code]

You code is correct. You should add the Alpha Channel component, such as

``g=RGB(c.Red, c.Green, c.Blue,c.Alpha)``

But when you say “the value does not match”, what do you mean ? The conversion is pretty simple. RGB(255,255,255,0) = &hFFFFFF00. Each couple of digits is in hex the same as the value in RGB. FF = 255, for instance.

Or is it that the color you get from capturing the screen is different than the color in the original picture ? If that is the case, as I pointed in another thread not too long ago, the rendition of the screen on a computer is different than the picture you display, due to the display profile. In tests, a picture filled with RGB(255,255,0) rendered as RGB(253,253,10) with the Generic RGB Profile on Macintosh and something like RGB(255,250,0) on PC.

This is for Richard, who posted a question a couple minutes ago, and withdrew it before I could post :

``` dim s as string = "AD2C4B" dim c as color = RGB(val("&h"+Mid(s,1,2)),val("&h"+Mid(s,3,2)),val("&h"+Mid(s,5,2))) MsgBox "RGB("+str(c.red)+","+str(c.Green)+","+str(c.Blue)+")"```

Michel - I realised that my code was working perfectly - the problem was with my hexadecimal value
All fixed now.

Paulo, you need to be aware however, that the examples kindly provided here, will overwrite anything the user already had in his clipboard.

It would therefore be advisable to warn the user beforehand

I am still interested in finding a way to display a colour value (from anywhere on the screen) in a text field - without actually making a screenshot which is copied to the clipboard. It should be possible, as the DigitalColor Meter which is part of the OS does this.

It would be much more user-friendly that way

Several years ago Joe Ranieri provided the framework to replace system.pixel using core graphics. You can find it in the following feedback report attachment screenshot.rbp.zip:

It looks like it needs to be updated for retina displays but I’m sure someone here can jump in here .

Jim Shaffer

[quote=124002:@Richard Summers]I am still interested in finding a way to display a colour value (from anywhere on the screen) in a text field - without actually making a screenshot which is copied to the clipboard. It should be possible, as the DigitalColor Meter which is part of the OS does this.

It would be much more user-friendly that way :)[/quote]

I started from Jason’s code which uses the clipboard, and have used that in the past. But now in one of my apps where I need to pick from the screen out of my app area, I use ScreenshotRectMBS which effectively can pick a color anywhere on the screen.

The alternative is to use screencapture to create a file, which is then loaded in the program. That preserves the clipboard. The buffer image can be created in the temporary folder, so it remains transparent to the user. And much friendlier

For the rest, the projects posted so far will work fine with that method.

Calls to the system are probably fine as well, it is just a matter of finding the proper declare. Maybe Joe Ranieri’s project Jim Shaffer referred to is a good way. I downloaded it to have a look.

In general, I tend to use the simplest approach as possible that provides a reliable result. Screencapture is a documented way of getting the screen image that has all chances to remain valid for a long time, and it will not need tweaking for Retina or other screen technology, unlike system calls which become deprecated. But of course there are many roads to the same destination. That is the fun part of programming.

Here is the Screencolors project using a buffer file for screencapture, so it does not modify the user clipboard.

Screencolors-with-file.xojo_binary_project

Right click on the link and select “Save as”.

Michel
thank you very much - that is much more user-friendly!

Very much appreciated - thank you for sharing that with the community

Hi Michael,

I work with programming just over 3 years but my specialty is Prepress and Calibration and Color Management, why this I take good care of these details, what is happening is that for example:

Captured Color on Program:___________& h00879E3F
RGB color Specified in the Program:RGB (135, 158, 63)
Color by Photoshop CS6 info:
RGB (138, 194, 76)

And for my esperiência say that the conversion of CS6 is perfect, so do not know what can be done and that the values ??do not Match.

[quote=124036:@Paulo Vargas]Hi Michael,

I work with programming just over 3 years but my specialty is Prepress and Calibration and Color Management, why this I take good care of these details, what is happening is that for example:

Captured Color on Program:___________& h00879E3F
RGB color Specified in the Program:RGB (135, 158, 63)
Color by Photoshop CS6 info:
RGB (138, 194, 76)

And for my esperiência say that the conversion of CS6 is perfect, so do not know what can be done and that the values ??do not Match.[/quote]

That is exactly the problem I was referring to. I will try to explain what is going on, or so as I understand it.

What CS6 gives you is the exact color value as it is coded inside the original image.

in a way, you can think of the screen as the equivalent of a hi-fi system. The original music comes from the CD, then it goes through the amplifier which distorts it with the equalizer, and finally it is played through the speakers which depending on their size and quality, will render it differently.

You original picture is interpreted several times by imager subroutines, just the same as the sound is processed in a hi-fi system. First, the program you are loading the file into will take the information from Jpeg, png, tiff or something else, parse it, and create a picture in memory. Then to show that on screen, a second imager will take the information from the picture in memory, and send to the screen the electronic signals necessary to show it in a human recognizable form.

At every stage, most programs will do all they can to preserve the original information. But there is the equivalent of the sound equalizer for colors inside your Mac, that will offer not the original information, but a rendition meant to improve the perceived colors. It is the screen Display Profile. To improve the human perception of colors, some are shown slightly brighter than others. In film, some are meant for 5500 degrees Kelvin, some others for 3200 degrees Kelvin. You may think of the screen as doing something like that. To make matters worse, some programs such as Preview have their own display profile and add even more distortion.

When we pick a color on the screen, we pick the color as rendered by the system. Meaning it is distorted to have a better physiological response. Just like if you tried to record by placing the mike next to the speaker.

To have the exact color would require creating a special Display Profile with no distortion, or to load the picture directly in the program, so the color is read from the original instead of the screen capture.

It may be possible to compensate the screen rendition, but that will require calibration for each Display Profile, and some programs like Preview. For instance, in your example of
RGB color Specified in the Program:RGB (135, 158, 63)
Color by Photoshop CS6 info:
____ RGB (138, 194, 76)
The program could calculate the percentage added for each color and compensate before displaying the value.
Red * 0.978
Green * 0.8144
Blue * 0.8289
Hopefully the response curve is linear and the same percentage can be applied for low and high values, but I suspect a gamma coefficient to be applied.

If what you want to is being able to measure very precisely the colors of a picture, better load it into the program.

Last minute : loading into the program will not do. I just tried to read the colors from a calibrated original, and I do not get the precise values I had input. Meaning Xojo interpretation of the color information upon loading is not precise.

Worse yet, whatever happens inside Xojo when it parses the color information is not constant.

I set precise portions of an image with the following values. Next to it are what Xojo does with it. And the same picture saved to file has the problem as well :

``````Red       255,0,0        251,0,7
Green     0,255,0        35,255,6
Blue      0,0,255        0,0,255
Cyan      0,255,255      32,255,255
Yellow    255,255,0      255,255,10
Magenta   255,0,255      251,0,255``````

Because the results for a particular color value are perfectly incoherent, it is impossible to apply any sort of compensation ratio over any color. For instance Blue 0 becomes 7 in Red, 6 in Green, and 10 in yellow. If Xojo response curve was coherent, the value of Blue when zero in the original should remain constant, whether that be 7,6 or 10. Not variable according to the mix, as here. I see no way to obtain the exact value in the original from such a soup.

It looks as if Xojo internal color representation is using something other than RGB that creates these disparities. Could some HSV be playing a role as well ?

Conclusion for the time being, Photoshop or equivalent such as Paint. Net in Windows, is the only way to get the exact color value.

I don’t like it when something does not work. After discovering that Xojo image loading does not reflect colors correctly, I started wondering if that was Xojo or the framework doing things. I looked in MacOSLib for a declare to load a picture file directly through the system, but could not find one. MacOSLib being extremely poorly documented, it may very well be there, but I did not find it.

Finally, I discovered the MBS JPEG plugin was doing just that. In a few minutes, I modified my program to load a jpg picture prepared in Photoshop with calibrated colors. The results are far better than the Xojo method. Yet, they are not perfectly exact :

``` Red 255,0,0 254,0,0 Green 0,255,0 0,255,1 Blue 0,0,255 0,0,254 Cyan 0,255,255 1,255,255 Yellow 255,255,0 255,255,1 Magenta 255,0,255 255,0,255```

To be fair, a difference of plus or minus one is not a lot. But yet, as with Xojo, no way to compensate, since for the very same Blue channel, it is sometimes 0, sometimes 1 with no apparent reason, and it shows as 254 in Blue, where it should be pretty easy to load 255.

Conclusion : loading precise colors from pictures in Xojo does not seem possible.

[quote=124085:@Michel Bujardet]That is exactly the problem I was referring to. I will try to explain what is going on, or so as I understand it.

What CS6 gives you is the exact color value as it is coded inside the original image.

in a way, you can think of the screen as the equivalent of a hi-fi system. The original music comes from the CD, then it goes through the amplifier which distorts it with the equalizer, and finally it is played through the speakers which depending on their size and quality, will render it differently.

You original picture is interpreted several times by imager subroutines, just the same as the sound is processed in a hi-fi system. First, the program you are loading the file into will take the information from Jpeg, png, tiff or something else, parse it, and create a picture in memory. Then to show that on screen, a second imager will take the information from the picture in memory, and send to the screen the electronic signals necessary to show it in a human recognizable form.

At every stage, most programs will do all they can to preserve the original information. But there is the equivalent of the sound equalizer for colors inside your Mac, that will offer not the original information, but a rendition meant to improve the perceived colors. It is the screen Display Profile. To improve the human perception of colors, some are shown slightly brighter than others. In film, some are meant for 5500 degrees Kelvin, some others for 3200 degrees Kelvin. You may think of the screen as doing something like that. To make matters worse, some programs such as Preview have their own display profile and add even more distortion.

When we pick a color on the screen, we pick the color as rendered by the system. Meaning it is distorted to have a better physiological response. Just like if you tried to record by placing the mike next to the speaker.

To have the exact color would require creating a special Display Profile with no distortion, or to load the picture directly in the program, so the color is read from the original instead of the screen capture.

It may be possible to compensate the screen rendition, but that will require calibration for each Display Profile, and some programs like Preview. For instance, in your example of
RGB color Specified in the Program:RGB (135, 158, 63)
Color by Photoshop CS6 info:
____ RGB (138, 194, 76)
The program could calculate the percentage added for each color and compensate before displaying the value.
Red * 0.978
Green * 0.8144
Blue * 0.8289
Hopefully the response curve is linear and the same percentage can be applied for low and high values, but I suspect a gamma coefficient to be applied.

If what you want to is being able to measure very precisely the colors of a picture, better load it into the program.[/quote]

Bah, Ultra Super Mega Ninja your explanation hehehehehehehe

You did not need to have lost so much time with it my friend.

Tanks a lot Michel !