Yes, I did.  I sent them the bitmap files saved by Photoshop and they replied that these files are not compliant with the MSDN documentation.

There are 5 different alternatives to  BITMAPINFOHEADER that exist in the wild.  See the attached image:

BITMAPCOREHEADER, BITMAPINFOHEADER, BITMAPV4HEADER, BITMAPV5HEADER are all documented by Microsoft.

However BITMAPADOBEHEADER and BITMAPADOBEALPHAHEADER are proprietary and undocumented by Microsoft, yet Adobe Photoshop creates them when saving images in certain advanced Bitmap (BMP) formats.

For example when saving in these advanced bitmap formats, Photoshop creates proprietary headers:

16bpp X1 R5 G6 B5

16bpp A4 R4 G4 B4

32bpp X4 R8 G8 B8

I can send you these bitmap files or you can generate them yourself in Photoshop.

Also, I can provide you with a MS-Winows utility that displays the header sizes of bitmaps and you will see that these files saved by Photoshop have a header sizes equal to 0x34 bytes or 0x38 bytes.  Ergo, PROPRIETARY and undocumented by Microsoft's MSDN.

Are you convinced already that Photoshop uses proprietary bitmap headers?

Also, the practice of "many other applications writing BITMAPINFOHEADER, BI_RGB, and ARGB data" does not make it legal and compliant with Microsft's documentation.

BITMAPV4HEADER, BITMAPV5HEADER were especially invented to explicitly indicate the presence of the Alpha Channel in bitmaps and advanced color info.

All they have to do, is use them correctly.

You might want to check these files which I generated with Photoshop a while ago:

http://1dollarsoftware.com/Photoshop16bpp_X1R5G6B5.bmp

http://1dollarsoftware.com/Photoshop16bpp_A4R4G4B4.bmp

They also have the 0x38 bytes undocumented header....

P.S.

What is YOUR name for the 0x34 and 0x38 byte headers?

Very well, so our discussion bears fruit

I was presumptious of me to state that the 0x38 sized header is an invention of Adobe, and my original post should be corrected as:

WAS:

"a) Alternatively use the proprietary Adobe header of the size 0x38 bytes, that Photoshop seems to be using in the wild."

SHOULD BE:

"a) Alternatively use the undocumented header of the size 0x38 bytes, that Photoshop seems to be using in the wild."

What was named as BITMAPADOBEALPHAHEADER should have been named BITMAPV3INFOHEADER - their structure is the same.

Nonetheless BITMAPV3INFOHEADER is still undocumented.  Google search yields NO HITS on it.

Also, I cannot find it in MSDN nor in officiel Microsoft SDK sources.

Also, no other software, that I know of, generates bitmap files with BITMAPV3INFOHEADER.

Because of this undocumented header the following major software is incompatible with such bitmaps generated by Photoshop:

http://1dollarsoftware.com/Photoshop32bpp_X8R8G8B8.bmp

1) MS_Office - Does not display the image at all

2) Windows Picture and Fax Viewer v6.00.2900.5512 - Does not display the image at all

3) Firefox v3.6.12 (the most recent version) - Displays the image with corrupted colors

4) Opera v9.62 - Does not display the image at all
5) Chrome v7.0.517.44 - Does not display the image at all

6) Internet Explorer 8.0.6001.18702 and v6.0.2900.5512 - Displays corrupted image. Note the little black artifact in upper right corner of the image.

For completeness, I am attaching an updated comparison between all the bitmap headers that I have encountered in the wild:

Dear Curious Admin,

Thanks for adding the Safari column

I cannot assign a bacground image to a table cell while posting on this forum

Could you allow the "background" keyword when inserting Raw HTML, so I can insert overlapping images in a table cell like this ? :

<table><tr><td background="checkerboard.bmp"><img src="foreground.bmp"/></td></tr></table>

Now if I try to insert Raw HTML that contains this "background" keyword , your script simply cuts it out.

This would help me illustrate to Chris more of the bugs with current implementation and demonstrate how proper formats behave.

Too bad the Admin cannot help me, because it limits my diagramming ability.

The usage of undocumented bitmaps headers (yes they are undocumented today and I have never seen them documented in the past) is not the original point that I brought up. However this issue is also sigficant because it causes many incompatibilities with MAJOR applications.

I illustrate this at the URL below:

http://1dollarsoftware.com/bmp.html

However my original point was not about undocumeted structures but that in a bitmap file Photoshop does not indicate the presence of an Alpha Channel in a consistent and in documented manner.

Because of this whan users make a PowerPoint presentation, they loose the Alpha channel.  When programmers design icons or GUI elements in Photoshop, they also lose the Alpha channel.

Not even Photoshop itself is certain when an Alpha channel is present in a bitmap file, and spuriously adds it, even when it was removed earlier.

See the examples in the URL above, where I propose alternative encodings of the bitmap files using minimum documented header versions that are possible without loosing information.

Regards,

George

Photoshop is a flagship graphics editor and I expect only perfection from it and adherence to current documentation.

The original intention of a feature is of no consequence.  It is a social argument - not technical.

Many people in my company use Photoshop to create presentations - not games and it is up to the user what he/she uses the tool for.  The tool must work reliably, yet it does not.

How can you imply that "Error opening" an image created by Photoshop by major software is not an incompatibility?

I cannot file a bug with PowerPoint team because they are coding according to current Microsoft's documentation - Photoshop is not.

The result of some software audit a decade ago is irrelevant to current situation, even if that audit was without a flaw, which I am not claiming that it was.

Image wise, the extra channel does no harm.  For round tripping purposes, the extra channel does no harm.  So, what is your point?

But it does!

1) It harms performance.  Alpha blending is many times slower than normal blitting (sometimes requires a hard division by n^2-1), see:

http://msdn.microsoft.com/en-us/library/dd183393%28VS.85%29.aspx

...and since Photoshop does not indicate the presence of an Alpha channel in bitmap headers it is hard to select the proper pixel operation routine.

2) Also lack of reliable information in the headers prevents searching large collections of files for bitmaps containing an Alpha channel.

3) Showing an Alpha channel in the Photoshop GUI after it has just been removed in previous operation, is confusing to the Photoshop user at best.

3) Finally, showing an Alpha channel after opening a bitmap file in the format R5G6B5, that does not even have a space for an Alpha channel is plainly illogical.

You are not documenting incompatibilities -- but that Photoshop implements more than the other applications.

Yes, I am.  For example VisualStudio and PowerPoint can open bitmap files generated by other applications  (including translucency in the Alpha channel)  and of the same "non-openable" pixel format as generated by Photoshop.  The "Alternative" table in my last URL does not document files that have been generated by Photoshop, but by other software.

You keep suggesting that I should learn about bitmaps and ask questions.

Thus, what kind of questions do you suggest that I ask about the component structures of the bitmap files, such as: BITMAPFILEHEADER, BITEMAP*INFOHEADER, BITMAPV?HEADER, the BITFIELDs, Color Table, Pixel Array and Color Profile Data ?  Did I miss any?

P.S.

I did not use the word "transparent" or "transparency" even once.  Please do not split hairs on the contents of the Alpha channel...