Maybe it's possible to temporarily disable the usage of rsvg in the ImageMagick configuration files? I don't know..
If you plan to disable rsvg completely, then perhaps you just have to delete the rsvg libraries on the Unix server (if that's ok in your case) and then re-install ImageMagick. But I don't use Unix, so someone else should give the hints.
But before you try this, you might update the rsvg libraries first (I think, the latest version is 2.31?) and see if the error maybe disappears in this latest version.
Another workaround would be to extract the clipping path from files where rsvg has a problem. Then you can use 'MSVG:' to read that file and create a mask out of this. But I don't know if you want to use a difficult method like this.
Possible bug: partial clipping-path on jpg & tiff
Re: Possible bug: partial clipping-path on jpg & tiff
Report this problem as a bug to the RSVG project. To verify, extract the clip path from
- identify -verbose 069415A1.jpg
- display clip.svg msvg:clip.svg
Re: Possible bug: partial clipping-path on jpg & tiff
Ahh, hello people with my problem
I might be able to narrow down this problem a bit. Check this out:
Notice the difference in versions (6.5.7 vs 6.2.4).
In the four examples, the "current server" fails in example #1 and #4.
In column "Clipping path orientation" (didn't know what else to call it) you see how the clipping paths are created.
"right / right" means that both the outer and the inner clipping path are created clock wise.
"right / left " means that the outer clipping path is created clock wise and that the inner path is created counter clock wise
Etc ...
So - this fails when the clipping paths are created in the same way. Makes no sense, I know.
We also found out that if you edit the clipping path (with PhotoShop) - delete a point and create it again - the problem magically vanishes.
Both are Linux servers.
Getting quite desperate to solve this ... and would hate to roll back to ver. 6.2.something ...
Regards,
Nik
I might be able to narrow down this problem a bit. Check this out:
Notice the difference in versions (6.5.7 vs 6.2.4).
In the four examples, the "current server" fails in example #1 and #4.
In column "Clipping path orientation" (didn't know what else to call it) you see how the clipping paths are created.
"right / right" means that both the outer and the inner clipping path are created clock wise.
"right / left " means that the outer clipping path is created clock wise and that the inner path is created counter clock wise
Etc ...
So - this fails when the clipping paths are created in the same way. Makes no sense, I know.
We also found out that if you edit the clipping path (with PhotoShop) - delete a point and create it again - the problem magically vanishes.
Both are Linux servers.
Getting quite desperate to solve this ... and would hate to roll back to ver. 6.2.something ...
Regards,
Nik
Re: Possible bug: partial clipping-path on jpg & tiff
Ah, didn't see this post until now. But great - will try to use the MSVG-renderer!magick wrote:Report this problem as a bug to the RSVG project. To verify, extract the clip path from
and put it into clip.svg. Next type
- identify -verbose 069415A1.jpg
notice how the cup handle is transparent when using the MSVG renderer (internal to ImageMagick) verses the RSVG renderer where the handle is not transparent (suggesting a bug in RSVG).
- display clip.svg msvg:clip.svg
Thanks,
Nik
Re: Possible bug: partial clipping-path on jpg & tiff
I have the same Problem right now, @have did you manage to change your command line so that MSVG is used?
I will try updating rsvg from 2.16 to 2.31 tommorrow too and will report back.
I will try updating rsvg from 2.16 to 2.31 tommorrow too and will report back.
Re: Possible bug: partial clipping-path on jpg & tiff
Nope for the time i can't update librsvg.
I'm running ImageMagick without rsvg support for now.
Can anyone else confirm if this Problem is fixed in librsvg 2.31?
I'm running ImageMagick without rsvg support for now.
Can anyone else confirm if this Problem is fixed in librsvg 2.31?
Re: Possible bug: partial clipping-path on jpg & tiff
No. I have my server at a hosting company, and I asked them to recompile ImageMagick to use the MSVG renderer. They replied back that they deactivated RSVG and rebuilt IM. This worked, but I don't know if you can force it from the command line to use MSVG ...zaratol wrote:I have the same Problem right now, @have did you manage to change your command line so that MSVG is used?
Re: Possible bug: partial clipping-path on jpg & tiff
I tested today with librsvg 2.32.0-1 the Problem is still therezaratol wrote:Nope for the time i can't update librsvg.
I'm running ImageMagick without rsvg support for now.
Can anyone else confirm if this Problem is fixed in librsvg 2.31?
Could someone with more experience posts this issue?
The reason: Out of curiosity i tried the extracted svg path (identify -verbose 069415A1.jpg -> clip.svg) in different Browsers.
Opera 11.0 and Firefox 3..6.13 both display the svg File wrong so it seems a rather common problem. Maybe someone with knowlegde of MSVG internals could point in the right direction
Or maybe this is not a rsvg Bug at all and PS is saving the path information in some non standard way, it would not be the first Time, because even Illustrator CS4 does not like the cup Handle : http://home.arcor.de/durius.obsidian/Il ... ipping.PNG (Screen of clip.svg)
One last Question on this Toppic: How exactly is the Path Information extracted? In the svg code i can only see one closed Path Element. The Second closed Path visible in the Picture is decribed by a Move. Should there be not one Path Element for every closed Path of the Original Document? (SVG: http://home.arcor.de/durius.obsidian/clip.svg
Re: Possible bug: partial clipping-path on jpg & tiff
After some further Reading the not so pleasent conclusion:
RSVG is right, MSVG is not. Do get a hole the subpath MUST be in the opposite direction http://osdir.com/ml/text.xml.svg.devel/ ... 00223.html That what have describes with his screenshots (the colored alarm-clock) is actually correct svg rendering.
The Cup in svg-code should look like this : http://home.arcor.de/durius.obsidian/clip2.svg so that it is rendered correctly.
So different Question: Does save PS the Information "wrong"? Is it possible to workaround Photoshop in the Path-SVG Extraction?
On a side-note: In PS it is not possible to create a clipping-path where 2 path-items have a common area, the path elements always excludes each other.
RSVG is right, MSVG is not. Do get a hole the subpath MUST be in the opposite direction http://osdir.com/ml/text.xml.svg.devel/ ... 00223.html That what have describes with his screenshots (the colored alarm-clock) is actually correct svg rendering.
The Cup in svg-code should look like this : http://home.arcor.de/durius.obsidian/clip2.svg so that it is rendered correctly.
So different Question: Does save PS the Information "wrong"? Is it possible to workaround Photoshop in the Path-SVG Extraction?
On a side-note: In PS it is not possible to create a clipping-path where 2 path-items have a common area, the path elements always excludes each other.
Re: Possible bug: partial clipping-path on jpg & tiff
So after some more reading:
as i understand it so far ImageMagick reads not all available data on saved PathInformation: Attention much speculation on my part
Please correct me if i'm wrong:
-ImageMagick does it's own PS-Pathextraction in property.c (TracePSClippath) the extraction is commented with:
"The clipping path format is defined in "Adobe Photoshop File
Formats Specification" version 6.0 downloadable from adobe.com."
Currently the Format Specification is avaiable: http://www.adobe.com/devnet/photoshop.html
In the specification a sample Plugin is mentionend, the "IllustratorExport". Photoshop has an Option for exporting PathInformation to Illustrator (File->Export->Path to Illustrator)
This saves the Pathinfomation as Postscript/AI, for Example the Cup as exported File: http://home.arcor.de/durius.obsidian/069415A1.ai Notice how the 2 Subpathes are extracted and treated separately with notion of how the PathInfomation should be merged. So i think all necessary Path-Informations are available.
Unfortunately i'm not even close to understanding how the Path extraction currently works in ImageMagick or in the IllustratorExport Plugin. If someone else is willing to spend some time on this, the PS IllustratorExport Plugin sample Plugin can be found within the PS CS2 SDK
I know this is a longshot and not something quick to fix, but please review the Path extraction and svg generation
as i understand it so far ImageMagick reads not all available data on saved PathInformation: Attention much speculation on my part
Please correct me if i'm wrong:
-ImageMagick does it's own PS-Pathextraction in property.c (TracePSClippath) the extraction is commented with:
"The clipping path format is defined in "Adobe Photoshop File
Formats Specification" version 6.0 downloadable from adobe.com."
Currently the Format Specification is avaiable: http://www.adobe.com/devnet/photoshop.html
In the specification a sample Plugin is mentionend, the "IllustratorExport". Photoshop has an Option for exporting PathInformation to Illustrator (File->Export->Path to Illustrator)
This saves the Pathinfomation as Postscript/AI, for Example the Cup as exported File: http://home.arcor.de/durius.obsidian/069415A1.ai Notice how the 2 Subpathes are extracted and treated separately with notion of how the PathInfomation should be merged. So i think all necessary Path-Informations are available.
Unfortunately i'm not even close to understanding how the Path extraction currently works in ImageMagick or in the IllustratorExport Plugin. If someone else is willing to spend some time on this, the PS IllustratorExport Plugin sample Plugin can be found within the PS CS2 SDK
I know this is a longshot and not something quick to fix, but please review the Path extraction and svg generation