16 bit BMP | developer.brewmp.com 16 bit BMP | developer.brewmp.com

Developer

16 bit BMP

Forums:

Hello Friends,

We are trying to make 16-bit Bitmap images. Our graphics designer is using Adobe Illustrator. But when she tries to save image, she does not get option to save image as 16-bit. Does anyone know of any other software that allows Bitmap to be stored as 16-bit ?

Regards,
Gaurang.

I'm not sure if this will help, but...
16 bit color isn't an "official" BMP color depth: it supports 1, 4, and 8 bits per pixel palette indices or 24 bit RBG. The palette is always 24 bit color, so in essence BMP is always 24-bit color. Gimp also only supports the official forms.
My best guess about the BREW device spec sheets that claim they work with 1, 2, 4, 8, and 16 bit color is that they just refer to the number of significant bits in the color fields. I've had good results on the 16 bit devices masking each color by 0xF8 i.e taking the most significant 5 bytes for each color and throwing away the rest.
-Jesse

I'm not sure if this will help, but...
16 bit color isn't an "official" BMP color depth: it supports 1, 4, and 8 bits per pixel palette indices or 24 bit RBG. The palette is always 24 bit color, so in essence BMP is always 24-bit color. Gimp also only supports the official forms.
My best guess about the BREW device spec sheets that claim they work with 1, 2, 4, 8, and 16 bit color is that they just refer to the number of significant bits in the color fields. I've had good results on the 16 bit devices masking each color by 0xF8 i.e taking the most significant 5 bytes for each color and throwing away the rest.
-Jesse

Quote:Originally posted by jhw
16 bit color isn't an "official" BMP color depth: it supports 1, 4, and 8 bits per pixel palette indices or 24 bit RBG.
MSDN documents 16-bit BMPs, so I consider it official.
I'm not sure what application will create 16-bit BMPs, but you could always write your own converter. The BMP format is well documented and straight forward. Alternatively, you could store your resources as another bit depth. For instance, 8-bit paletted bitmaps are often sufficient (since every image can have its own palette), and they are more space efficient.

Quote:Originally posted by jhw
16 bit color isn't an "official" BMP color depth: it supports 1, 4, and 8 bits per pixel palette indices or 24 bit RBG.
MSDN documents 16-bit BMPs, so I consider it official.
I'm not sure what application will create 16-bit BMPs, but you could always write your own converter. The BMP format is well documented and straight forward. Alternatively, you could store your resources as another bit depth. For instance, 8-bit paletted bitmaps are often sufficient (since every image can have its own palette), and they are more space efficient.

16-bit is very official and well documented in MSDN. In addition, Photoshop 7 will output 16-bit BMP images :)
Tom

16-bit is very official and well documented in MSDN. In addition, Photoshop 7 will output 16-bit BMP images :)
Tom

Quote:Originally posted by jhw
I'm not sure if this will help, but...
16 bit color isn't an "official" BMP color depth: it supports 1, 4, and 8 bits per pixel palette indices or 24 bit RBG. The palette is always 24 bit color, so in essence BMP is always 24-bit color. Gimp also only supports the official forms.
he's right.

Quote:Originally posted by jhw
I'm not sure if this will help, but...
16 bit color isn't an "official" BMP color depth: it supports 1, 4, and 8 bits per pixel palette indices or 24 bit RBG. The palette is always 24 bit color, so in essence BMP is always 24-bit color. Gimp also only supports the official forms.
he's right.

16-bit is definitely part of the official format and has been since Win95. It's also true 16-bit, with two bytes per pixel and 555, 565, 5551, 4444, etc as options for the bit packing.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bit...
Tom

16-bit is definitely part of the official format and has been since Win95. It's also true 16-bit, with two bytes per pixel and 555, 565, 5551, 4444, etc as options for the bit packing.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bit...
Tom

Quote:Originally posted by Vexxed
16-bit is very official and well documented in MSDN. In addition, Photoshop 7 will output 16-bit BMP images :)
Tom
I have photshop 7.0 and the 16bit images (565 format) that are output will not display in brew. I contacted qualcomm, and it looks to be an issue with the images that Photoshop produces. They are not in the correct format.
Does anyone author thier own 16bit images? What do you use?

Quote:Originally posted by Vexxed
16-bit is very official and well documented in MSDN. In addition, Photoshop 7 will output 16-bit BMP images :)
Tom
I have photshop 7.0 and the 16bit images (565 format) that are output will not display in brew. I contacted qualcomm, and it looks to be an issue with the images that Photoshop produces. They are not in the correct format.
Does anyone author thier own 16bit images? What do you use?

Our application rendeing engine creates 16bit bitmap on fly and it works well on BREW phone (if hardware supports 16 bit).
ruben

Our application rendeing engine creates 16bit bitmap on fly and it works well on BREW phone (if hardware supports 16 bit).
ruben

Quote:Originally posted by DirtyWigeon
I have photshop 7.0 and the 16bit images (565 format) that are output will not display in brew. I contacted qualcomm, and it looks to be an issue with the images that Photoshop produces. They are not in the correct format.
From looking at a few sample Photoshop 7.0 BMPs, I'd say it's more like it generates broken BMPs. They contain an incorrect header size in one of the fields.

Quote:Originally posted by DirtyWigeon
I have photshop 7.0 and the 16bit images (565 format) that are output will not display in brew. I contacted qualcomm, and it looks to be an issue with the images that Photoshop produces. They are not in the correct format.
From looking at a few sample Photoshop 7.0 BMPs, I'd say it's more like it generates broken BMPs. They contain an incorrect header size in one of the fields.

yes it is definatly a Photoshop issue.

yes it is definatly a Photoshop issue.

Note that according to the device data sheets, at least some of the phones just do 5.5.5 16-bit color as opposed to 5.6.5. (the VX4400, most notably - this probably holds for at least some of the other handsets too)

Note that according to the device data sheets, at least some of the phones just do 5.5.5 16-bit color as opposed to 5.6.5. (the VX4400, most notably - this probably holds for at least some of the other handsets too)

ruben wrote:Our application rendeing engine creates 16bit bitmap on fly and it works well on BREW phone (if hardware supports 16 bit).
ruben
Cool. So do you create a Microsoft documented 16-bit BMP file image in memory and use the IDISPLAY_BitBlt to draw it to the screen? I want to make sure that a real 16-bit MSDN defined bitmap will work as the source for the IDISPLAY_BitBlt function, which requires a BMP file image buffer.

ruben wrote:Our application rendeing engine creates 16bit bitmap on fly and it works well on BREW phone (if hardware supports 16 bit).
ruben
Cool. So do you create a Microsoft documented 16-bit BMP file image in memory and use the IDISPLAY_BitBlt to draw it to the screen? I want to make sure that a real 16-bit MSDN defined bitmap will work as the source for the IDISPLAY_BitBlt function, which requires a BMP file image buffer.

not checked in high detail but this may help:
photoshop saves in the header of 16 bit 565 bitmaps for the member biSize the value 0x38(that means 56).
If you correct this with a hex editor to 0x28 (that means 40) everything should work well.
It will be loaded successfully on emulator/device/Gimp/Paint. Be sure that the bitmap is bottom up (top down bmps will not work for all of them).
the reason of the correction is this:
translating the microsoft BITMAPINFOHEADER:
typedef struct tagBITMAPINFOHEADER{
DWORD biSize;
LONG biWidth;
LONG biHeight;
WORD biPlanes;
WORD biBitCount;
DWORD biCompression;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
BITMAPINFOHEADER;
to:
typedef struct {
UInt32 biSize;
UInt32 biWidth;
UInt32 biHeight;
UInt16 biPlanes;
UInt16 biBitCount;
UInt32 biCompression;
UInt32 biSizeImage;
UInt32 biXPelsPerMeter;
UInt32 biYPelsPerMeter;
UInt32 biClrUsed;
UInt32 biClrImportant;
BITMAPINFOHEADER;
the structure has 40 bytes (the value 0x28).
Probably photshop's biSize value is wrong
(just a thought: maybe sizeof(LONG)=8 is the problem on their implementation, that would match the value 56)
I could load/save/blit 16 bit bmps from files/camera successfully.
Regards.

not checked in high detail but this may help:
photoshop saves in the header of 16 bit 565 bitmaps for the member biSize the value 0x38(that means 56).
If you correct this with a hex editor to 0x28 (that means 40) everything should work well.
It will be loaded successfully on emulator/device/Gimp/Paint. Be sure that the bitmap is bottom up (top down bmps will not work for all of them).
the reason of the correction is this:
translating the microsoft BITMAPINFOHEADER:
typedef struct tagBITMAPINFOHEADER{
DWORD biSize;
LONG biWidth;
LONG biHeight;
WORD biPlanes;
WORD biBitCount;
DWORD biCompression;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
BITMAPINFOHEADER;
to:
typedef struct {
UInt32 biSize;
UInt32 biWidth;
UInt32 biHeight;
UInt16 biPlanes;
UInt16 biBitCount;
UInt32 biCompression;
UInt32 biSizeImage;
UInt32 biXPelsPerMeter;
UInt32 biYPelsPerMeter;
UInt32 biClrUsed;
UInt32 biClrImportant;
BITMAPINFOHEADER;
the structure has 40 bytes (the value 0x28).
Probably photshop's biSize value is wrong
(just a thought: maybe sizeof(LONG)=8 is the problem on their implementation, that would match the value 56)
I could load/save/blit 16 bit bmps from files/camera successfully.
Regards.

mihai wrote:not checked in high detail but this may help:
photoshop saves in the header of 16 bit 565 bitmaps for the member biSize the value 0x38(that means 56).
If you correct this with a hex editor to 0x28 (that means 40) everything should work well.
It will be loaded successfully on emulator/device/Gimp/Paint. Be sure that the bitmap is bottom up (top down bmps will not work for all of them).
Regards.
I am running Adobe Photoshop CS and I just tested saving a 16-bit BMP. I am not sure what version you are running, but in CS it appears to save the BMP file correctly. I checked out the info in a Hex Editor and got the 0x28 instead of the 0x38. It appears that is probably just a PS 7 issue.
Scott

mihai wrote:not checked in high detail but this may help:
photoshop saves in the header of 16 bit 565 bitmaps for the member biSize the value 0x38(that means 56).
If you correct this with a hex editor to 0x28 (that means 40) everything should work well.
It will be loaded successfully on emulator/device/Gimp/Paint. Be sure that the bitmap is bottom up (top down bmps will not work for all of them).
Regards.
I am running Adobe Photoshop CS and I just tested saving a 16-bit BMP. I am not sure what version you are running, but in CS it appears to save the BMP file correctly. I checked out the info in a Hex Editor and got the 0x28 instead of the 0x38. It appears that is probably just a PS 7 issue.
Scott

You are right Scott, I noticed the 0x38 in 16 bit 565 bmps generated with PS7 but I think
this may solve some of the previous posts about using/loading 16 bit bmps. They were talking about PS7.
Thank you for pointing that.
Mihai

You are right Scott, I noticed the 0x38 in 16 bit 565 bmps generated with PS7 but I think
this may solve some of the previous posts about using/loading 16 bit bmps. They were talking about PS7.
Thank you for pointing that.
Mihai