Ted Goldblatt

(Possibly the wrong place to ask this sort of question, but...)


We have a need to provide custom image decode filters for the standard image types. For most of them, this is easy enough using standard IE facilities to register the filters against the appropriate MIME types. Unfortunately (for our purposes), image/gif, image/jpeg, and image/pjpeg are special cased by IE, so that even if an image decode filter is registered for one of them, it is ignored, and the build in renderer is used. (It would be nice if IE checked for an explicitly registered decoder, and use the built-in one only if a custom one wasn't registered, but that's not the case...)


We currently fake this out by hooking the FindMimeFromData() function to return custom image MIME types for these 3, and then registering our filters against these custom MIME types. This works OK for displaying these image types. Unfortunately, FindMimeFromData() is apparently also used by IE to determine the Content-type to return in the file data part of the multipart/form-data returned for an INPUT Type=file FORM, meaning that attempts to upload GIF or JPEG files will get our "funny" MIME types attached to them, which isn't OK. As far as I can tell, there doesn't appear to be enough info passed to FindMimeFromData() to allow our hook routine to determine why it is being called, so it can't return the "real" MIME types in the outbound case, and the "fake" MIME types in the inbound case. I was wondering if anyone has a suggestion for another way to solve this problem. I am not at all knowledgeable about IE extensions, but I have read some things implying that it may be possible to insert a filtering add-on that could find (and rewrite) the MIME types in the incoming stream. However, I haven't found any details or documentation that describes how to do something of this sort. A solution that isn't specific to a particular rev of IE would be preferred, but an IE7 only solution would be acceptable.

Anyone have any ideas for me

ted



Re: Internet Explorer Extension Development Custom Image Decode Filters for GIF and JPEG?

EricLaw-MSFT

Curious: What are you doing with the custom decoder

Do you get a meaningful difference in the pwzUrl parameter when FindMimeFromData is being called for an upload





Re: Internet Explorer Extension Development Custom Image Decode Filters for GIF and JPEG?

HaroonGhauree

Hello, I'm impressed by your work. I'm not here to help you out but asking help from you. I'm developing my own image CODEC in C++. But when it comes to advance operating system, I'm stuck with that as there are more than enough formalities lying around and i hate them alot. Why can't these guys make things simpler !

I've read about IImageDecodeFilter in msdn. It looks pretty good and straigh forward to me. But when I implemented a basic COM decoder. Register it like a COM server and also pay respect to the formalities of IE extensions i.e. for .myext and mime type mapping. I'm still struggling to get a proper property tag in IE on my image saying image type MyImage. It is showing unavailable and i've checked about 100 times that i'm registering my basic com (no atl/mfc support in plain c) properly. still my browser is unable to parse my file extension and properly map it to the mime i've registered. please help me out in getting a fine activation of my COM server. :( plzzz ...

thank you. i will be grateful to you.





Re: Internet Explorer Extension Development Custom Image Decode Filters for GIF and JPEG?

Ted Goldblatt

Sorry for the very delayed follow up - I had stopped looking for a response once we had an acceptable workaround, but a "real" solution would still be preferable.

The purpose of the custom decoder is to allow additional compression (the image will then be shipped across another (one assumes lower bandwidth) link, and then redisplayed there). For jpeg, the behavior is the moral equivalent of decoding as if the image had been compressed at a higher compression level (so that when the final display image is recompressed for transmission, it will compress better), but I don't personally know the actual mechanism used by the custom decoders.

I don't remember off-hand what pwzUrl showed, but I believe it wasn't NULL in one case and non-NULL in the other or anything else that distinct, so short of parsing the value and making assumptions about what types of values are used when, this wasn't a promising line of attack. Like I said, what would be the best (cleanest) solution for us would be for IE to always look for a registered decoder and only look at its built-in list and use its built-in decoders if no external one was registered for that MIME type, but I'm open to any reliable ideas.

ted