Page 1 of 1
Should Photoshop pathes always considered "even-odd"
Posted: 2014-07-08T09:42:18-07:00
by zaratol
While drawing path Elements with Photoshop you can choose how path-elements should interact with each other.
The default choice is "Exclude Overlapping Shapes" which is the same as drawing svg pathes with even-odd rule.
So for example in Photoshop i could draw a whole while drawing both path items in clockwise directions
http://home.arcor.de/durius.obsidian/path1test.tif Photoshop Path Display:
Path Extraction with Imagemagick:
convert -version
Version: ImageMagick 6.8.9-5 Q16 x86_64
identify -format '%[8BIM:1999,2998:#1]' path1test.tif
Code: Select all
<?xml version="1.0" encoding="iso-8859-1"?>
<svg width="400" height="400">
<g>
<path style="fill:#00000000;stroke:#00000000;stroke-width:0;stroke-antialiasing:false" d="
M 59.055 59.055
L 354.33 59.055
L 354.33 354.33
L 59.055 354.33
L 59.055 59.055 Z
M 118.11 118.11
L 295.275 118.11
L 295.275 295.275
L 118.11 295.275
L 118.11 118.11 Z
"/>
</g>
</svg>
which will result in a svg with no Hole. So now some people might say you have to draw the inner path counter clockwise to get a hole, but this is only true when drawing svg pathes, but not for photoshop.
Btw the official File Format Specification
http://www.adobe.com/devnet-apps/photos ... 7409_17587 states:
2 byte fill rule. 0 = same fill rule, 1 = even odd fill rule, 2 = non zero winding fill rule. The fill rule is ignored by Photoshop.
Well obviously the fill rule is correctly applied by photoshop so Adobe and documentation...
A simple addition of "fill-rule="evenodd"" to the svg path would solve that issue and would be "more" correct for the most use Cases.
Of course that does not work with any other option i could choose in Photoshop for path interaction but to read the stored information AND write proper svg is much more complicated.
So i propose at least add some option for that flag
Re: Should Photoshop pathes always considered "even-odd"
Posted: 2014-07-08T09:47:10-07:00
by fmw42
A simple addition of "fill-rule="evenodd"" to the svg path would solve that issue and would be "more" correct for the most use Cases.
Is this then an SVG issue if you want to add that to the SVG file? I believe IM already expects alternate directions for such paths. However, I am neither an SVG nor a path expert.
The developers or some other more experience IM user would really need to comment.
Re: Should Photoshop pathes always considered "even-odd"
Posted: 2014-07-08T10:01:48-07:00
by zaratol
IM already expects alternate directions for such path
That is exactly my point, for Photoshop it does not matter how you draw your pathes, if you don't change the settings it will always apply the fill-rule "even-odd"
So from my point of view if photoshop pathes are read the resulting svg should also have the atrribute "fill-rule="evenodd"
Re: Should Photoshop pathes always considered "even-odd"
Posted: 2014-07-08T10:07:00-07:00
by fmw42
zaratol wrote:IM already expects alternate directions for such path
That is exactly my point, for Photoshop it does not matter how you draw your pathes, if you don't change the settings it will always apply the fill-rule "even-odd"
So from my point of view if photoshop pathes are read the resulting svg should also have the atrribute " IM already expects alternate directions for such path"
This is not an IM issue as far as I can tell. You should request that on an SVG forum. Correct me if I am wrong about this and explain further.
What is your exact IM command? Can you post your input file?
What SVG delegate are you using in IM. Perhaps you should use or upgrade to Inkscape or RSVG.
convert -list format
will tell you what delegate is being used. Here is mine.
SVG SVG rw+ Scalable Vector Graphics (RSVG 2.40.2)
SVGZ SVG rw+ Compressed Scalable Vector Graphics (RSVG 2.40.2)
Re: Should Photoshop pathes always considered "even-odd"
Posted: 2014-07-08T10:09:42-07:00
by zaratol
No, because ImageMagick is repsonsible for reading the stored 8bim recource and converting the stored information into a svg path.
From my point of view this conversion should add the attribute "fill-rule="evenodd"" because that is the default fill rule of photohop
Re: Should Photoshop pathes always considered "even-odd"
Posted: 2014-07-08T10:11:12-07:00
by fmw42
IM uses a delegate library for SVG. Perhaps you should check what delegate you are using and what version. See my edited post above.
Re: Should Photoshop pathes always considered "even-odd"
Posted: 2014-07-08T10:26:31-07:00
by snibgo
IM creates the SVG. It seems to me that IM could insert fill-rule=evenodd, taking its value from a "-define" or "-set". See
http://www.w3.org/TR/SVG/painting.html#FillRuleProperty
Re: Should Photoshop pathes always considered "even-odd"
Posted: 2014-07-08T10:30:50-07:00
by zaratol
Yes,
the resulting svg in my example could look like this:
Code: Select all
<?xml version="1.0" encoding="iso-8859-1"?>
<svg width="400" height="400">
<g>
<path fill-rule="evenodd" style="fill:#00000000;stroke:#00000000;stroke-width:0;stroke-antialiasing:false" d="
M 59.055 59.055
L 354.33 59.055
L 354.33 354.33
L 59.055 354.33
L 59.055 59.055 Z
M 118.11 118.11
L 295.275 118.11
L 295.275 295.275
L 118.11 295.275
L 118.11 118.11 Z
"/>
</g>
</svg>
Re: Should Photoshop pathes always considered "even-odd"
Posted: 2014-07-08T11:14:22-07:00
by snibgo
Yes. (This is for SVG code created by IM for paths, and not editable by users.)
There are 2 possible values: "nonzero" or "evenodd". The current effect is "nonzero". A user-option to change this would be good.
I only recently discovered that IM creates the SVG. As it does create the SVG, I expect this is easy, but a developer would need to comment.
I'm less sure that the change should be automatic when the input is PSD. IM can use multiple inputs, and behaviour needs to be well-defined and understandable when only one of these is PSD.
Re: Should Photoshop pathes always considered "even-odd"
Posted: 2014-07-08T12:24:34-07:00
by dlemstra
We could also check if the 8BIM ID with the value 1057 is available before the clip path. This contains the name of the writer. If it was written by Photoshop we can assume the fill-rule should be evenodd. But I am not sure if this is valid for all versions of Photoshop.
Re: Should Photoshop pathes always considered "even-odd"
Posted: 2014-07-16T02:56:31-07:00
by zaratol
What about reading the first fill-rule info or giving a new user Option?
Re: Should Photoshop pathes always considered "even-odd"
Posted: 2014-07-16T03:22:20-07:00
by dlemstra
I think there should be a way to determine which fill rule should be used. I don't have Photoshop so can you post a link to two identical images where one path is saved with "nonzero" and the other one with "evenodd". The difference between the images might help me with the correct way to detect the fill rule.
Re: Should Photoshop pathes always considered "even-odd"
Posted: 2014-07-17T03:25:55-07:00
by zaratol
So i created sample File
http://home.arcor.de/durius.obsidian/pathExample.tif
i drew in total 5 Pathes:
- Pfad 1: ""Exclude Overlapping Shapes" -> SVG even-odd fill rule
- Pfad 2: "Intersect Shape Areas"
- Pfad 3: "Substract Front Shape"
- Pfad 4: "Combine Shapes"
- Pfad 5: Combination of all Options
I tried my very best do always daw the same shape
Photoshop View:
I also used the Photoshop integrated Tool "Export path to Postscript"; Result:
http://home.arcor.de/durius.obsidian/pathExample.ai
If you really want to go down the Rabbit Hole, the export Plugin is available in Photoshop SDK CS2
http://download.macromedia.com/pub/deve ... SDKWin.zip
Re: Should Photoshop pathes always considered "even-odd"
Posted: 2014-07-19T02:04:01-07:00
by dlemstra
According to the specifications of Adobe (
http://www.adobe.com/devnet-apps/photos ... 7409_17587) the fill-rule should be evenodd:
The first 26-byte path record contains a selector value of 6, path fill rule record. The remaining 24 bytes of the first record are zeroes. Paths use even/odd ruling.
This will be fixed in the next release of ImageMagick (6.8.9-6).
After researching your file I figured out how Adobe stores the different types but this does not appear to be documented:
#1
00 00 04 00
00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
#2
00 00 04 00
03 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
#3
00 00 04 00
02 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
#4
00 00 04 00
01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
And
#5 contains a combination of this. The only problem is that this is an undocumented feature. The specification states the following:
Subpath length records, selector value 0 or 3, contain the number of Bezier knot records in bytes 2 and 3. The remaining 22 bytes are unused, and should be zeroes.
The first byte is the subpath selector (00) and byte 2-3 contain the number of paths (04 00). The rest should be zero but it seems Photoshop uses a number as the 4th byte (maybe also the 5th?) to store the type of your path. At this moment I don't know how I should use this number to modify the svg we generate. If anyone who reads this knows where we can find documentation how we should handle this extra number to generate the path please let us know and we can apply a patch for this.