Reading pixels?

[Intio]

Does anyone have documentation or examples for the thinBasic command (getPixel?) which reads through a BMP and can store the RGB value of each pixel into an array?

I don't need it for any special effects, which I understand is the most common use for this, but I do need to fill a 2D matrix with values that depend on (though are not the same as) the pixel values of a BMP.

Any help? Thanks.

Intio

[Michael Clease]

Are you just working with files because thats really easy for what you want.


Here is something I was playing with a while back.

[Intio]

Thanks Abraxas.

That was essentially what I asked for, but I think I should have phrased my question differently. I'd rather load a texture and display it off-screen and then read the pixels directly off the texture.

I got your code working, but it seems a bit much for what I want to do (fill a static 2D grid with values, and the start position of a few moveable things - all from the colours of a small BMP), since I just need the RGB values rather that having to negotiate and keep track of bytes and increments so that I do not read off the wrong data.

I saw the '%XPRINT_GetPixel' statement in the help files, but I am not sure how to implement it (I have been using several different languages recently, and find it increasingly difficult keeping track of what commands and syntax are resident for each language! I'll be sticking with thinBasic for now though ;) ), would this be a simpler way of using a single command to read pixel info.?

Thanks for any help, and thanks for the code sample - it may come in useful for other things.

[Petr Schreiber]

Hi Intio,

you did not mention "texture" in your original post, then the Abraxas reply seemed pretty ok to me.

If you need to go 3D, then use TBGL module to load BMP file using TBGL_LoadTexture, then setup 2D projection using TBGL_RenderMatrix2D, and then pick the RGB value at specified location using TBGL_GetPixelInfo.

Well, I attached working code for you :)


Petr

P.S. But the file processing way is cleaner, I am with Abraxas on this.

[Intio]

You're right, I didn't make my request clear in the original post - though Abraxas has provided me with a very useful code snippet that I will be sure to study in future.

I'll give your example a try when I have some free time, thanks!

[Intio]

Everything is working now as it should, thanks Abraxas and Petr!

P.S. One thing I did notice, when I use the GetPixelInfo command on one graphics chipset I get a slightly innacurate result; the Red and Blue values are 2 or 3 points below what they should be and the Green value is 2 or 3 points higher that what it should be.

When I say "what it should be", I of course mean the value that I set in the code itself. It is never wildly innacurate, only by a few points. I tried changing BYTE variables to LONG but it made no difference. Changing the colour set in the code doesn't make it accurate - it just means the pixel info is still a few points off. This happens even if I read pixels from the uniform background colour.

And this only happens on some chipsets (integrated Intel 9**GM/GL family), whilst others within the same chipset family will display perfectly accurate info.

It's nothing that will affect my code (I always intended to include some buffer zone when I read pixel values, so that they do not have to be the exact value expected, but can be off by a few points), it just intrigues me.

Anyhoo.. thanks for the help Petr and Abraxas. ;D

[Michael Clease]

Intel seem to have real problems with their drivers and/or hardware.

glad everything is ok.

[ISAWHIM]

When you read from the screen, you are reading the display color. (Graphic settings can alter those, as well as video-translation. Some cards use the BMP colors as a suggestion, and display the closest color from a list of compressed colors.)

BMP is (256, 256, 256) RGB... However, certain colors are used by the GUI, and are reserved colors for layers and overlays. (VIDEO uses BLUE), for example... that is one color that will never display on the screen in an image. It is used to tell the DRIVERS where to draw the "WINDOW" or "OVERLAY".

Older computers also have designated, "Windows colors". Those never appear in images. The colors are shortened to a close-color. (I think windows only has about 64 colors which it wipes from the available colors.)

That was also a big issue with Web-Browsers, back in the day. They translated HEX into a "Close" color... Thus... Netscape and MSIE and OPERA, all showed a 256 BMP or GIF or HEX color "FF44FF", as another color, that was not the actual value. (Yet, amazingly, with the overlay, they displayed normal colors for images over 256 colors.)

Your best bet, for accuracy, is to pull the value from a data-file... and DRAW the color on the screen, and use that same value to DRAW your other data... (So you are playing with the same "True" values. Your eyes will not notice the 2-val offset on the color, but your data will.)

[Petr Schreiber]

Hi Intio,

that is why I recommend to analyze file as Abraxas and now ISAWHIM suggests, contrary to rely on graphic card output.
Drrivers make some optimizations, which can result in not so accurrate output.

Intel does great CPUs, but I cannot say the same about their graphic cards ( I even hesitate to call it GPU in case of Intel ). It might be because graphics innovation is not their target, but this is exactly why me and Intel we are no big friends :)

If I am not wrong, none of the Intel cards supports OpenGL 2.1 at the moment, which is 2 years old thing. They do not have 1.5 as well, which is even older.

Good thing is with TBGL you code safely - it is written in way all features can be executed on 99.99% cards, and some commands even scale according to architecture they run on.

Sadly it is not in my power to control output and correct it. All textures are internally stored with 8 bits of precision per channel = 8 Red, 8 Green, 8 Blue, 8 Alpha.

I checked my code to load 256 color textures ( as is the test one ), and there is no rounding involved - I just take colors from pallete and assign them to pixels directly.


Petr

[Intio]

Thank you for the explanations ISAWHIM and Petr. That's not a platitude - I genuinely find all this detail interesting.

As I said, it looks like I'll pay more attention to Abraxas's code ;D