emf-export renders transparent image areas black

[Erich Taubmann]

The transparent parts of images become black when exported into the emf-format.
I am using Inkscape 0.91 on Windows 7; the emf-file is viewd in Microsoft Word 2010.

Included is a Inkscape test file plus the resulting emf file.

I consider the Inkscape emf export fare superior to Adobe Illustrator and are very glad about the new version.
Thanks for the great wok!

Best Regards
Erich

=====
Follow-up report:
Bug #1419926 “EMF clipping of bitmaps is broken”

[su_v (suv-lp)]

Reproduced with Inkscape 0.91 r13725 and 0.91+devel r13909 on OS X 10.7.5 (tested with cairo 1.12.2 and cairo 1.14.0): the rasterized content of the EMF file imports with a black background, the same happens with local EMF export (the transparent regions of the bitmap image embedded in the SVG file are black when reopening the EMF file in Inkscape).

@David Mathog - any chance you could take a look?

[David Mathog (mathog)]

The short answer is that EMF does not support transparency very well.

In modern bitmap formats one specifies for each pixel RGB and in addition a 4th value that sets the transparency. In such a bitmap any color can have any transparency. No EMF record type supports that. EMF format does support a more limited form of transparency where a regular RGB image is defined and in addition one color is set as "transparent". This is essentially the same thing as "green screening" in a movie, that one color is completely transparent and all others are completely opaque. (Note that EMF and WMF do support 4 byte/pixel bitmaps, but section 2.1.1.4 of the WMF manual says "The high byte in each DWORD is not used". In theory one could extend the format in an incompatible manner by storing the usual transparency byte there. However, since that byte can legally have any value whatsoever, one would have to expect to run into images produced by other applications with that number of bytes/pixel which would import with spurious transparency values.)

EMF has half a dozen "BLT" record types and the Inkscape implementation supports many of them, but not EMR_TRANSPARENTBLT, which is the one you would need for even the more limited "green screen" form of transparency. I will give this some thought - I guess it would be possible to scan the incoming image (from SVG) and IF all transparent pixels
are 100% transparent AND they are the same color AND that color exists nowhere else in the image then we could use
the EMR_TRANSPARENBLT format. Going the other way would be trivial, but it has not come up before now, since nobody has yet posted an example generated by any other application that uses this record type. I would not be surprised if we found that perfectly valid EMR_TRANSPARENTBLT records were imported poorly or not at all by other applications.

The EMF output you are seeing does appear to be correct for the current implementation. The transparent image does appear to have black pixels in the areas shown - but with an opacity of 0.

It _should_ have been possible to work around this by defining a clipping region and clipping the image, however I see that doesn't work. This is very odd, since a clipped path type object works, but adding an image and clipping both the path and the image is broken. I will look into that.

[Erich Taubmann (etaubmann)]

Hi David

Thank you for that detailed feedback!

At home I did a short test with CorelDraw X6 and transparent image areas.
Corel preserves the tranparent parts in the image, but the transition seems
harder and more like a sawtooth effect (due to the limitation of emf).

You can see the results in the contained zip file.

Best Regards
Eric

2015-02-09 19:14 GMT+01:00 David Mathog <email address hidden>:

> The short answer is that EMF does not support transparency very well.
>
> In modern bitmap formats one specifies for each pixel RGB and in
> addition a 4th value that sets the transparency. In such a bitmap any
> color can have any transparency. No EMF record type supports that.
> EMF format does support a more limited form of transparency where a
> regular RGB image is defined and in addition one color is set as
> "transparent". This is essentially the same thing as "green screening"
> in a movie, that one color is completely transparent and all others are
> completely opaque. (Note that EMF and WMF do support 4 byte/pixel
> bitmaps, but section 2.1.1.4 of the WMF manual says "The high byte in
> each DWORD is not used". In theory one could extend the format in an
> incompatible manner by storing the usual transparency byte there.
> However, since that byte can legally have any value whatsoever, one
> would have to expect to run into images produced by other applications
> with that number of bytes/pixel which would import with spurious
> transparency values.)
>
> EMF has half a dozen "BLT" record types and the Inkscape implementation
> supports many of them, but not EMR_TRANSPARENTBLT, which is the one you
> would need for even the more limited "green screen" form of transparency.
> I will give this some thought - I guess it would be possible to scan the
> incoming image (from SVG) and IF all transparent pixels
> are 100% transparent AND they are the same color AND that color exists
> nowhere else in the image then we could use
> the EMR_TRANSPARENBLT format. Going the other way would be trivial, but
> it has not come up before now, since nobody has yet posted an example
> generated by any other application that uses this record type. I would not
> be surprised if we found that perfectly valid EMR_TRANSPARENTBLT records
> were imported poorly or not at all by other applications.
>
> The EMF output you are seeing does appear to be correct for the current
> implementation. The transparent image does appear to have black pixels
> in the areas shown - but with an opacity of 0.
>
> It _should_ have been possible to work around this by defining a
> clipping region and clipping the image, however I see that doesn't work.
> This is very odd, since a clipped path type object works, but adding an
> image and clipping both the path and the image is broken. I will look
> into that.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1419686
>
> Title:
> emf-export renders transparent image areas black
>
> Status in Inkscape: A Vector Drawing Tool:
> Confirmed
>
> Bug description:
> The transparent parts of images become black when exported into the
> emf...

[David Mathog (mathog)]

I could not open that cdr properly (no coreldraw, and Inkscape does a bad job of it - the star image is surrounded by a white, not transparent, region.) That EMF consists of a huge number of polybezier circular rings (to produce the circular gradient) which is then completely overwritten by an image of a blue star on a background with the same circular gradient. So CorelDraw does not preserve whatever transparency there was in the original drawing, it makes a bitmap of the screen image. The sawtooth effect is from a combination of the bitmapping and a lack of antialiasing.

The EMF it produces is also messed up, but in the expected way, since the gradient is entirely covered by the image, there is no reason whatsoever to have it in the EMF. I can tell you why that happened too. CorelDraw sent the objects to its output driver in the order bottom to top. So first it sent the gradient. EMF does not have a native way of representing a circular gradient, and the driver choose to emulate it with a series of rings (via MOVETOEX and POLYBEZIERTO16 records), which it sent to the EMF. Then it sent an image with transparent areas. The driver cannot send a transparency to EMF, so it bitmaps the part of the drawing within the bounds of the image and then sends that bitmap to the EMF. That is the STRETCHDIBITS record near the end of the EMF.

You can dump the contents of EMF files to a text file using the reademf application in libUEMF (from sourceforge). If you are on windows get the programs EMF Explorer and metafile explorer (this is the better of the two). You can find the downloads for these with Google. From reademf we can see that the emf file produced has only EMF records and no EMF+ records. (Which doesn't matter yet for Inkscape because I have yet to implement an EMF+ driver, although the bones for it are in libUEMF. I have not done that yet because I found that PowerPoint omits all text when it emits EMF+ records, making that format useless for most things for the most common application where it would be used!)

[Nathan Lee (nathan.lee)]

Hi - thanks for reporting this bug, I've manually migrated it to Inkscape's new bug tracker on GitLab, and closed it here.

Request still tracked at https://gitlab.com/inkscape/inbox/-/issues/3858

Please feel free to file new bugs about the issues you're seeing at http://inkscape.org/report.