Dear Inkscape Developers,
I added a few features to Inkscape for use in embroidery, because the commercial tools available don't offer the artistic flexibility I want. I would like to have your opinion on if you think it makes sense to integrate such functionality into the Inkscape mainline, or if it would be too much of a stretch. It boils down to some LPEs and an export format. The commercial tool I have from Bernina (a Swiss sewing machine manufacturer) is based on Corel Draw.
Below is a list of the additions I did / I am working on.
Please let me know what you think about this. With these additions, Inkscape offers substantially more flexibility than affordable commercial SW (and affordable here means 500..1000$).
Best regards,
Michael
1.) Ways to fill an area with clusters of contours
Inkscape already offers 2 path interpolation LPEs which allow this. I plan to add a 3rd one which creates a set of equidistant inset/outset paths.
2.) A way to connect sub path of a path into one continuous path
I added an LPE to do this with various options of end interpolation. Maybe if I use bool-ops I need to extend it with some sort of sorting, cutting and auto reversing mechanism to keep the connections short.
3.) A way to cut a path into stitches (straight line segments) in a controlled way.
I added an LPE to do this, but it is quite primitive as yet.
4.) Bool ops on paths because in embroidery you cannot simply hide an object below another one.
I just added a bool-op LPE for this - needs some additional work to cut contours against a closed path.
5.) A tool to convert graphics output to some format an embroidery / sewing machines can read.
I wrote an external tool to convert HPGL to a common embroidery format (stitch/DST), but could also integrate this into Inkscape.
6.) Maybe a tool to hide connections between path segments below filled areas. For a sewing machine it is quite complicated to do a "pen up" - it has to cut the threads, so one typically hides connection paths below some embroidery to avoid thread cutting.
Currently I do this semi-manually. Doing this automatically might be quite complicated.
This sounds awesome, Michael!
I'm not a developer, so I can't help much with your questions about programming. But I have a general question.
Are these improvements meant to create designs to embroider (like back in the day, when you could buy a design already stamped on the fabric, like in a kit)? Or is this for embroidery machines? (Or I guess these days it's embroidery software on the sewing machine?)
Thanks :-)
-------------------------------------------------- From: "Michael Soegtrop" <MSoegtrop@...889...> Sent: Saturday, February 27, 2016 7:39 AM To: inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] Inkscape for embroidery
Dear Inkscape Developers,
I added a few features to Inkscape for use in embroidery, because the commercial tools available don't offer the artistic flexibility I want. I would like to have your opinion on if you think it makes sense to integrate such functionality into the Inkscape mainline, or if it would be too much of a stretch. It boils down to some LPEs and an export format. The commercial tool I have from Bernina (a Swiss sewing machine manufacturer) is based on Corel Draw.
Below is a list of the additions I did / I am working on.
Please let me know what you think about this. With these additions, Inkscape offers substantially more flexibility than affordable commercial SW (and affordable here means 500..1000$).
Best regards,
Michael
1.) Ways to fill an area with clusters of contours
Inkscape already offers 2 path interpolation LPEs which allow this. I plan to add a 3rd one which creates a set of equidistant inset/outset paths.
2.) A way to connect sub path of a path into one continuous path
I added an LPE to do this with various options of end interpolation. Maybe if I use bool-ops I need to extend it with some sort of sorting, cutting and auto reversing mechanism to keep the connections short.
3.) A way to cut a path into stitches (straight line segments) in a controlled way.
I added an LPE to do this, but it is quite primitive as yet.
4.) Bool ops on paths because in embroidery you cannot simply hide an object below another one.
I just added a bool-op LPE for this - needs some additional work to cut contours against a closed path.
5.) A tool to convert graphics output to some format an embroidery / sewing machines can read.
I wrote an external tool to convert HPGL to a common embroidery format (stitch/DST), but could also integrate this into Inkscape.
6.) Maybe a tool to hide connections between path segments below filled areas. For a sewing machine it is quite complicated to do a "pen up" - it has to cut the threads, so one typically hides connection paths below some embroidery to avoid thread cutting.
Currently I do this semi-manually. Doing this automatically might be quite complicated.
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 02/27/2016 03:39 PM, Michael Soegtrop wrote:
I added a few features to Inkscape for use in embroidery, because the commercial tools available don't offer the artistic flexibility I want.
I'm not exactly an Inkscape developer but I would love to see embroidery functions integrated into Inkscape.
Did you create a branch on Launchpad where I can see your code? I'd like to test it and possibly contribute to it. I also struggle with my embroidery software and resorted to writing a little helper program which removes stitches which are too short for the machine and add undersewing to zig zag stitches.
Best Regards, Alexander
Hey Michael,
Yes, I personally think this would make sense to add directly into Inkscape. We already have Gcodetools extensions in trunk (which is "special case" like embroidery), so to me it seems like it would be a great fit to extend the functionality of Inkscape to include this.
Do you have your code hosted anywhere online for other to take a look at and/or test?
Cheers, Josh
On Sat, Feb 27, 2016 at 6:39 AM, Michael Soegtrop <MSoegtrop@...889...> wrote:
Dear Inkscape Developers,
I added a few features to Inkscape for use in embroidery, because the commercial tools available don't offer the artistic flexibility I want. I would like to have your opinion on if you think it makes sense to integrate such functionality into the Inkscape mainline, or if it would be too much of a stretch. It boils down to some LPEs and an export format. The commercial tool I have from Bernina (a Swiss sewing machine manufacturer) is based on Corel Draw.
Below is a list of the additions I did / I am working on.
Please let me know what you think about this. With these additions, Inkscape offers substantially more flexibility than affordable commercial SW (and affordable here means 500..1000$).
Best regards,
Michael
1.) Ways to fill an area with clusters of contours
Inkscape already offers 2 path interpolation LPEs which allow this. I plan to add a 3rd one which creates a set of equidistant inset/outset paths.
2.) A way to connect sub path of a path into one continuous path
I added an LPE to do this with various options of end interpolation. Maybe if I use bool-ops I need to extend it with some sort of sorting, cutting and auto reversing mechanism to keep the connections short.
3.) A way to cut a path into stitches (straight line segments) in a controlled way.
I added an LPE to do this, but it is quite primitive as yet.
4.) Bool ops on paths because in embroidery you cannot simply hide an object below another one.
I just added a bool-op LPE for this - needs some additional work to cut contours against a closed path.
5.) A tool to convert graphics output to some format an embroidery / sewing machines can read.
I wrote an external tool to convert HPGL to a common embroidery format (stitch/DST), but could also integrate this into Inkscape.
6.) Maybe a tool to hide connections between path segments below filled areas. For a sewing machine it is quite complicated to do a "pen up" - it has to cut the threads, so one typically hides connection paths below some embroidery to avoid thread cutting.
Currently I do this semi-manually. Doing this automatically might be quite complicated.
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Dear Josh,
Yes, I personally think this would make sense to add directly into Inkscape.
very well. I think quite a few people would love to see this in Inkscape.
Do you have your code hosted anywhere online for other to take a look at and/or test?
not yet. The main purpose of my email was to discuss the best method to do this. I guess if you plan to integrate it, I should create an embroidery branch on launchpad, which means I would need permission to do so. I should say that I have close to 0 experience with bzr, but quite a bit with git and before with SVN, Clearcase & Co.
If you first want to check if I do reasonable quality code, I can of cause upload a patch e.g. on my website.
In case you want me to start on launchpad right away: my launchpad account name is MSoegtrop.
Best regards,
Michael
On 29.02.2016 04:41, Josh Andler wrote:
Hey Michael,
Yes, I personally think this would make sense to add directly into Inkscape. We already have Gcodetools extensions in trunk (which is "special case" like embroidery), so to me it seems like it would be a great fit to extend the functionality of Inkscape to include this.
Do you have your code hosted anywhere online for other to take a look at and/or test?
Cheers, Josh
On Sat, Feb 27, 2016 at 6:39 AM, Michael Soegtrop <MSoegtrop@...889...> wrote:
Dear Inkscape Developers,
I added a few features to Inkscape for use in embroidery, because the commercial tools available don't offer the artistic flexibility I want. I would like to have your opinion on if you think it makes sense to integrate such functionality into the Inkscape mainline, or if it would be too much of a stretch. It boils down to some LPEs and an export format. The commercial tool I have from Bernina (a Swiss sewing machine manufacturer) is based on Corel Draw.
Below is a list of the additions I did / I am working on.
Please let me know what you think about this. With these additions, Inkscape offers substantially more flexibility than affordable commercial SW (and affordable here means 500..1000$).
Best regards,
Michael
1.) Ways to fill an area with clusters of contours
Inkscape already offers 2 path interpolation LPEs which allow this. I plan to add a 3rd one which creates a set of equidistant inset/outset paths.
2.) A way to connect sub path of a path into one continuous path
I added an LPE to do this with various options of end interpolation. Maybe if I use bool-ops I need to extend it with some sort of sorting, cutting and auto reversing mechanism to keep the connections short.
3.) A way to cut a path into stitches (straight line segments) in a controlled way.
I added an LPE to do this, but it is quite primitive as yet.
4.) Bool ops on paths because in embroidery you cannot simply hide an object below another one.
I just added a bool-op LPE for this - needs some additional work to cut contours against a closed path.
5.) A tool to convert graphics output to some format an embroidery / sewing machines can read.
I wrote an external tool to convert HPGL to a common embroidery format (stitch/DST), but could also integrate this into Inkscape.
6.) Maybe a tool to hide connections between path segments below filled areas. For a sewing machine it is quite complicated to do a "pen up" - it has to cut the threads, so one typically hides connection paths below some embroidery to avoid thread cutting.
Currently I do this semi-manually. Doing this automatically might be quite complicated.
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hey Michael,
We're actually looking into switching to git. Perhaps Krzysztof can chime in and let us know what the status of things is. Honestly, it makes more sense if you spend more time working on actual code rather than learning a vcs that we're looking to move away from.
Cheers, Josh
On Mon, Feb 29, 2016 at 10:00 AM, Michael Soegtrop <MSoegtrop@...889...> wrote:
Dear Josh,
Yes, I personally think this would make sense to add directly into Inkscape.
very well. I think quite a few people would love to see this in Inkscape.
Do you have your code hosted anywhere online for other to take a look at and/or test?
not yet. The main purpose of my email was to discuss the best method to do this. I guess if you plan to integrate it, I should create an embroidery branch on launchpad, which means I would need permission to do so. I should say that I have close to 0 experience with bzr, but quite a bit with git and before with SVN, Clearcase & Co.
If you first want to check if I do reasonable quality code, I can of cause upload a patch e.g. on my website.
In case you want me to start on launchpad right away: my launchpad account name is MSoegtrop.
Best regards,
Michael
On 29.02.2016 04:41, Josh Andler wrote:
Hey Michael,
Yes, I personally think this would make sense to add directly into Inkscape. We already have Gcodetools extensions in trunk (which is
"special
case" like embroidery), so to me it seems like it would be a great fit to extend the functionality of Inkscape to include this.
Do you have your code hosted anywhere online for other to take a look at and/or test?
Cheers, Josh
On Sat, Feb 27, 2016 at 6:39 AM, Michael Soegtrop <MSoegtrop@...889...> wrote:
Dear Inkscape Developers,
I added a few features to Inkscape for use in embroidery, because the commercial tools available don't offer the artistic flexibility I want. I would like to have your opinion on if you think it makes sense to integrate such functionality into the Inkscape mainline, or if it would be too much of a stretch. It boils down to some LPEs and an export format. The commercial tool I have from Bernina (a Swiss sewing machine manufacturer) is based on Corel Draw.
Below is a list of the additions I did / I am working on.
Please let me know what you think about this. With these additions, Inkscape offers substantially more flexibility than affordable commercial SW (and affordable here means 500..1000$).
Best regards,
Michael
1.) Ways to fill an area with clusters of contours
Inkscape already offers 2 path interpolation LPEs which allow this. I plan to add a 3rd one which creates a set of equidistant inset/outset paths.
2.) A way to connect sub path of a path into one continuous path
I added an LPE to do this with various options of end interpolation. Maybe if I use bool-ops I need to extend it with some sort of sorting, cutting and auto reversing mechanism to keep the connections short.
3.) A way to cut a path into stitches (straight line segments) in a controlled way.
I added an LPE to do this, but it is quite primitive as yet.
4.) Bool ops on paths because in embroidery you cannot simply hide an object below another one.
I just added a bool-op LPE for this - needs some additional work to cut contours against a closed path.
5.) A tool to convert graphics output to some format an embroidery / sewing machines can read.
I wrote an external tool to convert HPGL to a common embroidery format (stitch/DST), but could also integrate this into Inkscape.
6.) Maybe a tool to hide connections between path segments below filled areas. For a sewing machine it is quite complicated to do a "pen up" - it has to cut the threads, so one typically hides connection paths below some embroidery to avoid thread cutting.
Currently I do this semi-manually. Doing this automatically might be quite complicated.
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Dear Josh,
We're actually looking into switching to git. Perhaps Krzysztof can chime in and let us know what the status of things is. Honestly, it makes more sense if you spend more time working on actual code rather than learning a vcs that we're looking to move away from.
Fine with me. Then I will publish it likely next weekend on my own web server as a patch. Since this are >99% new files, merging this shouldn't be an issue. I just wanted to adjust the stitching LPE so that it can handle the output of bool LPE before I publish it.
Best regards,
Michael
Dear Inkscape Developer-Team,
I just wanted to give an update on the embroidery functionality. Essentially it works, but there is one open end.
The open end is a function to reorder the cut pieces such that a minimal number of longer jumps is needed in between (jumps are expensive in embroidery because the thread needs to be cut and knot). This is essentially a traveling salesman problem with a few additional complexities.
1.) I don't connect points as in a usual TSP, but lines, and the tour needs to visit each line exactly once. This is similar to a usual TSP where pairs of cities have a 0 distance connection, but the difference is that I need a guarantee that the 0 distance paths are all taken. When I use a usual TSP algorithm, this is likely but not guaranteed.
2.) For performance reasons I collect groups of lines where both end points have a mutual nearest neighbor (think of a zig-zag pattern). This is a very common situation in embroidery patterns and cuts down the number of segments by more than a factor of 10, which is a substantial saving for a TSP algorithm. These zig-zag blocks results in block with 4 end points and 2 choices of 2 points. So I don't connect just lines, but this kind of blocks with 2 choices of endpoints.
3.) Since I usually want an open path, I can ignore the longest connection.
Points 1 and 2 work with something like a variable k "Lin" algorithm. Maybe later I will implement a Lin-Kernighan algorithm, if the Lin algorithm is too slow, but with k=3 it is quite fast (fraction of a second) even for quite complex patterns (29 zig zag blocks) and gives good results.
What I am struggling with is point 3, which is essential to get good results (or at least I believe so). I thought this would be easy, but it is either slow or results in complex book keeping.
Best regards,
Michael
Hi,
I made a lib2geom toy which creates stitches especially for hair-like effects where an area should be filled with lines similar to a given curve:
http://i.imgur.com/bx829Uk.png
Code is in the src/toys/hair* files:
https://github.com/abrock/lib2geom
It works the following way: 1. Create offset curves until there is no intersection between curve and offset curve. 2. Create equidistant stitches on the middle curve 3. Create stitches similar to the ones on the middle curve on all other curves 4. Calculate intersections between curves and area outline. Throw away stitches outside the area. 5. Find the best ordering of lines so the amount of stitches along the area outline for connecting different parts is minimized. I do the connecting stitches along the outline since I sometimes want to use a very low density of lines and then I can't hide the connecting stitches under "future lines".
I'd like to create an LPE which can be applied to a closed curve (blue) with an open curve (red) as parameter.
Any comments?
Michael: Would you like to share the work you have done so far?
Best Regards, Alexander Brock
On 05/20/2016 04:14 PM, Alexander Brock wrote:
I made a lib2geom toy which creates stitches especially for hair-like effects where an area should be filled with lines similar to a given curve:
http://i.imgur.com/bx829Uk.png
Code is in the src/toys/hair* files:
https://github.com/abrock/lib2geom
It works the following way:
- Create offset curves until there is no intersection between curve and
offset curve. 2. Create equidistant stitches on the middle curve 3. Create stitches similar to the ones on the middle curve on all other curves 4. Calculate intersections between curves and area outline. Throw away stitches outside the area. 5. Find the best ordering of lines so the amount of stitches along the area outline for connecting different parts is minimized. I do the connecting stitches along the outline since I sometimes want to use a very low density of lines and then I can't hide the connecting stitches under "future lines".
Update: I made an executable called "hair" which takes two filenames as command line arguments ($outline.svgd and $path.svgd). The contents are read by read_svgd, I usually just copy the content from a SVG file.
The stitches are computed and the result is written in $outline.svgd.svg / $outline.svgd.txt. The .txt file can be converted to many different embroidery formats by libembroider-convert:
https://github.com/Embroidermodder/Embroidermodder
I applied the method to mane and tail of this vector:
http://imageconstructor.deviantart.com/art/Luna-545158121
Here you can see the results (input paths and embroidered versions): http://imgur.com/a/bRrko http://imgur.com/a/LVs8j http://imgur.com/a/d0sc1
I tried to make the stitches follow the direction of the hairs.
One problem is that Inkscape::half_outline sometimes increases the number of nodes which leads to exponential node count increase when applied repeatedly:
Is there an alternative? If not I might have to write one.
Best Regards, Alexander
Great work Alexander!
Maybe you can use the half_outline form join_type LPE intead the livarot one.
Cheers, Jabier.
On Sun, 2016-11-13 at 13:23 +0100, Alexander Brock wrote:
On 05/20/2016 04:14 PM, Alexander Brock wrote:
I made a lib2geom toy which creates stitches especially for hair- like effects where an area should be filled with lines similar to a given curve:
http://i.imgur.com/bx829Uk.png
Code is in the src/toys/hair* files:
https://github.com/abrock/lib2geom
It works the following way:
- Create offset curves until there is no intersection between
curve and offset curve. 2. Create equidistant stitches on the middle curve 3. Create stitches similar to the ones on the middle curve on all other curves 4. Calculate intersections between curves and area outline. Throw away stitches outside the area. 5. Find the best ordering of lines so the amount of stitches along the area outline for connecting different parts is minimized. I do the connecting stitches along the outline since I sometimes want to use a very low density of lines and then I can't hide the connecting stitches under "future lines".
Update: I made an executable called "hair" which takes two filenames as command line arguments ($outline.svgd and $path.svgd). The contents are read by read_svgd, I usually just copy the content from a SVG file.
The stitches are computed and the result is written in $outline.svgd.svg / $outline.svgd.txt. The .txt file can be converted to many different embroidery formats by libembroider-convert:
https://github.com/Embroidermodder/Embroidermodder
I applied the method to mane and tail of this vector:
http://imageconstructor.deviantart.com/art/Luna-545158121
Here you can see the results (input paths and embroidered versions): http://imgur.com/a/bRrko http://imgur.com/a/LVs8j http://imgur.com/a/d0sc1
I tried to make the stitches follow the direction of the hairs.
One problem is that Inkscape::half_outline sometimes increases the number of nodes which leads to exponential node count increase when applied repeatedly:
Is there an alternative? If not I might have to write one.
Best Regards, Alexander
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 11/13/2016 07:11 PM, Jabiertxo Arraiza Cenoz wrote:
Great work Alexander!
Thank you :-)
Maybe you can use the half_outline form join_type LPE intead the livarot one.
I searched for it but I only found the version I'm already using. I had a closer look at it and implemented some functions which don't subdivide paths if the error of the offset curve is too high but adjust the lengthes of the node handles.
This commit shows the new functions (...._stable): https://github.com/abrock/lib2geom/commit/f13af53ebf0076deb5b48acf7914db1714...
It doesn't work perfectly, I'll continue to improve it.
Best Regards Alexander
Is cool you improve it! Im working in a offset LPE currently and hope can use this new code soon.
Cheers, Jabier.
On Mon, 2016-11-21 at 17:31 +0100, Alexander Brock wrote:
On 11/13/2016 07:11 PM, Jabiertxo Arraiza Cenoz wrote:
Great work Alexander!
Thank you :-)
Maybe you can use the half_outline form join_type LPE intead the livarot one.
I searched for it but I only found the version I'm already using. I had a closer look at it and implemented some functions which don't subdivide paths if the error of the offset curve is too high but adjust the lengthes of the node handles.
This commit shows the new functions (...._stable): https://github.com/abrock/lib2geom/commit/f13af53ebf0076deb5b48acf791 4db171410fb06
It doesn't work perfectly, I'll continue to improve it.
Best Regards Alexander
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 11/21/2016 05:53 PM, Jabier Arraiza wrote:
Is cool you improve it! Im working in a offset LPE currently and hope can use this new code soon.
I improved it further the new code is in the *_stable-functions here: https://github.com/abrock/lib2geom/blob/master/src/toys/geom-pathstroke.cpp
The old method for offset_cubic: 1. move the control points 2. checked if the error at t=.5 was below some threshold 2. a) if yes return 2. b) otherwise subdivide path and repeat (up to some recursion depth limit).
The new method: 1. move the control points 2. Find the point on the curve where the distance differs the most from the desired distance 3. Adjust control point (only lengthes, preserve direction and smoothness) to minimize this maximum error 4. checked if the error at t=.5 was below some threshold 4. a) if yes return 4. b) otherwise subdivide path and repeat (up to some recursion depth limit).
This method seems to prevent degradation where the number of nodes increases exponentially due to numerical instability. Attached are examples of the old and new method used to repeatedly offset an initial red curve. The old code produces 4625 segments in the last step, the new code 3.
Should I prepare a merge request? I'd like to run some tests, any suggestions which kind? I think the most important thing is to test for a wide variety of paths if the created offset path has constant distance from the original path.
Best Regards, Alexander
I'm already looking at machines to use this with. This is so cool!
On 22 Nov 2016 2:18 am, "Alexander Brock" <a.brock@...2965...> wrote:
On 11/21/2016 05:53 PM, Jabier Arraiza wrote:
Is cool you improve it! Im working in a offset LPE currently and hope can use this new code soon.
I improved it further the new code is in the *_stable-functions here: https://github.com/abrock/lib2geom/blob/master/src/toys/ geom-pathstroke.cpp
The old method for offset_cubic:
- move the control points
- checked if the error at t=.5 was below some threshold
- a) if yes return
- b) otherwise subdivide path and repeat (up to some recursion depth
limit).
The new method:
- move the control points
- Find the point on the curve where the distance differs the most from
the desired distance 3. Adjust control point (only lengthes, preserve direction and smoothness) to minimize this maximum error 4. checked if the error at t=.5 was below some threshold 4. a) if yes return 4. b) otherwise subdivide path and repeat (up to some recursion depth limit).
This method seems to prevent degradation where the number of nodes increases exponentially due to numerical instability. Attached are examples of the old and new method used to repeatedly offset an initial red curve. The old code produces 4625 segments in the last step, the new code 3.
Should I prepare a merge request? I'd like to run some tests, any suggestions which kind? I think the most important thing is to test for a wide variety of paths if the created offset path has constant distance from the original path.
Best Regards, Alexander
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Alexander,
We've not moved to github yet, so if you need to do a merge request, you'll either have to make a bzr branch or get the help of another developer (hopefully on the mailing list) to do the merge for you.
Best Regards, Martin Owens
On Tue, 2016-11-22 at 01:30 +0100, Alexander Brock wrote:
On 11/21/2016 05:53 PM, Jabier Arraiza wrote:
Is cool you improve it! Im working in a offset LPE currently and hope can use this new code soon.
I improved it further the new code is in the *_stable-functions here: https://github.com/abrock/lib2geom/blob/master/src/toys/geom-pathstro ke.cpp
The old method for offset_cubic:
- move the control points
- checked if the error at t=.5 was below some threshold
- a) if yes return
- b) otherwise subdivide path and repeat (up to some recursion depth
limit).
The new method:
- move the control points
- Find the point on the curve where the distance differs the most
from the desired distance 3. Adjust control point (only lengthes, preserve direction and smoothness) to minimize this maximum error 4. checked if the error at t=.5 was below some threshold 4. a) if yes return 4. b) otherwise subdivide path and repeat (up to some recursion depth limit).
This method seems to prevent degradation where the number of nodes increases exponentially due to numerical instability. Attached are examples of the old and new method used to repeatedly offset an initial red curve. The old code produces 4625 segments in the last step, the new code 3.
Should I prepare a merge request? I'd like to run some tests, any suggestions which kind? I think the most important thing is to test for a wide variety of paths if the created offset path has constant distance from the original path.
Best Regards, Alexander
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Alexander,
I could help you if you want. By the way, can you tell me abot similar overlaping on Powerstroke, Bend, and Pattern Along Path. If they can be improved in similar way there is a important advance step.
I start using your code in my offset branch now to start trying.
Cheers, Jabier.
On Tue, 2016-11-22 at 04:06 -0500, Martin Owens wrote:
Hi Alexander,
We've not moved to github yet, so if you need to do a merge request, you'll either have to make a bzr branch or get the help of another developer (hopefully on the mailing list) to do the merge for you.
Best Regards, Martin Owens
On Tue, 2016-11-22 at 01:30 +0100, Alexander Brock wrote:
On 11/21/2016 05:53 PM, Jabier Arraiza wrote:
Is cool you improve it! Im working in a offset LPE currently and hope can use this new code soon.
I improved it further the new code is in the *_stable-functions here: https://github.com/abrock/lib2geom/blob/master/src/toys/geom-pathst ro ke.cpp
The old method for offset_cubic:
- move the control points
- checked if the error at t=.5 was below some threshold
- a) if yes return
- b) otherwise subdivide path and repeat (up to some recursion
depth limit).
The new method:
- move the control points
- Find the point on the curve where the distance differs the most
from the desired distance 3. Adjust control point (only lengthes, preserve direction and smoothness) to minimize this maximum error 4. checked if the error at t=.5 was below some threshold 4. a) if yes return 4. b) otherwise subdivide path and repeat (up to some recursion depth limit).
This method seems to prevent degradation where the number of nodes increases exponentially due to numerical instability. Attached are examples of the old and new method used to repeatedly offset an initial red curve. The old code produces 4625 segments in the last step, the new code 3.
Should I prepare a merge request? I'd like to run some tests, any suggestions which kind? I think the most important thing is to test for a wide variety of paths if the created offset path has constant distance from the original path.
Best Regards, Alexander
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi,
Considering what this file contains, it might have its place in lib2geom (which is already on github ;) )
Yes his place is in 2Geom but currently this file is inside helper folder in inkscape. I try remember Krzysztof say to Liam P. White that maybe we need to move it in the future.
Currently the original of this file is used on the Join Type LPE.
Cheers, Jabier.
On Tue, 2016-11-22 at 10:51 +0100, Marc Jeanmougin wrote:
Hi,
Considering what this file contains, it might have its place in lib2geom (which is already on github ;) )
On Tue, 2016-11-22 at 10:51 +0100, Marc Jeanmougin wrote:
Hi,
Considering what this file contains, it might have its place in lib2geom (which is already on github ;) )
True, and if re-factored into that it makes sense to keep it there.
Do we plan to keep lib2geom there if Inkscape moves to GitLab instead of GitHub? No need to keep them in the same place of course.
Martin,
On 11/22/2016 10:41 AM, Jabier Arraiza wrote:
I could help you if you want. By the way, can you tell me abot similar overlaping on Powerstroke, Bend, and Pattern Along Path. If they can be improved in similar way there is a important advance step.
I'll have a look at the code later. Is this behaviour for Pattern Along Path considered a bug or a feature? http://imgur.com/a/29UAe
So if my changes would lead to this behaviour, would that be good or bad? http://imgur.com/a/TTLZd
I start using your code in my offset branch now to start trying.
I'm glad to hear that :-)
Best Regards, Alexander
On Tue, 2016-11-22 at 13:01 +0100, Alexander Brock wrote:
On 11/22/2016 10:41 AM, Jabier Arraiza wrote:
I could help you if you want. By the way, can you tell me abot similar overlaping on Powerstroke, Bend, and Pattern Along Path. If they can be improved in similar way there is a important advance step.
I'll have a look at the code later. Is this behaviour for Pattern Along Path considered a bug or a feature? http://imgur.com/a/29UAe
So if my changes would lead to this behaviour, would that be good or bad? http://imgur.com/a/TTLZd
That's an improvement in my book.
Path off-setting is very tricky it turns out. The idea offset would be to evaluate the path at each point and then union all the enclosed area.
I start using your code in my offset branch now to start trying.
I'm glad to hear that :-)
Best Regards, Alexander
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I think this beabiour is a bug and your proposal is ok.
Cheers, Jabier.
On Tue, 2016-11-22 at 13:01 +0100, Alexander Brock wrote:
On 11/22/2016 10:41 AM, Jabier Arraiza wrote:
I could help you if you want. By the way, can you tell me abot similar overlaping on Powerstroke, Bend, and Pattern Along Path. If they can be improved in similar way there is a important advance step.
I'll have a look at the code later. Is this behaviour for Pattern Along Path considered a bug or a feature? http://imgur.com/a/29UAe
So if my changes would lead to this behaviour, would that be good or bad? http://imgur.com/a/TTLZd
I start using your code in my offset branch now to start trying.
I'm glad to hear that :-)
Best Regards, Alexander
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
And this is exactly the bug I ping to you to solve.
Cheers, Jabier.
On Tue, 2016-11-22 at 16:48 +0100, Jabier Arraiza wrote:
I think this beabiour is a bug and your proposal is ok.
Cheers, Jabier.
On Tue, 2016-11-22 at 13:01 +0100, Alexander Brock wrote:
On 11/22/2016 10:41 AM, Jabier Arraiza wrote:
I could help you if you want. By the way, can you tell me abot similar overlaping on Powerstroke, Bend, and Pattern Along Path. If they can be improved in similar way there is a important advance step.
I'll have a look at the code later. Is this behaviour for Pattern Along Path considered a bug or a feature? http://imgur.com/a/29UAe
So if my changes would lead to this behaviour, would that be good or bad? http://imgur.com/a/TTLZd
I start using your code in my offset branch now to start trying.
I'm glad to hear that :-)
Best Regards, Alexander
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I can't wait to see inescape in GutHub. I believe it'll bring more visibility and contributions to the project.
Em terça-feira, 22 de novembro de 2016, Martin Owens <doctormo@...972.....> escreveu:
On Tue, 2016-11-22 at 10:51 +0100, Marc Jeanmougin wrote:
Hi,
Considering what this file contains, it might have its place in lib2geom (which is already on github ;) )
True, and if re-factored into that it makes sense to keep it there.
Do we plan to keep lib2geom there if Inkscape moves to GitLab instead of GitHub? No need to keep them in the same place of course.
Martin,
On 11/22/2016 11:21 AM, Martin Owens wrote:
Considering what this file contains, it might have its place in lib2geom (which is already on github ;) )
True, and if re-factored into that it makes sense to keep it there.
I could: 1. Move the file to lib2geom and create a pull request there 2. Make Inkscape trunk compatible to the new version of lib2geom
Thoughts?
Best Regards, Alexander
Hi Alexander. Your code works very well in my offset branch, Thanks.
One thing more to do is add the more extrapolated joins located into helper/geom-pathstroke.cpp/h on Inkscape trunk.
To me the first option is the first one.
Cheers, Jabier.
On Tue, 2016-11-22 at 23:28 +0100, Alexander Brock wrote:
On 11/22/2016 11:21 AM, Martin Owens wrote:
Considering what this file contains, it might have its place in lib2geom (which is already on github ;) )
True, and if re-factored into that it makes sense to keep it there.
I could:
- Move the file to lib2geom and create a pull request there
- Make Inkscape trunk compatible to the new version of lib2geom
Thoughts?
Best Regards, Alexander
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Alexander and all.
I just sent you as reviewer of the offset LPE I just resubmit. I want it soon merged for try to remove SP-Offset on 0.93. Finaly I can get similar performace, than SPLivarot offset, + allow another line joins on expand offset than the previous rounded only.
I use your 2geom-pathstroke code. We can rollback it to previous one before merge, or, if the Extrapolated Cases are covered, i could commit it, and when 2Geom get it and sync with inkscape we can remove this files from helper folder.
Also another question. There is a LPE called Interpolate Paths that maybe can be improved with your code en embrodery.
Cheers, Jabier.
On Tue, 2016-11-22 at 10:41 +0100, Jabier Arraiza wrote:
Hi Alexander,
I could help you if you want. By the way, can you tell me abot similar overlaping on Powerstroke, Bend, and Pattern Along Path. If they can be improved in similar way there is a important advance step.
I start using your code in my offset branch now to start trying.
Cheers, Jabier.
On Tue, 2016-11-22 at 04:06 -0500, Martin Owens wrote:
Hi Alexander,
We've not moved to github yet, so if you need to do a merge request, you'll either have to make a bzr branch or get the help of another developer (hopefully on the mailing list) to do the merge for you.
Best Regards, Martin Owens
On Tue, 2016-11-22 at 01:30 +0100, Alexander Brock wrote:
On 11/21/2016 05:53 PM, Jabier Arraiza wrote:
Is cool you improve it! Im working in a offset LPE currently and hope can use this new code soon.
I improved it further the new code is in the *_stable-functions here: https://github.com/abrock/lib2geom/blob/master/src/toys/geom-path st ro ke.cpp
The old method for offset_cubic:
- move the control points
- checked if the error at t=.5 was below some threshold
- a) if yes return
- b) otherwise subdivide path and repeat (up to some recursion
depth limit).
The new method:
- move the control points
- Find the point on the curve where the distance differs the
most from the desired distance 3. Adjust control point (only lengthes, preserve direction and smoothness) to minimize this maximum error 4. checked if the error at t=.5 was below some threshold 4. a) if yes return 4. b) otherwise subdivide path and repeat (up to some recursion depth limit).
This method seems to prevent degradation where the number of nodes increases exponentially due to numerical instability. Attached are examples of the old and new method used to repeatedly offset an initial red curve. The old code produces 4625 segments in the last step, the new code 3.
Should I prepare a merge request? I'd like to run some tests, any suggestions which kind? I think the most important thing is to test for a wide variety of paths if the created offset path has constant distance from the original path.
Best Regards, Alexander
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 11/23/2016 01:22 AM, Jabier Arraiza wrote:
Hi Alexander. Your code works very well in my offset branch, Thanks.
One thing more to do is add the more extrapolated joins located into helper/geom-pathstroke.cpp/h on Inkscape trunk.
I copied my code into inkscape trunk (on my machine) and tested it using the "Join type" LPE. I noticed two problems: 1. It is rather slow 2. Some degenerated cases are not handled well (glitches).
I'm working on it and I'm going to make a merge request to inkscape which replaces the function offset_cubic.
Best Regards, Alexander
Great!
On Wed, 2016-11-23 at 16:03 +0100, Alexander Brock wrote:
On 11/23/2016 01:22 AM, Jabier Arraiza wrote:
Hi Alexander. Your code works very well in my offset branch, Thanks.
One thing more to do is add the more extrapolated joins located into helper/geom-pathstroke.cpp/h on Inkscape trunk.
I copied my code into inkscape trunk (on my machine) and tested it using the "Join type" LPE. I noticed two problems:
- It is rather slow
- Some degenerated cases are not handled well (glitches).
I'm working on it and I'm going to make a merge request to inkscape which replaces the function offset_cubic.
Best Regards, Alexander
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi,
I made the offset_cubic function more stable and fast and merged it into the latest version from Inkscape trunk so you can test extrapolated joins etc., you can find it here so you can test it if you want:
https://github.com/abrock/lib2geom/blob/master/src/toys/geom-pathstroke.cpp
I played a little with the Join Type LPE and collect path data samples so I can automatically compare different offset methods:
https://github.com/abrock/lib2geom/tree/master/src/tests/half-outline-paths
Feel free to send me any path data / svg file with paths that behave odd.
I added a svg file with comparisons between the new and old behaviour and proposal for "correct" behaviour which I might be able to implement.
Best Regards, Alexander
Cool. Im out home, try it on weekend.
El 2016-11-23 22:42, Alexander Brock escribió:
Hi,
I made the offset_cubic function more stable and fast and merged it into the latest version from Inkscape trunk so you can test extrapolated joins etc., you can find it here so you can test it if you want:
https://github.com/abrock/lib2geom/blob/master/src/toys/geom-pathstroke.cpp
I played a little with the Join Type LPE and collect path data samples so I can automatically compare different offset methods:
https://github.com/abrock/lib2geom/tree/master/src/tests/half-outline-paths
Feel free to send me any path data / svg file with paths that behave odd.
I added a svg file with comparisons between the new and old behaviour and proposal for "correct" behaviour which I might be able to implement.
Best Regards, Alexander
Look forward to testing in trunk! Thanks for all the work!
On 23 Nov 2016 6:58 pm, "Jabier Arraiza" <jabier.arraiza@...2893...> wrote:
Great!
On Wed, 2016-11-23 at 16:03 +0100, Alexander Brock wrote:
On 11/23/2016 01:22 AM, Jabier Arraiza wrote:
Hi Alexander. Your code works very well in my offset branch, Thanks.
One thing more to do is add the more extrapolated joins located into helper/geom-pathstroke.cpp/h on Inkscape trunk.
I copied my code into inkscape trunk (on my machine) and tested it using the "Join type" LPE. I noticed two problems:
- It is rather slow
- Some degenerated cases are not handled well (glitches).
I'm working on it and I'm going to make a merge request to inkscape which replaces the function offset_cubic.
Best Regards, Alexander
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (11)
-
Alexander Brock
-
Brynn
-
C R
-
Jabier Arraiza
-
Jabiertxo Arraiza Cenoz
-
Josh Andler
-
Marc Jeanmougin
-
Martin Owens
-
Michael Soegtrop
-
Tavmjong Bah
-
Victor Westmann