colors are slightly off importing gifs and bmps

  • Thread starter Thread starter Joshua Moore
  • Start date Start date
J

Joshua Moore

I know this has been addressed before, but I can't find it. I'm using
identical RGB values for colors, on the background color on the .netcf
device, and on the images (both gif and bmp) imported. Something about 3
shifted ring a bell to anyone?

Thanks in advance,

Joshua Moore
 
Tim,
In the conversation below, they found you could right shift by 3 to get
the right color, but I don't know what this means. Is that if you have R25
G25 B25 your imported graphics should be R22 G22 B22?

Thanks in advance (in ship mode...need to fix this soon),
Joshua Moore
 
If you tried to bit shift each pixel in your image, on demand, then this
could cause your application to slow down to a point noticeable by the
end-user, depending on how many images you need and how large they might be.
I believe what Geoff was trying to say is that you will need to shift every
R, G, and B value for every pixel 3 places using the bit shift operator (Rimages until they render in a respectable manner through the CF - this is
what Boris ended up doing.

There is some more information in the thread linked below about what might
actually be going on inside the CF to cause this behavior, if you're
interested.
http://groups.google.com/groups?hl=...#[email protected]&frame=off
 
Is there any way to save the file in a format that would create identical
colors? The artist says it wouldn't take much time to save them in
different formats, etc., but I tried it as a 16-bit color (the viewsonic
device claims 15 bit color), hoping that would be close enough, but no go.
Any ideas?

Thanks,
 
I think you will run into this issue with the loading of any picture format
through the CF, but I'm not 100% sure. So I don't think that a different
format would work in this situation. Unless someone else knows of a
light-weight programmatic way to work-around this then you might need to
have the artist do some modifications to the images.
 
Since the problem is clearly in pixel format not matching what you have on
the device, I wonder if you'd do a little experimet for me. I've put
together a small desktop application, that can load an image and save it in
RGB555 format. Could you try opening one of your images and saving it (with
different name of course), then looking at it both on the desktop and the
device?

http://www.alexfeinman.com/download.asp?doc=BitmapApp.zip

You can of course modify the app to try different pixel formats and image
disk formats
 
Greetings,

What I was trying to articulate before, and maybe not too well, is that
because the display of most PPC devices is 16 or 15 bit, the pixel values of
a 24 bit image have to be packed (right shift each color component by 3) in
order to be displayed on the device. This is how each pixel is converted
from 888 to 555 or 565 (with 565, the green component is only shifted by 2).
The only device I know of that supports 565 is one of the older Casio
MIPS-based Pocket PCs.

I believe (Alex did some research on bitmap memory use a while back which
confirms this), that what happens in GDI is that each pixel is loaded into
memory "as is" and then a copy of the image is also made which matches the
format of the device. It is this latter image that is used for displaying
(there is your 16 bit 555 format), while the former memory image is used to
uphold the integrity of the data for programmatic operations, such as
transparency comparisons, etc.

If you only maintained the converted image then you would have poblems where
colors that are close to each other in value would be rounded to the same
value and the integrity of such operations would not be maintained (see my
"Dancing Rectangles" article for an example of this).

On the other hand, if you only maintained the original then each pixel would
have to be converted on the fly when it is drawn.

To make a much too long story short; to see a more realistic view on the PC
of what you will see on the device, save the bitmap as 16 bit.

Regards,
Geoff Schwab
 
My product interweaves custom buttons and labels on top of background
picture boxes. I spent a great deal of time trying to match the colors
given by the graphics department to that of my labels and such. The
"only" way I was able to clean up the disparity between my graphics
and the bitmaps was by using Image.GetPixel and displaying a message
box with the RGB values. After getting the RGB values I hardcoded my
graphics accordingly. After doing this, I got RGB values that were off
from what Photoshop told me, however they appeared as part of the
background.

This is just a work around I used instead of trying to figure out the
math behind making graphics match.

I hope this helps,

Norm
 
Prior to posting this I did some research of my own - basically, it looks
like DecompressImageIndirect does not handle DIBs with compression set to
BI_BITFIELDS. Unfortunately the only way to get a true 16bit bitmap is to
use BITFIELDS. If I create a bitmap (on the desktop) that has 5:6:5 color
packing (with an extended version BITMAPINFOHEADER), it will not open on the
device (not even in PIE). The 16 bit 5:5:5 bitmap will be treated as 16bit
period, so that the white will stay F8 F8 F8. At the same time the real
white is F8 FC F8. SInce the internal DIB for CF is created as 5:5:5, it
means that even calling SetPixel(Color.White) will produce an almost white
pixel. As a result in CF it is impossible to draw a pure white pixel - only
a close approximation. At present I am not aware of any workaround
 
Is there any patch, etc. that could be provided? It could be copied into
ROM on the CE devices, I just really need a viable solution that doesn't
force me to draw each pixel (I already do that in certain circumstances to
infer transparency.

Thanks for all your help!

Joshua Moore
Developer in distress ;)
 
Back
Top