PureBasic Forums - English

Hi,
I just discovered that when I read the colorvalue from a pixel in a 24-bit image using Point() the decimal value has its Red and Blue bytes flipped!
Why?!
When I read a green pixel(00FF00) I get the decimal value 65280 which is correct.
When I read a red pixel I should get FF0000 which is 16711680, but instead I get 255.
Extremely strange. But the Red() function returns 255 when I insert 255 into it. Still strange.

So after some googling and an upset call to a friend, where I ask if I am crazy or has the color tables flipped in the electronic world, I found the answer in the PureBasic manual in the Color Table section.
There is says: "2.) submit the color value as whole value - but then the red and blue parts must be swapped, i.e. the color submitted in the BGR format.".
So this is a PureBasic thing. And when I know this I can easily(but angry) continue coding.
But WHY is this so? I haven´t seen the BGR mode anywhere in any programming language or any imagetool. And ofcourse the manual doesn´t say WHY I need to use BGR.

Can anyone explain why we have to even have this stupid mode when RGB is the standard?

//Andreas..

It depends of your graphic card. Pb has nothing to do with it and use the classical RRGGBB in his commands.

DrawingBufferPixelFormat() has to be used to get the pixel format of your own graphic card if you need to adress its memory. (RRGGBB or BBGGRR etc...)
Cf https://www.purebasic.com/documentation ... ormat.html

So, you should email your graphic card's company to explain how stupid they are and that it makes you angry.
I am sure theirs ingeneers will be glad to explain you their reasons and to apology. fIf you live near the company you can also try to get an appointment to spank them.

So you are saying that the R and B swapping depends on my hardware?
If so, is the manual incorrect when it says that R and B are swapped when using the color value as a whole value?
And why does no other programming environment present the color values like that? Atleast none I have tried on the same hardware.
Or are they converting the values back to RGB? If so then PB should do the same since I see no advantage of this.

Obviously, every programming environnement use the classical RGB format. When compiled it check the hardware and swap the two value if needed.

And obvioulsy PB does not. So this is a PB problem.

Edit: I see your point... But as you said in your first post, the help file gave your all information needed on Point().
I guess every programming environnement need to read their help file to use tem.

its not a purebasic thing and there is no problem. if you havent seen it elsewhere, then you havent looked hard enough. also your issue has nothing to do with BGR, but with endianness. BGR is a proper standard btw, and probably everything you see on your screen, is internally stored and processed as BGR. but thats a whole different topic.
x86 cpus use the Little Endian format. meaning, the least significant bit is stored first:


https://en.wikipedia.org/wiki/Endianness

c ya,
nco2k

I understood what he meant: According to his logic, he is expecting Pb command Point() to swap the Red/Blue if needed in the value he gets. It's aguable.

Fig: Yes, that´s my point exactly. The Point() function should return the 24-bits in RGB order since that´s what the respective Point() command in other environments do.

I have no problem with endianness on the low-level side. I am(well, was) used to assembly-programming on the Amiga which uses big-endian, which caused some problems, at first, when I began assembly on the PC which does the other way around.

But in higher levels graphics programming and in handling in graphics applications they ALL use RGB format(and/or possibly CMYK and such) and represent it with either hex or dec. It´s very weird to have the decimal value of 24 bit red(FF) to be 16711680 in all situations, except in PureBasic where the decimal of 24-bit red is 255.

Perhaps I was unclear of stating my problem, due to fumes coming out of my ears(;)), but it´s simply why the Point() function doesn´t return RGB, as expected.

//Andreas..

i understand what you were trying to say earlier. but you wanted to know why Point() works the way it works, so i mentioned endianess for you to understand this design decision. if you think about it, it makes a lot of sense.

pretty much everything network and web related, including image formats like png, use the network byte order (big-endian). maybe thats somehow related to why the majority does it the way they do, and purebasic doesnt.

as for real RGB vs BGR, on windows the image will usually be stored as BGR in memory, while on linux it will usually be stored as RGB. either way, Point() will return the same value, so you dont have to convert anything. however, if you are planning to access the memory directly via a pointer, then you should check how the data is stored, by using DrawingBufferPixelFormat().

c ya,
nco2k