Legacy ImageMagick Discussions Archive

Hi there,

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"):

Code: Select all

convert.exe test.jpg -alpha set -channel alpha -clip -negate test.png
convert.exe test.png -channel Alpha -negate test2.png

Any ideas?

I get the same result all the way back to IM 6.8.9.8. I cannot test much before that.

Code: Select all

im6898 convert test.jpg -alpha set -channel alpha -clip -negate test.png

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 can render just the clip path:

Code: Select all

identify -quiet -format "%[8BIM:1999,2998:#1]" bike2.jpg >bike_clip.svg

convert bike_clip.svg bike_clip.png

convert bike_clip.svg -resize 600 bike_clip.png

This explains why the result looks weird.

If it looks fine in Photoshop, then IM may have a bug that a developer would need to investigate.

From what snibgo says, as a guess, I would say that IM was taking the abs value of the clip path values rather than clipping it to the image bounds.

Thanks for investigating. I guess we have to wait for an developer to resolve this issue? Or do you have any ideas for a workaround?

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?

Code: Select all

<path fill-rule="evenodd" style="fill:#00000000;stroke:#00000000;stroke-width:0;stroke-antialiasing:false" d="
M -191.927 -239.927
C 1679.17 -239.927 3550.83 -239.927 5421.94 -239.927
C 5421.94 946.259 -191.927 931.598 -191.927 -239.927 Z
M 5269.99 2554.22
C 5269.33 2555.55 5268.66 2556.89 5267.99 2558.22
C 5270.03 2556.13 5270.88 2556.85 5269.99 2554.22 Z
M 5401.94 2684.18
C 5403.93 2686.83 5403.07 2686.14 5406.94 2687.18
C 5407.27 2686.51 5407.61 2685.85 5407.94 2685.18
C 5407.94 2684.85 5407.94 2684.51 5407.94 2684.18
C 5405.94 2684.18 5403.94 2684.18 5401.94 2684.18 Z
....

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've hacked together a program to dump the contents of 8BIM, ignoring IM entirely and using only information from http://www.adobe.com/devnet-apps/photos ... 7409_16000

My program gives the same numbers for the coordinates as IM gives in the SVG. My suspicion "that IM is mis-reading the 8BIM data" was wrong.

My program doesn't generate SVG, so I haven't yet looked closely at that aspect.

Here are the first few lines from my hack, for the bicycle image. My hack gives coordinates in (y,x) order, as they are in the JPG file.

Code: Select all

8 [56]BIM resourceID = 1028 IPTC-NAA
len = 85 Skip 85 bytes
8 [56]BIM resourceID = 1061 Caption digest
len = 16 Skip 16 bytes
8 [56]BIM resourceID = 749 unk
len = 16 Skip 16 bytes
8 [56]BIM resourceID = 1062 Print scale
len = 14 Skip 14 bytes
8 [56]BIM resourceID = 1037 Global Angle
len = 4 Skip 4 bytes
8 [56]BIM resourceID = 1049 Global Altitude
len = 4 Skip 4 bytes
8 [56]BIM resourceID = 755 unk
len = 9 Skip 9 bytes
8 [56]BIM resourceID = 1034 Copyright flag
len = 1 Skip 1 bytes
8 [56]BIM resourceID = 10000 Print flags
len = 10 Skip 10 bytes
8 [56]BIM resourceID = 757 unk
len = 72 Skip 72 bytes
8 [56]BIM resourceID = 760 unk
len = 112 Skip 112 bytes
8 [56]BIM resourceID = 1032 Grid and guides
len = 16 Skip 16 bytes
8 [56]BIM resourceID = 1054 URL List
len = 4 Skip 4 bytes
8 [56]BIM resourceID = 1050 Slices
len = 837 Skip 837 bytes
8 [56]BIM resourceID = 1064 Pixel Aspect Ratio
len = 12 Skip 12 bytes
8 [56]BIM resourceID = 1044 Document-specific IDs seed number
len = 4 Skip 4 bytes
8 [56]BIM resourceID = 1036 Thumbnail resource
len = 6146 Skip 6146 bytes
8 [56]BIM resourceID = 1057 Version Info
len = 85 Skip 85 bytes
8 [56]BIM resourceID = 1744 unk
Path 1len = 96434 nRecs=3709
  selector = 6 path fill rule Skip 24 bytes
  selector = 8 initial fill Skip 24 bytes
  selector = 3 open len=2 Skip 22 bytes
  selector = 5   open knot unlinked 931.598 -191.927 -239.927 -191.927 -239.927 1679.17 Skip 0 bytes
  selector = 5   open knot unlinked -239.927 3550.83 -239.927 5421.94 946.259 5421.94 Skip 0 bytes
  selector = 0 closed len=2 Skip 22 bytes
  selector = 2   closed knot unlinked 2556.85 5270.88 2554.22 5269.99 2555.55 5269.33 Skip 0 bytes
  selector = 2   closed knot unlinked 2556.89 5268.66 2558.22 5267.99 2556.13 5270.03 Skip 0 bytes
  selector = 0 closed len=4 Skip 22 bytes
  selector = 2   closed knot unlinked 2684.18 5403.94 2684.18 5401.94 2686.83 5403.93 Skip 0 bytes
  selector = 2   closed knot unlinked 2686.14 5403.07 2687.18 5406.94 2686.51 5407.27 Skip 0 bytes
  selector = 2   closed knot unlinked 2685.85 5407.61 2685.18 5407.94 2684.85 5407.94 Skip 0 bytes
  selector = 2   closed knot unlinked 2684.51 5407.94 2684.18 5407.94 2684.18 5405.94 Skip 0 bytes

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.

Here is the SVG for your info: https://members.zeg.com/Downloads/Image ... ported.svg

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.

Many thanks for that. I'm out of time at the moment, but I'll look at that and compare it to the IM SVG, and my dump program.

The scale in exported.svg is difference to bike.jpg, and the SVG uses both absolute and relative coordinates, so the comparison process isn't trivial.

Yes, your SVG starts with a move to (0,0), and that's not in bike.jpg. Weird.

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.

Hi snibgo,

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.

Code: Select all

bike.jpg -> Adobe CS2 -> "Export" -> "Pathes -> Illustrator..." -> bike.ai
bike.ai -> Illustrator -> "Save as..." -> bike.svg

Here is the file. I hope this helps comparing: https://members.zeg.com/Downloads/Images/IM/bike.svg

I added the following stylesheet to make the path visible. This was the only change I made.

Code: Select all

<style type="text/css">
	path {stroke:black;stroke-width:1;fill:none;}
</style>

Mmm, thanks. Aside from the first point, it is very similar to "exported.svg" you showed earlier, but at a slightly different scale.

exported.svg has viewport 1347.8 x 898.6
this bike.svg has viewport 1260.96 x 786

But bike.jpg is 5254x3275 pixels.

Legacy ImageMagick Discussions Archive

Bug: Crop by clipping path

Bug: Crop by clipping path

Re: Bug: Crop by clipping path

Re: Bug: Crop by clipping path

Re: Bug: Crop by clipping path

Re: Bug: Crop by clipping path

Re: Bug: Crop by clipping path

Re: Bug: Crop by clipping path

Re: Bug: Crop by clipping path

Re: Bug: Crop by clipping path

Re: Bug: Crop by clipping path

Re: Bug: Crop by clipping path

Re: Bug: Crop by clipping path

Re: Bug: Crop by clipping path

Re: Bug: Crop by clipping path

Re: Bug: Crop by clipping path