Page 1 of 1
Possible bug IM 7 with EPS clip path
Posted: 2017-04-06T11:10:32-07:00
by 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?
Re: Possible bug IM 7 with EPS clip path
Posted: 2017-04-17T10:28:43-07:00
by 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.
Re: Possible bug IM 7 with EPS clip path
Posted: 2017-04-17T12:20:02-07:00
by 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.
fmw42 wrote:2. inkscape: 96
As far as I know, Inkscape's default density is 90 dpi, which is the SVG standard.
Re: Possible bug IM 7 with EPS clip path
Posted: 2017-04-17T13:22:10-07:00
by 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)
Re: Possible bug IM 7 with EPS clip path
Posted: 2017-04-18T14:37:36-07:00
by fmw42
snibgo wrote: ↑2017-04-17T12:20:02-07:00
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.
Re: Possible bug IM 7 with EPS clip path
Posted: 2017-04-18T15:09:06-07:00
by 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.
Re: Possible bug IM 7 with EPS clip path
Posted: 2017-04-18T17:00:49-07:00
by 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.
Re: Possible bug IM 7 with EPS clip path
Posted: 2017-04-18T18:04:47-07:00
by 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:
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.
Re: Possible bug IM 7 with EPS clip path
Posted: 2017-04-26T16:43:39-07:00
by 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
Re: Possible bug IM 7 with EPS clip path
Posted: 2017-04-26T17:45:01-07:00
by magick
It works best with inkscape and a density of 96. With RSVG, we got expected results with a density of 95.
Re: Possible bug IM 7 with EPS clip path
Posted: 2017-04-26T19:02:10-07:00
by fmw42
magick wrote: ↑2017-04-26T17:45:01-07:00
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
Re: Possible bug IM 7 with EPS clip path
Posted: 2017-04-27T09:08:15-07:00
by 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.