[RESOLVED] [GDI+] EMF > WMF & VB6 LoadPicture

Interesting effect but unwanted. After successfully converting GDI+ handle to WMF bits and saving them to file, I am getting semi-transparency when the file is loaded into a VB6 picture/property. But when displayed in GDI+, no noticeable side effects.

The source image is a GDI+ 32bppARGB bitmap that includes only simple transparency: pixels are either 100% opaque or 100% transparent. It is converted to EMF and then to WMF using this logic. I'll use the GDI+ flat api names, but any .Net solutions would be welcomed as well.

1. Create blank EMF using desktop DC: GdipRecordMetafileStream
2. Get EMF graphics: GdipGetImageGraphicsContext
3. Draw source to EMF: GdipDrawImageRectRect
4. Convert EMF to windows EMF: GdipGetHemfFromMetafile
5. Convert EMF bits to WMF: GdipEmfToWmfBits
6. Write bits to file & clean up

Attached are the source (32bppARGB bitmap) & converted EMF, WMF. Again, loaded via GDI+ all looks good, but loading WMF into VB6, I'm getting unwanted semi-transparency; not so with the EMF. I have also double & triple checked that the source alpha values are either 0 or 255 and nothing between. Saving an image with transparency produces this effect from the logic I described above.

Any ideas how to get rid of the semi-transparency for the WMF? Maybe a different way of getting GDI+ handle with simple transparency to windows WMF format? I have tried both 32bppARGB & 8bpp bitmaps (i.e., like a transparent GIF)

Now this is a bit frustrating. On a different machine and I cannot replicate the problem. Starting to think graphics card issue? If anyone else experiences similar semi-translucency issues with the WMF, please chime in.

And backtracking again... gawd! Problem resurfaced. Looking now to see if manifesting VB form is in play or not.

Edited: Here is an example of what I am seeing (a picture is worth a 1,000 words)
You can see the design-time form and then the run-time form. The Lion.wmf is one created eons ago before GDI+ existed. The Spider.wmf is one created by me using GDI+, same logic described in post #1.
Attachment 82520
In the VB6 form, both WMFs are loaded in image controls. Not one line of code added to the form. Ideas anyone?

Note. I also did a fresh reboot to see if possibly not loading GDI+ into VB6 process had any change. Ran the form again immediately after reboot and got same results. Not a WMF records expert, but I'd be willing to bet that there is some command in that WMF that is causing the transparency & most likely the fact that the source image had transparency may be a player. But if that's true, then how does one write to WMF with a source that uses the alpha channel? EMF format is not affected this way.

I may have answered my own question. I'll post back tomorrow to let you know if it worked. Too frustrated to start this tonight. And you say, "what do you have in mind"? My answer: Regions, specifically ClipRegion from mask.

Like my signature block below reads... Insomnia is just a byproduct of "It can't be done".

Well, not too much insomnia, but blasted problem wouldn't let me stop thinking about it.

The key, it appears is not to allow source as 32bpp ARGB or any format with transparency, including 8bpp. Even filling with solid color before rendering didn't help. I had to create the region from bitmap then reduce the source to 24bpp. Only then did the WMF semi-transparency stop. Fortunately I have a very fast region from bitmap routine.

Regions work, but still looking for a far simpler method. Here's the adjusted logic...

1. Create blank EMF using desktop DC: GdipRecordMetafileStream
2. Get EMF graphics: GdipGetImageGraphicsContext
3. [added] Get previously created Region object & apply to graphics: GdipSetClipRegion
4. Draw 24bpp source to EMF: GdipDrawImageRectRect
5. Convert EMF to windows EMF: GdipGetHemfFromMetafile
6. Convert EMF bits to WMF: GdipEmfToWmfBits
7. Write bits to file & clean up

Edited: This is one of my favorite sites regarding GDI+ declarations and some examples. However, the owner forgot to include GdipSetClipRegion which threw me for a loop for a bit trying to figure out how to set a clipping region with a region. Anyway, good ol' MSDN listed it. But for us VB6'rs here's the API declaration

Code:

---

Private Declare Function GdipSetClipRegion Lib "gdiplus.dll" (ByVal hGraphics As Long, ByVal hRgn As Long, ByVal combineMode As Long) As Long

---

Another annoyance.

If the source image is black and white, regardless of the actual bit depth, 1,4,8,16,24,32 then the WMF resorts to transparency as would a 1bpp black and white icon during runtime, but like a 1bpp black & white bitmap during design time. My workaround for this is to ensure the black color in a palette that only contains black and white, is not true black, but 1 (near black). Doing so, allows the WMF to appear identical during both runtime and design time.

Edited: In zip below you'll find the offending WMF. In design-time ok, but not at runtime

A side note, somewhat related.

Anyone know how to parse the info retrieved from GdipGetRegionData? I am well versed in parsing data retrieved from GDI's GetRegionData.

But the two are different. GDI has a 32 byte header followed by region rectangles. A region consisting of just one rectangle will be 48 bytes. But that same region set in GDI+ and returned with GdipGetRegionData returned just 36 bytes. And looking at those bytes; not sure what I'm looking at. This last question is more for education and to allow me to set a region from bitmap even faster than what I'm doing now.

Edited: FYI, some other overly curious individual posted some teasing info here
And from those comments, I can't see creating a region via the related GdipCreateRegionRgnData could be a speed improvement if the region data is created manually. It appears the data required is a structured list of commands: Add this rectangle to the region using this combine flag. Next rectangle: similar commands, etc, etc. However, using GdipGetRegionData & GdipCreateRegionRgnData does allow serialization/deserialization of regions.