PNG Icon format

PNG Icon format

• Sk8tz

  Since a PNG is not a BMP it cannot use a BITMAPINFOHEADER structure. You can look at the cbSize member of the BITMAPINFOHEADER to see whether it is sizeof(BITMAPINFOHEADER) - indicating that what follows is a BMP - or the PNG signature - indicating that what follows is a PNG.
  
  Clearly all apps that parse ICO files and resources will have to be updated to support PNGs since that is a new feature. You can check the cbSize to see whether you have a BMP or PNG. (Who knows maybe future versions of the ICO file will support other image formats... in which case you get to update your app again.)
  
  If all you care about is the image meta-data (height, width, color depth) you can get that from the ICONDIRECTORY.
  
  It's not clear to me what you're asking for.

  
  

• Jagadesh

  I have code that is reading the .ico format of a Vista icon (the icon for notepad). Icons previous to Vista have a standard layout (i.e. IconHeader, IconDirectory). Vista has the new PNG embedded in the file. The thing is, it seems that the IconDirectory structure is still in the new Vista icons, but I'm reading odd data for what I think is the 256x256 data (the raw hex shows 13x67 hex). Are these structures not valid for Vista icons Are there new structures
  
  

• bobwilmes

  Hi Raymond,
  
  Thanks for your response.  My app is based on the IconPro sample and the "Icons in Win32" article at http://msdn.microsoft.com/library/default.asp url=/library/en-us/dnwui/html/msdn_icons.asp.
  
  The problem with Windows Vista icons is that there is no BITMAPINFOHEADER.  According to the article:
  
  

  "For each ICONDIRENTRY, the file contains an icon image. The dwBytesInRes member indicates the size of the image data. This image data can be found dwImageOffset bytes from the beginning of the file, and is stored in the following format:

  typdef struct
  {
     BITMAPINFOHEADER   icHeader;      // DIB header
     RGBQUAD         icColors[1];   // Color table
     BYTE            icXOR[1];      // DIB bits for XOR mask
     BYTE            icAND[1];      // DIB bits for AND mask
  } ICONIMAGE, *LPICONIMAGE;

  (end quote)
  
  The problem is that PNG device images don't have this structure, they have the raw PNG data right here; thus there is no BITMAPINFOHEADER to check for validity.  I will have to code my app to explicitly check for PNG data.
  
  The article does start off with the disclaimer "Internal details discussed in this article are subject to change without notice in future versions of Windows."  So, I don't fault Microsoft for making a breaking change like this. I understand that there probably isn't any good way to add this functionality without breaking SOMEthing.

  
  

• jnousis

  Thanks for reporting the problem. We're looking at it now. Backwards compatibility may have to be sacrificed to some degree because the icon file format previously supported only BMP.  It appears that your app fails to check the signature in the BITMAPINFOHEADER and just blindly assumes a BMP format.
  

• MuratO

  (I had been thinking of where the BITMAPINFOHEADER specifies that the data uses PNG compression, something that was introduced in Windows 2000 I believe.  I've got my head on straight now. )
  
  Also, thanks Raymond for all the time you put into these forums and your blog -- it is much appreciated!
  
• PNG Icon format