How to save Data in a Grafics to a Bitmap ?

[Mark Johnson]

How can you save all or a portion of the Grafics object to a Image/Bitmap ?
I am try to save the Images from Cards.dll to a BitMap file.
I can read in the Images to the Grafics, but when I try this with a Bitmap
the results are Black.
Can you somehow Clip the Grafic and Paste it into the Bitmap ?

Mark Johnson, Berlin Germany
(e-mail address removed)

 

[Alex Yakhnin, eMVP]

Mark,

Take a look at this sample:

http://download.microsoft.com/downl...4-9d17-fd6767e66908/SaveBitmapSampleSetup.exe

 

[Paul Kay]

I think there is a bug in that sample when it saves bitmaps with 24bit
colour depth.
I believe each line needs to be started on a 4 byte boundary, or something
along those lines, it's late at night and I haven't studied it in detail, I
just looked at the output and have experienced a similar skewed effect.

Paul Kay

 

[Mark Johnson]

Thank you, I have gotten everything to work.
- Read in the Bitmap from cards.dll
- Save as Bitmap to File
- Save ReRead Bitmap as Jpeg
- Pack Bitmap to Graphics in WinCe Size
- Save as Bitmap in WinCe Size
- Save ReRead Bitmap as Jpeg in in WinCe Size

 

[Geoff Schwab [MSFT]]

Hi Paul,

Thanks for the input. I will take a look at the sample today and post the
results to this thread.

--
Geoff Schwab
Program Manager
Excell Data Corporation
http://msdn.com/mobility
http://msdn.microsoft.com/mobility/prodtechinfo/devtools/netcf/FAQ/default.aspx

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Geoff Schwab [MSFT]]

Hi Paul,

I did some testing and cannot seem to reproduce this problem. I tried
images of varying sizes and saved them as 16 and 24 bit bitmaps and they
look fine in the ImageEditor on the device, IE on the device, Paint on the
PC, and Windows Picture Viewer on the PC. I don't think the 32-bit
alignment should be an issue since the bitblt automates that and that would
be the case for 16 bit images as well as 24.

Could you please give me a scenario that causes this problem, including the
size and format of the original image and what changes you made to save it
as 24-bit - I assume just changing the third parameter to
BitampFile.SaveToFile?

Thanks,
Geoff Schwab
Program Manager
Excell Data Corporation
http://msdn.com/mobility
http://msdn.microsoft.com/mobility/prodtechinfo/devtools/netcf/FAQ/default.aspx

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Paul Kay]

Geoff,

I just loaded a known 24bit .bmp image into 'Image Editor' where it
displayed correctly, then I saved it under a new name. Then when viewing
both images using the 'Picture' Application installed on my iPaq 22xx, the
new image is skewed, whereas the original isn't. Strangely, though, on
reloading the skewed copy to 'Image Editor', it displays correctly, as did
the original.

So it would seem the underlying problem is more complex than I originally
surmised. I still haven't looked at the code in any detail or made any
changes to it , but can see that the saved copy is smaller (45.9K 145w*160h)
than the original (68.4K 145w*160h) and therefore I'm guessing that it has
been saved as a 16 bit colour depth. Maybe the sample just isn't intended
to cope with the above scenario in it's raw state, i.e. load a 24 bit
bitmap, save it as 16 bit.

Now, the next bit of testing I've just done is even more interesting, the
Image viewer portion of the application I'm in the process of writing
displays both the original and the saved 16bit version correctly. So.....
I'm beginning to think that in fact it's the 'Picture' application that
comes installed on the new Windows Mobile 2003 Pocket PCs that doesn't
handle 16bit bitmaps correctly and that both the sample and my code do.

Therefore, (I'm testing as I'm writing this) I apologise, it seems the Image
Editor Sample is in fact fine...... but the installed (in Rom) 'Pictures'
Application, pimg.exe doesn't.... Ouch, sorry I wasted your time checking
the sample, but perhaps you'd better talk to the pimg.exe 'team'.

My apologies, it was a bit late last night (actually early this (or now
yesterday) morning) when I looked at the sample, I should have investigated
more before commenting, but I'd coincidently spent much of the day writing
bitmap saving code and had been using the pimg.exe to test the results,
thinking it must be solid.

Regards
Paul

 

[Alex Yakhnin, eMVP]

Hi Mark,

Just wondering... what did you use to save bitmap as jpeg?
Native jpeglib?

 

[Geoff Schwab [MSFT]]

Hi Paul,

No problem, this is good information to have. There tends to be a bit of
inconsistency with the BMP "standard." From the most reliable resources I
have found, a 16 bit image (as reported by BITMAPINFOHEADER::biBitCount) is
always supposed to be 565 RGB format, whereas an image reported as 15 (not
16) bit is 555. I actually went against this standard in the sample because
all of the commercial products I tested with only supported a 16 bit 555
formatted image which is technically wrong but seems to have become the de
facto industry standard.

I don't know if this has anything to do with what you are seeing but thank
you for following up!

--
Geoff Schwab
Program Manager
Excell Data Corporation
http://msdn.com/mobility
http://msdn.microsoft.com/mobility/prodtechinfo/devtools/netcf/FAQ/default.aspx

This posting is provided "AS IS" with no warranties, and confers no rights.

Geoff,

I just loaded a known 24bit .bmp image into 'Image Editor' where it
displayed correctly, then I saved it under a new name. Then when viewing
both images using the 'Picture' Application installed on my iPaq 22xx, the
new image is skewed, whereas the original isn't. Strangely, though, on
reloading the skewed copy to 'Image Editor', it displays correctly, as did
the original.

So it would seem the underlying problem is more complex than I originally
surmised. I still haven't looked at the code in any detail or made any
changes to it , but can see that the saved copy is smaller (45.9K 145w*160h)
than the original (68.4K 145w*160h) and therefore I'm guessing that it has
been saved as a 16 bit colour depth. Maybe the sample just isn't intended
to cope with the above scenario in it's raw state, i.e. load a 24 bit
bitmap, save it as 16 bit.

Now, the next bit of testing I've just done is even more interesting, the
Image viewer portion of the application I'm in the process of writing
displays both the original and the saved 16bit version correctly. So.....
I'm beginning to think that in fact it's the 'Picture' application that
comes installed on the new Windows Mobile 2003 Pocket PCs that doesn't
handle 16bit bitmaps correctly and that both the sample and my code do.

Therefore, (I'm testing as I'm writing this) I apologise, it seems the Image
Editor Sample is in fact fine...... but the installed (in Rom) 'Pictures'
Application, pimg.exe doesn't.... Ouch, sorry I wasted your time checking
the sample, but perhaps you'd better talk to the pimg.exe 'team'.

My apologies, it was a bit late last night (actually early this (or now
yesterday) morning) when I looked at the sample, I should have investigated
more before commenting, but I'd coincidently spent much of the day writing
bitmap saving code and had been using the pimg.exe to test the results,
thinking it must be solid.

Regards
Paul

Hi Paul,

I did some testing and cannot seem to reproduce this problem. I tried
images of varying sizes and saved them as 16 and 24 bit bitmaps and they
look fine in the ImageEditor on the device, IE on the device, Paint on the
PC, and Windows Picture Viewer on the PC. I don't think the 32-bit
alignment should be an issue since the bitblt automates that and that would
be the case for 16 bit images as well as 24.

Could you please give me a scenario that causes this problem, including the
size and format of the original image and what changes you made to save it
as 24-bit - I assume just changing the third parameter to
BitampFile.SaveToFile?

Thanks,
Geoff Schwab
Program Manager
Excell Data Corporation
http://msdn.com/mobility

http://msdn.microsoft.com/mobility/prodtechinfo/devtools/netcf/FAQ/default.aspx

This posting is provided "AS IS" with no warranties, and confers no rights.

http://msdn.microsoft.com/mobility/...4-9d17-fd6767e66908/SaveBitmapSampleSetup.exe with

a

 

[Paul Kay]

Geoff,

I guess then 15/16bit is a 'grey' area (pun intended)

Paul