Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
we have the following image which is an JPEG with an clipping path:
(Note: This scaled example image actually have no clipping path because the server remove it before sending. Please use following image for testing purposes: Orignal image with clipping path)
We use ImageMagick to crop this image by it's clipping path. But in this image (and a few other images too) the result looks strange:
We reviewed the clipping path in adobe photoshop and it's fine - no sign for the ellipse at the top.
These are the batch commands we use on Windows (ImageMagick-7.0.1-9-Q8-x64) to convert the JPEG to clipped PNG (source file is "test.jpg"):
With "identify -verbose", we can see the clip path. We can see it contains coordinates that are outside the image. Within the first few, we have negative x- and y-coordinates. So the path (as seen by ImageMagick) is weird.
We bypass ImageMagick by directly exacting the SVG clipping path to a separate file. We render the SVG file with Firefox, inkscape, and KSVG and they all render with the ellipse at the top. We can't speak to what Photoshop is doing, but ImageMagick is behaving as expected. It is honoring the clip path precisely as described by the SVG script.
@magick, just curious: how were you able to extract the svg without using ImageMagick? I tried this before I posted here, but I was not able to find a way without ImageMagick.
magick wrote:We bypass ImageMagick by directly exacting the SVG clipping path to a separate file. We render the SVG file with Firefox, inkscape, and KSVG and they all render with the ellipse at the top. We can't speak to what Photoshop is doing, but ImageMagick is behaving as expected. It is honoring the clip path precisely as described by the SVG script.
As snibgo pointed out earlier the first few lines of the clip path contain negative values. Might this be causing the problem if IM (or the svg renderer) does not treat them properly?
The SVG created by ImageMagick is valid SVG. The first three lines cause the ellipse, which is correctly rendered. But I suspect the ellipse shouldn't be present.
I suspect that IM is mis-reading the 8BIM data, perhaps in property.c function Get8BIMProperty().
I asked our designer to export the clipping path from photoshop to an SVG. There is also the 0,0 Point. But when I open the file in a browser there is no ellipse (but a straight line) at the top.
It also seems quite different than the SVG that ImageMagick is extracting from 8bim. This may be credited to tha 8bim definition - I'm not an expert in this.
The problem is clearly caused by the image's 0,0 point. I asked our designers to remove this point and I guess the problem will shortly be solved for us. Thanks to all of you for investigating and helping us.
Last edited by eurorad.dob on 2016-06-15T02:38:39-07:00, edited 1 time in total.
I've done more hacking, comparing the SVG that IM outputs from the clippath in the OP jpeg "Orignal image with clipping path" with the file "exported.svg" posted by eurorad.dob.
Except for the first segment, they are pretty much the same. exported.svg is at a smaller scale than the jpeg, and the coordinates also seem to have an offset compared to the jpeg. But the SVG is substantially the same.
The only real difference is the first segment, which is an ellipse in bike.jpg and a straight line in bike.svg.
The difference in scale suggests that exported.svg was not created from bike.jpg, and this also explains the difference in the first segment.
If someone can produce a jpeg with a complex clipping path and the SVG created by Photoshop from that actual jpeg, I can compare the PS and IM results.
For now, my conclusion is that IM is doing nothing wrong.
I don't know what our designer exactly did. But now I was able to export the clipping path to an SVG on my own from the original bike.jpg without rescale or anything.
