It is currently Sat Dec 16, 2017 7:41 pm

All times are UTC + 1 hour




Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: Explanation of the flipped BGR mode?
PostPosted: Fri Dec 01, 2017 3:03 pm 
Offline
User
User

Joined: Wed Dec 31, 2014 1:01 pm
Posts: 58
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..


Top
 Profile  
Reply with quote  
 Post subject: Re: Explanation of the flipped BGR mode?
PostPosted: Fri Dec 01, 2017 4:41 pm 
Offline
Enthusiast
Enthusiast
User avatar

Joined: Thu Apr 30, 2009 5:23 pm
Posts: 203
Location: Côtes d'Azur, France
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.

_________________
There are 2 methods to program bugless.
But only the third works fine.


Last edited by Fig on Fri Dec 01, 2017 4:49 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: Explanation of the flipped BGR mode?
PostPosted: Fri Dec 01, 2017 4:48 pm 
Offline
User
User

Joined: Wed Dec 31, 2014 1:01 pm
Posts: 58
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: Explanation of the flipped BGR mode?
PostPosted: Fri Dec 01, 2017 4:51 pm 
Offline
Enthusiast
Enthusiast
User avatar

Joined: Thu Apr 30, 2009 5:23 pm
Posts: 203
Location: Côtes d'Azur, France
Obviously, every programming environnement use the classical RGB format. When compiled it check the hardware and swap the two value if needed.

_________________
There are 2 methods to program bugless.
But only the third works fine.


Last edited by Fig on Fri Dec 01, 2017 4:53 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: Explanation of the flipped BGR mode?
PostPosted: Fri Dec 01, 2017 4:52 pm 
Offline
User
User

Joined: Wed Dec 31, 2014 1:01 pm
Posts: 58
And obvioulsy PB does not. So this is a PB problem.


Top
 Profile  
Reply with quote  
 Post subject: Re: Explanation of the flipped BGR mode?
PostPosted: Fri Dec 01, 2017 4:54 pm 
Offline
Enthusiast
Enthusiast
User avatar

Joined: Thu Apr 30, 2009 5:23 pm
Posts: 203
Location: Côtes d'Azur, France
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.

_________________
There are 2 methods to program bugless.
But only the third works fine.


Last edited by Fig on Fri Dec 01, 2017 5:04 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: Explanation of the flipped BGR mode?
PostPosted: Fri Dec 01, 2017 5:03 pm 
Offline
Addict
Addict
User avatar

Joined: Mon Sep 15, 2003 5:55 am
Posts: 1262
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.

Code:
Structure MyColor
  a.a[0]
EndStructure

Color.l = RGB(11, 22, 33)
*Color.MyColor = @Color

Debug *Color\a[0]; First Value Red
Debug Red(Color)
Debug ""
Debug *Color\a[1]; Second Value Green
Debug Green(Color)
Debug ""
Debug *Color\a[2]; Third Value Blue
Debug Blue(Color)
Debug ""
Debug Bin(Color)

x86 cpus use the Little Endian format. meaning, the least significant bit is stored first:
Image

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

c ya,
nco2k

_________________
If OSVersion() = #PB_OS_Windows_ME : End : EndIf


Top
 Profile  
Reply with quote  
 Post subject: Re: Explanation of the flipped BGR mode?
PostPosted: Fri Dec 01, 2017 5:07 pm 
Offline
Enthusiast
Enthusiast
User avatar

Joined: Thu Apr 30, 2009 5:23 pm
Posts: 203
Location: Côtes d'Azur, France
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.

_________________
There are 2 methods to program bugless.
But only the third works fine.


Top
 Profile  
Reply with quote  
 Post subject: Re: Explanation of the flipped BGR mode?
PostPosted: Fri Dec 01, 2017 5:25 pm 
Offline
User
User

Joined: Wed Dec 31, 2014 1:01 pm
Posts: 58
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..


Top
 Profile  
Reply with quote  
 Post subject: Re: Explanation of the flipped BGR mode?
PostPosted: Sat Dec 02, 2017 3:59 am 
Offline
Addict
Addict
User avatar

Joined: Mon Sep 15, 2003 5:55 am
Posts: 1262
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

_________________
If OSVersion() = #PB_OS_Windows_ME : End : EndIf


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: Baidu [Spider] and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  

 


Powered by phpBB © 2008 phpBB Group
subSilver+ theme by Canver Software, sponsor Sanal Modifiye