This topic was discussed awhile back.
You can open any GIF, JPG, BMP and display it, using the Render()
method of the ipicture interface -- this is COM stuff.

I experimented and found that the actual bitmap is still a DIB, and
I used ipicture::SelectPicture() to extract a handle to the bitmap
and then used BitBlt() to paint the bitmap.
I also experimented with TransparentBlt(), which enables you to
specify a transparent color -- but it has a memory leak in Win9x
-- MS fixed it for WinMe onwards.

So, my question. As the image is just a DIB, how does Render()
know which color is the transparent one? Ernie and some other guys
have some code in which they used GetPixel(hdc,0,0,) to get the
transparent color -- but, was this an arbitary choice? is it some kind
of standard to use 0,0 for the transparent color?

By the way, Ernie, I tried to email you at ernie@surfree.com but
got "user unknown".

When a GIF is loaded, or any image, it becomes a DIB, and
somehow Render() knows what color is transparent. This is the
question I can't find the answer to in any MS docs.
I want to be able to read that color and maybe modify it.

For my little freeware app, I would like to display a edit box in which
users can choose the transparent color for any image, regardless of
whether it was GIF, BMP, etc beforehand, but must be able to read
the transparent color previously inside the image.
Surely I won't have to go back to the original GIF image to read it
... surely not ...

Anyone got any thoughts on this?

Regards,
Barry kauler
P.S., I'm planning to write-up my experiments on TransparentBlt()
and whatever else turns up, for everyone to benefit.
Posted on 2002-10-26 18:22:13 by bkauler
Barry,

Nice to see you again.

I've seen the 0,0 pixel defined as transparent in a few places (such as OCX toolbox bitmaps), so apparently its a common hack to use it that way in a bitmap.

GIFs were designed "bottom up" to be transparent, they store the index number of the transparent color in the Graphic Control Extension per my copy of GIF89a.

I was playing around once trying to make a royality free moving GIF control that used the Windows code to do the LZW unpacking (hence no royality). The project went no where (paying work got far more interesting), but parsing the GIF data stream wasn't all that bad, even for multiple (or moving) images.

For the moment, I'm borrowing mail server space from my wife's site. I can be reached at ernie@chairlady.com
Posted on 2002-10-29 20:43:27 by Ernie
Hi,
I posted a similar question to a Microsoft newsgroup, and an actual
MS support person responded.

He pointed out that I can't expect to find transparent color info
in a DIB, because it isn't part of the DIB spec.

He also said that although I found the image inside the ipicture object
was just a DIB and I was able to use BitBlt() instead of ::Render(), that
was just "coincidental". Render() knows about transparent color and
the format of image storage in the object is not published and subject
to change.

Finally, he recommended that my problem with transparent color would
be solved if I used GDI+.

GDI+???

So, I had a quick look at the GIF89a spec and wrote some code to extract
the transparent color. Works on a couple of GIFs but I don't fully understand
the spec yet, so it's probably not perfect -- the code looks like a quick hack,
which it is.

Regards,
Barry Kauler
Posted on 2002-10-30 09:21:05 by bkauler
He also said that although I found the image inside the ipicture object was just a DIB and I was able to use BitBlt() instead of ::Render(), that was just "coincidental".


In my copy of MSDN, IPicture:SelectPicture returns a phbmpOut. Now my hungarian might be a little rusty, but I read that as "pointer to a handle of a bitmap you can copy from me"

Interesting that the Microspeak for an interface performing exactly as it is published is "coincidental"
Posted on 2002-10-30 23:04:29 by Ernie
Well, here is my posting to microsoft.public.win32.programmer.gdi
and the reply from the MS guy:

Subject: RE: ipicture render transparent color Attachments: None
From: "John Hornick " <JHornick@online.microsoft.com> Sent: 10/26/2002 7:22:54 PM

Hi,

> You can open any GIF, JPG, BMP and display it, using the Render()
> method of the ipicture interface -- this technique is documented
> in various places, including a link off my x86 page:
> http://www.goosee.com/x86/
>
> Ipicture is a COM thing, but the functions are readily callable
> from non-oop code -- I program in MS assembler.
> I experimented and found that the actual bitmap is still a DIB, and
> I used ipicture::SelectPicture() to extract a handle to the bitmap
> and then used BitBlt() to paint the bitmap.
> I also experimented with TransparentBlt(), which enables you to
> specify a transparent color -- but it has a memory leak in Win9x
> -- MS fixed it for WinMe onwards.
>
> A note for those unfamiliar with ipicture::Render() -- it automatically
> displays the transparent color in a GIF. I use OleLoadPicture() to
> load any GIF, JPG or BMP. This is all in the olepro32.dll, that works
> on Win95.
>
> So, my question. As the image is just a DIB, how does Render()
> know which color is the transparent one? I looked at some code
> in which they used GetPixel(hdc,0,0,) to get the
> transparent color -- but, was this an arbitary choice? is it some kind
> of standard to use 0,0 for the transparent color?
>
> When a GIF is loaded, or any image, it becomes a DIB, and
> somehow Render() knows what color is transparent. This is the
> question I can't find the answer to in any MS docs.
> I want to be able to read that color and maybe modify it.
>
> For my little freeware app, I would like to display a edit box in which
> users can choose the transparent color for any image, regardless of
> whether it was GIF, BMP, etc beforehand, but must be able to read
> the transparent color previously inside the image.
> Surely I won't have to go back to the original GIF, BMP, etc image to
> read it ... surely not ...
>
> Anyone got any thoughts on this?


As you noted, IPicture is a COM thing, not a GDI thing. So maybe
you'd get better information by posting on a COM newsgroup.

Still, here's my 2 cents: the fact that it's stored as a DIB is
a coincidence - I don't think that's documented, and therefore
might change from version to version of olepro32 or oleaut32.

If I needed to provide the functionality you are looking to provide,
I'd use GDI+. GDI+ does what you want, and in documented ways.

Thanks,
- John
Microsoft Developer Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Visit http://www.microsoft.com/security for current information on security.
Posted on 2002-10-31 16:44:24 by bkauler