Re: Image colors altered on Pocket PC

[Chris Tacke, eMVP]

Search the archives. This has been covered extensively. I believe the
answer is "it's a bug".

-Chris

"Bertrand Fontaine" <Bertrand Font...@discussions.microsoft.com> wrote in
message news:368CD21B-BD0E-44D0...@microsoft.com...
> If I create a white (255,255,255) image on the desktop and load it as a
> Bitmap on the Pocket PC, the color values that are returned by
GetPixel(x,y)
> are (248,248,248). It is crucial for me to get the actual colors as far as
I
> am using some images as masks in a rendering engine. What is going on ?
How
> do I get the actual color information of an image ?
>
> Thank you,
>
> Bertrand Fontaine

[Alex Feinman [MVP]]

It's a bug. As of now there is no generic workaround. For masking purposes,
black stays black (0,0,0), and white gets reduced to (F8,F8,F8). Modify your
code and images to rely on this.

To better understand what's happening, here is a rough scenario:
CF uses imgdecmp.dll to decompress bitmaps. During the decompression, it
creates a target DIBSECTION with 16bit color specified. This works for 5:5:5
color representation. Unfortunately most PPCs operate in true 16bit color
using 5:6:5 color scheme. This color layout requires using BI_BITFIELDS flag
and a slightly different version of BITMAPINFOHEADER.
As it is during the decompression the colors are reduced from whatever
format the source image used to 5:5:5 bitmap. As a result white (FF,FF,FF)
becomes (F8,F8,F8) instead of (F8,FC,F8). If the physical device were using
5:5:5 colors, it would be displayed as white. In 5;6:5 layout it becomes
very slightly grayish. Similarly, all other colors except of those that have
G=0 are offset to a certain extent. Even if the source image is not
compressed, it will not be rendered correctly, since everything goes through
the edcompression process as described above, if only to transform color
depth. And if you attempt to load an uncompressed bitmap saved as 5:6:5, it
will simply fail (another bug, but related).

Like I said before, there is no generic workaround, but you can come up with
something that works for your particular scenario

--
Alex Feinman
---
Visit http://www.opennetcf.org

[Bertrand Fontaine]

Thanks to you and Chris for your answers.

Do you know whether this problem is expected to be solved in .NET CF 2.0 ?

Bertrand Fontaine

[Alex Feinman [MVP]]

It appears it is indeed fixed in the current build of CF 2.0

--
Alex Feinman
---
Visit http://www.opennetcf.org

"Bertrand Fontaine" <Bertrand...@discussions.microsoft.com> wrote in
message news:D4DF3533-A99E-4DB4...@microsoft.com...

[Bertrand Fontaine]

Thank you very much, Alex. It also appears that .NET CF 1.x doesn't support
alpha blending what is another major problem for me. Do you know if .NET CF
2.0 supports alpha blending ?

I have heard about GAPI. Would that API be a solution for me ?

I would like to have a look at .NET CF 2.0. I guess that the only way to
access it is by downloading the beta of Visual Studio .NET 2005. Does .NET CF
2.0 run with current hardware (iPaq 2210 w. PPC 2003 for ex.) ? Do you think
it is a viable option to develop with it right now a project to be delivered
internally at the beginning of 2005 ?

Thank you again for your time and help,

[Alex Feinman [MVP]]

Regarding GAPI - it is just means of accessing the screen buffer directly.
There is no support for anything beyond that.
Alpha blending - honestly, I don't remember. Repost this as a new question,
and I'm sure someone will help you wit that.
VS 2005 - there is currently no go-live license for CF2.0 and it does not
look like the stuff will be released in the early 2005 (and then again - it
might). I cannot offer a sound advise, since the product cycles are hard to
predict

--
Alex Feinman
---
Visit http://www.opennetcf.org
"Bertrand Fontaine" <Bertrand...@discussions.microsoft.com> wrote in

message news:C2D99AA5-DC04-4E0C...@microsoft.com...