Possible bug IM 7 with EPS clip path

[fmw42]

Using the following EPS file and the commands below, I can get a proper result of masking using the clip path from the EPS file using IM 6.9.8.3 Q16. But it fails using IM 7.0.5.4.

EPS file:
http://www.fmwconcepts.com/misc_tests/c ... OV_EPS.eps

IM 6.9.8.3 Q16:

Code: Select all

identify -quiet -format "%[8BIM:1999,2998:#1]" \
-density 150 218755504_HOV_EPS.eps  |\
convert -density 150 218755504_HOV_EPS.eps \
-profile /Users/fred/images/profiles/sRGB.icc \
\( - -negate +write mask6.png \) \
-alpha off -compose copy_opacity -composite \
result6.png

Mask:


Result:



IM 7.0.5.4 Q16:
(Note I had to add -alpha off in using the mask in IM 7 otherwise it was totally transparent)

Code: Select all

magick identify -quiet -format "%[8BIM:1999,2998:#1]" \
-density 150 218755504_HOV_EPS.eps  |\
magick -density 150 218755504_HOV_EPS.eps \
-profile /Users/fred/images/profiles/sRGB.icc \
\( - -alpha off -negate +write mask7.png \) \
-alpha off -compose copy_opacity -composite \
result7.png

Mask:


Result:



Also changing the density, cause the result image's transparent pattern to be different.

It is clear from the displayed images, that the mask is not getting the correct density when being generated in IM 7. That is why the result image looks different for different densities.

I am using RSVG 2.40.16. Can someone else test this using Inkscape?

[fmw42]

This problem is being looked into. But this seems to work in the current IM 7.0.5.4 Q16.

It turns out that each renderer needs to have its default density specified when extracting the SVG path.

1. rsvg: 90
2. inkscape: 96
3. msvg: 72

I am using RSVG, so I do the following include adding -density 90 when extracting the SVG path from the eps file.

Code: Select all

magick identify -quiet -format "%[8BIM:1999,2998:#1]" \
-density 90 218755504_HOV_EPS.eps  |\
magick -density 300 218755504_HOV_EPS.eps \
-profile /Users/fred/images/profiles/sRGB.icc -set option:dim "%wx%h" \
\( - -alpha off -channel red -separate -negate \
-background black -gravity northwest -extent "%[dim]" \
+write mask7.png \) \
-alpha off -compose copy_opacity -composite \
result7.png

Note the line

Code: Select all

-background black -gravity northwest -extent "%[dim]" \

I need to add this since RSVG is currently making the mask image too small by one pixel on the right and one pixel on the bottom, so that the mask is not the same size as the eps image. Since I use -set option:dim to get the WxH of the eps image and -extent to make the mask larger, it should work when the mask size is already the correct size as apparently it does when using Inkscape.

[snibgo]

Hmm. I extract the SVG, and rasterise it using RSVG, MSVG and Inkscape v0.91 as delegates.

With IM v6.9.5-3, the results are 114x281 pixels. The MSVG is slightly cruder and has no resolution. RSVG and Inkscape give identical results, both 90 dpi.

With v7.0.3-6, RSVG fails and MSVG makes a 114x281 image that is entirely white, thus wrong. Inkscape makes the correct result.

2. inkscape: 96

As far as I know, Inkscape's default density is 90 dpi, which is the SVG standard.

[fmw42]

As far as I know, Inkscape's default density is 90 dpi, which is the SVG standard.

My information came from Magick about the density of the different renderers. I did not have inkscape to test.

This issue is still being investigated.

This was a workaround that seemed to work for me on my Mac under RSVG. I do not know how different versions of Imagemagick or RSVG will behave. Magick reported to me that my command (without the extent) worked correctly for him under Inkscape (and I presume he used density of 96)

[fmw42]

As far as I know, Inkscape's default density is 90 dpi, which is the SVG standard.

I do not use Inkscape, but according to http://wiki.inkscape.org/wiki/index.php ... n_Inkscape it would appear that they use 96 dpi.

[snibgo]

Ah, yes. That link also says:

Inkscape 0.91 and earlier used a value of 90 pixels per inch.

I use Inkscape 0.91. 0.92 is now available, and is quite recent.

I can't find anything in SVG 1.1 that defines a default resolution. I thought 90 dpi was a SVG standard, but I could be wrong.

CSS2 says:

It is recommended that the reference pixel be the visual angle of one pixel on a device with a pixel density of 90dpi and a distance from the reader of an arm's length.

Perhaps some standard somewhere has changed from 90dpi to 96dpi.

[fmw42]

Thanks for the information. That should be useful to the IM developers. It is interesting that Inkscape has decided to change their default density. I wonder what the reason was.

This seems to be something that may have to be left to the user to know which renderer is being used and the corresponding default density, especially since Inkscape seems to have a different density for different versions.

[snibgo]

The Inkscape release notes: known issues refer to the "DPI change". Elsewhere in Inkscape docs I've seen mention of a change from 90 dpi to 96 DPI, but no explanation.

This may be to conform to CSS2:

pt: points — the points used by CSS are equal to 1/72nd of 1in.
px: pixel units — 1px is equal to 0.75pt.

So one inch is 72*4/3 = 96 pixels.


When IM generates an SVG clip-path for rasterization, the units are pixels, so DPI isn't important. The problem arises when we want to tell the rasterizer to enlarge or reduce the rasterization. We do this with "-density X", where X is a multiple of the default setting. As Inkscape has changed its default, our commands that use "-density" will need to change. Grrr.

I've never liked IM's "-density", because I care about pixels. I usually don't care at all about inches. So I'd like a new option in IM, such as:

Code: Select all

-rasterize-factor 2.5

This would set the density to 2.5 times the default value of the rasterizer. So the same script could be used, without caring if the rasterizer is RSVG, old Inkscape, new Inkscape, or whatever.

[fmw42]

The changelog indicates that this issue has been fixed. But for me on IM 7.0.5.5 Q16 and IM 6.9.8.4 Q16 using RSVG 2.40.16 it still does not work. In no cases do the mask and image align properly.

Test1 - IM7 including -extent

Code: Select all

magick identify -quiet -format "%[8BIM:1999,2998:#1]" \
-density 90 218755504_HOV_EPS.eps  |\
magick -density 150 218755504_HOV_EPS.eps \
-profile /Users/fred/images/profiles/sRGB.icc -set option:dim "%wx%h" \
\( - -alpha off -channel red -separate -negate \
-background black -gravity northwest -extent "%[dim]" \
+write mask7a.png \) \
-alpha off -compose copy_opacity -composite \
result7a.png

Test2 - IM7 excluding -extent - is even worse

Code: Select all

magick identify -quiet -format "%[8BIM:1999,2998:#1]" \
-density 90 218755504_HOV_EPS.eps  |\
magick -density 150 218755504_HOV_EPS.eps \
-profile /Users/fred/images/profiles/sRGB.icc \
\( - -alpha off -channel red -separate -negate \
+write mask7b.png \) \
-alpha off -compose copy_opacity -composite \
result7b.png

Test3 - IM6 including -extent - note the colored mask, which should be binary b/w

Code: Select all

convert -density 150 218755504_HOV_EPS.eps -format "%wx%h" info:
238x585

identify -quiet -format "%[8BIM:1999,2998:#1]" \
-density 90 218755504_HOV_EPS.eps  |\
convert -density 150 218755504_HOV_EPS.eps \
-profile /Users/fred/images/profiles/sRGB.icc \
\( - -alpha off -channel red -separate -negate \
-background black -gravity northwest -extent 223x548 \
+write mask6a.png \) \
-alpha off -compose copy_opacity -composite \
result6a.png

Test4 - IM6 excluding -extent

Code: Select all

identify -quiet -format "%[8BIM:1999,2998:#1]" \
-density 90 218755504_HOV_EPS.eps  |\
convert -density 150 218755504_HOV_EPS.eps \
-profile /Users/fred/images/profiles/sRGB.icc \
\( - -alpha off -channel red -separate -negate \
+write mask6b.png \) \
-alpha off -compose copy_opacity -composite \
result6b.png

[magick]

It works best with inkscape and a density of 96. With RSVG, we got expected results with a density of 95.

[fmw42]

It works best with inkscape and a density of 96. With RSVG, we got expected results with a density of 95.

OK. For IM 7, using -density 95, does work better, but disagrees with the default density of 90 that you mentioned earlier for RSVG and as specified at http://linuxcommand.org/man_pages/rsvg1.html.

Test IM7

Code: Select all

magick identify -quiet -format "%[8BIM:1999,2998:#1]" \
-density 95 218755504_HOV_EPS.eps  |\
magick -density 150 218755504_HOV_EPS.eps \
-profile /Users/fred/images/profiles/sRGB.icc -set option:dim "%wx%h" \
\( - -alpha off -channel red -separate -negate \
-background black -gravity northwest -extent "%[dim]" \
+write mask7c.png \) \
-alpha off -compose copy_opacity -composite \
result7c.png

But for IM 6, setting the density to 95, still causes problems. First the mask is red and should not be. Second, I had to play around with the extent to make it work reasonably, but the result is clipped a bit at the bottom.

IM6

Test1 -- using the extent define by a density of 150 -- mask and image are different sizes

Code: Select all

convert -density 150 218755504_HOV_EPS.eps -format "%wx%h" info:
238x585

identify -quiet -format "%[8BIM:1999,2998:#1]" \
-density 95 218755504_HOV_EPS.eps  |\
convert -density 150 218755504_HOV_EPS.eps \
-profile /Users/fred/images/profiles/sRGB.icc \
\( - -alpha off -channel red -separate -negate \
-background black -gravity northwest -extent 238x535 \
+write mask6c.png \) \
-alpha off -compose copy_opacity -composite \
result6c.png

Test2 -- removing -extent -- mask and image are still different sizes

Code: Select all

identify -quiet -format "%[8BIM:1999,2998:#1]" \
-density 95 218755504_HOV_EPS.eps  |\
convert -density 150 218755504_HOV_EPS.eps \
-profile /Users/fred/images/profiles/sRGB.icc \
\( - -alpha off -channel red -separate -negate \
+write mask6d.png \) \
-alpha off -compose copy_opacity -composite \
result6d.png

Test3 -- using -extent for the size of the previous test2 mask image

Code: Select all

identify -quiet -format "%[8BIM:1999,2998:#1]" \
-density 95 218755504_HOV_EPS.eps  |\
convert -density 150 218755504_HOV_EPS.eps \
-profile /Users/fred/images/profiles/sRGB.icc \
\( - -alpha off -channel red -separate -negate \
-background black -gravity northwest -extent 235x579 \
+write mask6e.png \) \
-alpha off -compose copy_opacity -composite \
result6e.png

Can someone else test IM 6.9.8.4 using Inkscape and RSVG to see if the mask is red and cyan and not properly B/W

[fmw42]

I think the above approach is too complicated and it seems that a simpler approach at viewtopic.php?f=3&t=31846#p145593 works very well.