BitmapMetaData throwing COM exceptions on TIFF files
- I have code that simply reads in the meta data from a variety of image files using presentationcore. Our QA folks have identified a few TIFF files that fail. What happens is that attempts to access the properties of the BitmapMetaData object such as Author, ApplicationName, etc all throw a System.Runtime.InteropServices.COMException. Of note is that this doesn't happen to all TIFF files. In addition, the problematic files have their metadata show up in the properties dialog of explorer with no problem.
Here's the code:
FileInfo file = new FileInfo(@"\\server\share\somefile.TIFF"); try { // We'll create the file stream ourselves so we can guarantee that the underlying file will be released using (FileStream fileStream = file.OpenRead()) { BitmapSource img = BitmapFrame.Create(fileStream); if (img != null) { BitmapMetadata metaData = img.Metadata as BitmapMetadata; if (metaData != null) { if (metaData.Author != null) // Throws exeception on this TIFF! { foreach (string currAuthor in metaData.Author) base.AddTextString(currAuthor); } base.AddTextString(metaData.ApplicationName); // Throws exeception on this TIFF! base.AddTextString(metaData.CameraManufacturer); // Throws exeception on this TIFF! base.AddTextString(metaData.CameraModel); // Throws exeception on this TIFF! base.AddTextString(metaData.Comment); // Throws exeception on this TIFF! base.AddTextString(metaData.Copyright); // Throws exeception on this TIFF! base.AddTextString(metaData.DateTaken); // Throws exeception on this TIFF! base.AddTextString(metaData.Format); // Throws exeception on this TIFF! if (metaData.Keywords != null) // Throws exeception on this TIFF! { foreach (string currKeyword in metaData.Keywords) base.AddTextString(currKeyword); } base.AddTextString(metaData.Location); // Throws exeception on this TIFF! base.AddTextString(metaData.Subject); // Throws exeception on this TIFF! base.AddTextString(metaData.Title); // Throws exeception on this TIFF! } } } } catch (ComException) { // Some TIFF files wind up here 100% of the time. }
The particular HRESULT is simply 0x80004005 (E_FAIL)
Does anyone have any idea what may be going wrong?
Thanks!
All Replies
- I suspect that TIFF file which fails with exception might be corrupted, could you please zip the problematic TIFF file and send it to me at v-mazho at microsoft dot com for repro?
Thanks
Another Paradigm Shift
http://shevaspace.blogspot.com - Marco was unable to address my issue here so I'd like to add more information and ping the community to see if there are other folks having the same problem. In addition the exception I noted above we have 2 other errors coming out of this code (depending on the particular file being opened).
I have 2 jpgs that throw the following exception on the line in my code sample above that tries to access the DateTaken property of the metadata:
System.OverflowException:The image data generated an overflow during processing. Exception while filtering: System.OverflowException: The image data generated an overflow during processing. ---> System.Runtime.InteropServices.COMException (0x88982F05): Exception from HRESULT: 0x88982F05
--- End of inner exception stack trace ---
at System.Windows.Media.Imaging.BitmapMetadata.GetQuery(String query)
at System.Windows.Media.Imaging.BitmapMetadata.get_DateTaken()
We also have some other TIFF files that give an error on the line where BitmapFrame.Create() is called:
System.ArgumentException:Property cannot be found. Exception while filtering: System.ArgumentException: Property cannot be found. ---> System.Runtime.InteropServices.COMException (0x88982F40): Exception from HRESULT: 0x88982F40
--- End of inner exception stack trace ---
at System.Windows.Media.Imaging.BitmapDecoder.SetupDecoderFromUriOrStream(Uri uri, Stream stream, BitmapCacheOption cacheOption, Guid& clsId, Boolean& isOriginalWritable, Stream& uriStream, UnmanagedMemoryStream& unmanagedMemoryStream, SafeFileHandle& safeFilehandle)
at System.Windows.Media.Imaging.BitmapDecoder.CreateFromUriOrStream(Uri baseUri, Uri uri, Stream stream, BitmapCreateOptions createOptions, BitmapCacheOption cacheOption, RequestCachePolicy uriCachePolicy, Boolean insertInDecoderCache)
at System.Windows.Media.Imaging.BitmapDecoder.Create(Stream bitmapStream, BitmapCreateOptions createOptions, BitmapCacheOption cacheOption)
at System.Windows.Media.Imaging.BitmapFrame.CreateFromUriOrStream(Uri baseUri, Uri uri, Stream stream, BitmapCreateOptions createOptions, BitmapCacheOption cacheOption, RequestCachePolicy uriCachePolicy)
at System.Windows.Media.Imaging.BitmapFrame.Create(Stream bitmapStream)
Is there something fundamentally wrong with the approach that my code takes up above? I'm finding it quite odd that the 3.5 framework classes trip up this much on images that load just fine in 3rd party viewers. Does anyone else have any advice or experiences with this? I'm simply trying to read the metadata. It doesn't get any simpler than that!
- No one else has run into this issue? No words from MS at all? I'm at a loss as to why the 3.5 library is barfing on images that most regular software has no problems processing.
- Can anyone point me to any information regarding this? I can supply both code and sample images that exhibit these issues. I'd like to know if this is a known bug, if it's being fixed or whatever the case is.
- Usually specific issues like this wil gain more traction if you file a Connect bug and attach the appropriate details (repro project, image files, etc). If you can, send a zipped, self-contained repro project and include the problematic image files to me at brendan DOT clark AT microsoft DOT com. I would suspect there is some metadata in the files that WIC (and therefore WPF) is handling differently than other 3rd party programs.
I took a look at the repro project I was sent and I believe that the issues lies with WIC v1 (the Windows Imaging Component). It seems to fail to decode the first image, and it has trouble reading metadata for the other 4 – note that the first image doesn’t even display in Windows Photo Gallery for me on Vista. Since WPF depends on WIC for imaging, there isn’t much the framework can do to mitigate this issue – the images are either malformed, are using metadata features that WIC v1 didn’t support, or are exposing some other issue in WIC. In the future you can use WICExplorer to investigate these issues.
The good news is that all of these problems are resolved with WIC v2 – on my Win7 machine all the images load and display as expected and all the metadata is processed correctly. Since WPF uses whatever version of WIC you have installed, that means these images will work fine in your application on Win7. There are also plans to port WIC v2 down to Vista so the situation will improve there as well, you can see details about that (and download a beta for it) here: http://blogs.msdn.com/directx/archive/2009/09/10/windows-7-transition-pack-for-windows-vista.aspx- Proposed As Answer byBrendan Clark - MSFT Wednesday, November 04, 2009 11:26 PM


