This site is no longer active and is available for archival purposes only. Registration and login is disabled.

Determing a pixel's RGB components with GAPI


Determing a pixel's RGB components with GAPI

Postby Frank W. Zammetti » May 23, 2001 @ 4:08pm

Frank W. Zammetti
 


Re: Determing a pixel's RGB components with GAPI

Postby Dan East » May 23, 2001 @ 4:30pm

That depends on the type of RGB encoding (555, 565, 888 ). Check the ffFormat member of the the display properties to determine the actual encoding. AFAIK, all devices use 565 at this time. This is off the top of my head, so it may need tweaking:<br>[pre]<br>//RGB 565 -> 24 bit RGB<br>int red=(pixelColor&0xf800)>>8;<br>int green=(pixelColor&0x7e0)>>3;<br>int blue=pixelColor&0x001f<<3;<br>[/pre]<br>Note that with 565 encoding green can have twice as many shades as red or blue.<br><br>Dan East<br><br>Last modification: Dan East - 05/23/01 at 13:30:59
User avatar
Dan East
Site Admin
 
Posts: 5264
Joined: Jan 25, 2001 @ 5:19pm
Location: Virginia, USA


Re: Determing a pixel's RGB components with GAPI

Postby Digby » May 23, 2001 @ 4:52pm

Back in the early DDraw days, drivers would be notorious for reporting the wrong pixel format for surfaces.  What we'd do is draw a red, green, and blue pixel on the screen using GDI's SetPixel(), then go read what was actually written to video memory using DDraw.  That way you absolutely knew which bits were being set for each color component.  <br><br>You shouldn't have to do that with the PocketPC though, since the display modes don't change and you can't swap out the video display hardware.<br>
Digby
pm Insider
 
Posts: 1011
Joined: Apr 29, 2001 @ 1:53pm


Re: Determing a pixel's RGB components with GAPI

Postby suchiaruzu » May 23, 2001 @ 4:54pm

<div align="center">Image<br></div>
User avatar
suchiaruzu
pm Insider
 
Posts: 2570
Joined: May 3, 2001 @ 9:29am
Location: BFE


Re: Determing a pixel's RGB components with GAPI

Postby Frank W. Zammetti » May 23, 2001 @ 11:37pm

Frank W. Zammetti
 


Re: Determing a pixel's RGB components with GAPI

Postby Malmer » May 24, 2001 @ 3:51am

All your base are belong to us
User avatar
Malmer
pm Member
 
Posts: 768
Joined: Apr 26, 2001 @ 5:15pm
Location: Sweden


Re: Determing a pixel's RGB components with GAPI

Postby Dan East » May 24, 2001 @ 8:58am

To expand on what Fredrik said, you are starting with colors that are 8 bits per color component. Those are converted to 5 bits for red and blue, and 6 bits for green. So you lose 3 bits of information from red and blue and 2 bits from green.  3 bits is equal to 8 decimal, while 2 bits is 4 decimal. So red and green may be equal to, or up to 8 less than, your original value, while green may be up to 4 less than the original color value.<br><br>Original 8 bit Red in binary:<br>RRRRRRRR<br>After converted to / from 5 bits:<br>RRRRR000<br>The lowest three bits will always be zero, hence your lost precision. If it so happened that in the original value the lowest 3 bits were already zero, then there was no information to lose, so the result will match. In the values you gave, 200 matched. 200 in binary is 11001000. Clear as mud? :)<br><br>Dan East<br><br>Last modification: Dan East - 05/24/01 at 05:58:29
User avatar
Dan East
Site Admin
 
Posts: 5264
Joined: Jan 25, 2001 @ 5:19pm
Location: Virginia, USA


Re: Determing a pixel's RGB components with GAPI

Postby Frank W. Zammetti » May 24, 2001 @ 9:12am

Grr... It IS clear as mud, it's just that mud sucks!<br><br>I guess the work-around is to pre-decrease the values when I plot them.  In other words, zero out the lowest three bits of R and B and two bits of G and use those as my color components.  Then when I read a pixel from the VFP, I would expect to get the same values I put there then.  <br><br>Fortunately, in my application I think it's not a big deal because I was actually writing a function to dim a portion of the screen, so basically this means that my colors will start out dimmed slightly already.  I was expecting this to lead to a sprite collision detection algorithm, so I would have had to have dealt with this anyway.<br><br>Does the pre-decreasing idea sound right though?  I'll test it later, but it seems to make sense at the moment (it IS 9 in the morning though, way too early for MY brain!)  Thanks again guys, you've all been a great help!
Frank W. Zammetti
 


Re: Determing a pixel's RGB components with GAPI

Postby Dan East » May 24, 2001 @ 9:27am

That sounds good. If you pre-translate all your bitmaps to the RGB encoding used by the device then it will save a lot of processor time when you blit the screen out. The disadvantage is that some processing, depending exactly on what your software does, may take longer because of the extra work to extract individual color component values.<br><br>Dan East
User avatar
Dan East
Site Admin
 
Posts: 5264
Joined: Jan 25, 2001 @ 5:19pm
Location: Virginia, USA


Return to Windows Mobile


Sort


Forum Description

A discussion forum for mobile device developers on the Windows Mobile platform. Any platform specific topics are welcome.

Moderators:

Dan East, sponge, Digby, David Horn, Kevin Gelso, RICoder

Forum permissions

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
You cannot post attachments in this forum

cron