Inkscape for embroidery
by Michael Soegtrop
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.
6 years, 10 months
performance problems and possible remedies?
by Yale Zhang
Hi. I'm using Inkscape to author a comic and the slow speed for certain
things is very annoying. I'm already have OpenMP turned on and using 4
cores.
1. *large blurs are slow* - I'm an expert with writing SIMD code, so I was
thinking about vectorizing the Gaussian IIR filter with SIMD intrinsics,
even though it's harder than for a FIR. But I noticed there isn't any SIMD
code in Inkscape so does that mean it's something to avoid.
I'm pretty sure no current compiler is smart enough to vectorize it, and
besides, Inkscape is compiled with -O2, meaning -ftree-vectorize isn't on
by default.
2. *when there's a large image (raster based) background - scrolling in a
zoomed region is very slow*
I compiled the latest 0.49 code with GCC profiling and it shows this:
33.98 22.47 22.47 exp2l
21.29 36.55 14.08 log2l
17.57 48.17 11.62 pow
7.12 52.88 4.71 658 0.01 0.01
ink_cairo_surface_srgb_to_linear(_cairo_surface*)
6.72 57.32 4.44 563 0.01 0.01
ink_cairo_surface_linear_to_srgb(_cairo_surface*)
5.51 60.96 3.64 1216 0.00 0.00
Inkscape::Filters::FilterGaussian::~FilterGaussian()
5.23 64.42 3.46 internal_modf
0.59 64.81 0.39 _mcount_private
0.41 65.08 0.27 __fentry__
0.12 65.16 0.08 GC_mark_from
0.09 65.22 0.06 5579 0.00 0.00
Geom::parse_svg_path(char const*, Geom::SVGPathSink&)
0.06 65.26 0.04 35320 0.00 0.00
bounds_exact_transformed(std::vector<Geom::Path,
std::allocator<Geom::Path> > const&, Geom::Affine const&)
0.06 65.30 0.04 8 0.01 0.01
convert_pixbuf_normal_to_argb32(_GdkPixbuf*)
0.05 65.33 0.03 885444 0.00 0.00
std::vector<Geom::Linear, std::allocator<Geom::Linear>
>::_M_fill_insert(__gnu_cxx::__normal_iterator<Geom::Linear*,
std::vector<Geom::Linear, std::allocator<Geom::Linear> > >, unsigned long
long, Geom::Linear const&)
The cost is absolutely dominated by ink_cairo_surface_srgb_to_linear() and
ink_cairo_surface_linear_to_srgb(). My first instinct was to optimize
those 2 functions, but then I thought why are those even being called every
time I scroll through the image?
Why not convert the images up front to linear and stay that way in memory?
If that can't be done, then my optimization approach is:
1. replace ink_cairo_surface_srgb_to_linear() with a simple 3rd degree
polynomial approximation (0.902590573087882 - 0.010238759806148x +
0.002825455367280x^2 + 0.000004414767235x^3) and vectorize with SSE
intrinsics. The approximation was calculated by minimizing the square error
(maxError = 0.313) over the range [10, 255]. For x < 10, it uses simple
scaling.
2. replace ink_surface_linear_to_srgb() with a vectorized implementation
of pow(). Unlike srgb_to_linear(), a low degree polynomial can't be used
due to the curve having larger high order derivatives. An alternative would
be piece wise, low order polynomials.
The main question I have is what degree of accuracy is desired? Certainly,
it doesn't need double precision pow() since the input is only 8 bits! Is
+- 0.5 from the true value (before quantization) OK or do people depend on
getting pixel perfect results?
UJ
6 years, 11 months
Git
by Krzysztof Kosiński
Eventually we probably need to move to Git. The user interface is
completely atrocious, but the fact it works from a single directory by
default is very convenient when using Eclipse, and Eclipse is an
elephantine monstrosity but has good code navigation. This could also
encourage more people to contribute, since almost all OSS developers
know Git, while a very limited number know Bazaar at this point.
The bug tracker and answer tracker should definitely stay on
Launchpad, but what about the code? Should we use Launchpad's nascent
Git support, or some other site like Github? What people think?
We can convert lib2geom first and apply the lessons learned to Inkscape.
Best regards, Krzysztof
7 years, 5 months
SpinachCon 2016
by Martin Owens
Dear users and developers,
Inkscape has been invited to take part in the Free Software design day
known as SpinachCon which happens the day before LibrePlanet here in
Boston:
https://libreplanet.org/2016/
The SpinachCon event is about working with users on finding odd, weird
and slightly ugly things within inkscape that we can fix or make designs
about.
If you are in the area and wish to take part it's March 18th 2016, from
12:00-5:00pm, in Boston at Beaucoop's offices (near South Station on the
Red Line)
I'll report in a new article any findings or fixes after the event.
Best Regards, Martin Owens
7 years, 6 months
Google Summer of Code 2016
by Josh Andler
Hey all,
I just wanted to let everyone know that Inkscape was accepted as a
mentoring organization for GSoC this year. This will be our 11th year
participating. Google has transitioned from Melange to a new site (1) this
year if you're interested in reading more about it.
If you are interested in participating as a student please visit our page
(2) on Google's new Summer of Code site to find links to our Ideas for
summer projects on our wiki and our developer mailing list. As usual,
please either introduce yourself on our developer mailing list or let us
know what you're interested in working on this year. Student application
don't open until the 14th, so now is the time to be talking to us if you
are interested in working with us.
If anyone has any questions, please ask away.
Cheers,
Josh
(1) https://summerofcode.withgoogle.com/
(2) https://summerofcode.withgoogle.com/organizations/6010720831406080/
7 years, 6 months
Re: [Inkscape-devel] Inkscape for embroidery
by Michael Soegtrop
Dear Alexander,
> Did you create a branch on Launchpad where I can see your code? I'd
> like to test it and possibly contribute to it.
Not yet, but I guess within a week.
Best regards,
Michael
7 years, 6 months
Screenshots of bool LPE with new slice-inside and slice-outside bool ops.
by Michael Soegtrop
Dear Inksacpe Team,
here are 3 screen shots of the bool-op LPE and the new slice-inside and
slice-outside bool ops I implemented this weekend:
www.Michael-Soegtrop.de/Inkscape/slice_off.png
www.Michael-Soegtrop.de/Inkscape/slice_inside.png
www.Michael-Soegtrop.de/Inkscape/slice_outside.png
In the slice-outside image please note that the cut shape is transparent
- it is not just hiding the lines below.
Of cause all normal bool-ops are also supported by the LPE.
Since I want to supply a patch for embroidery use based on 0.91 soon, I
implemented it based on the old livarot mechanisms, but the new bool ops
are just 200 lines with quite a few comments, so I don't see much of an
issue to port it later. The main work was anyway thinking about how to
do it so that it works reliably and not implementing it.
The filltype parameters I will remove and get them from the paths instead.
I think these bool-ops are quite useful for normal drawing (not
embroidery) as well as a more generic kind of hatching.
Best regards,
Michael
7 years, 6 months
Quality of gradients.
by Gez
A few weeks ago, Tavmjong added a comment to bug #180693, asking if the
reported issue was still present with the new renderer.
I'm answering here, as I'm adding some personal comments that probably
don't belong to the bug report.
Please tell me if it's is worth that I add some of this information to
the bug report, or feel free to do it if anyone wants to.
Regarding the question,
As long as Inkscape renders at 8bpc, yes. It will still be a problem.
It's possible that some sizes and colors hide the problem more than
others, but banding will still be a problem unless images are rendered
in higher precision.
The easiest way to check this is to draw a grayscale gradient.
At 8bpc, you can't paint more than 256 shades of gray. So a 256px-wide
gradient will look ok, but as soon as you stretched that gradient to a
larger size, banding will appear.
An even more extreme example (but not less frequent) is when you also
have a grayscale gradient, but instead of going from black to white you
go from a middle gray to a lighter gray. If your gradient takes, say 50
levels out of those 256, stretching the gradient will result in severe
banding sooner.
I don't think it's possible to address banding in 8bpc without some
form of dithering, and it looks that the current renderer doesn't apply
any.
As I mentioned in an older comment, the best way I could find to work
around this was using the "spread" filter in GIMP, which jitters the
edges of each step of the gradient making it look smoother.
There are existing dithering algorithms that could be used too, like
floyd-steinberg, bayer, a-diher (http://pippin.gimp.org/a_dither/),
etc. but I wonder how effective would they be as we don't have a smooth
gradient as a starting point, but a stepped one.
Those dithering algos could be useful if inkscape rendered at 16bpc, to
bring down the display to 8bpc though.
At any rate, rasterizing a vector shape and applying a filter would be
prohibitively slow for large sizes so this dithering, if applied,
should be probably applied only to export, making this solution
unsuitable for on-screen representation.
Anyway, I don't think banding is too much of a problem (it is, but it's
not as severe) for screen as it is for printing.
For printing it becomes a critical issue, as other commenters pointed
out.
Inkscape is a valuable tool for large format printing which I use
daily, and time to time I have to apply some nasty workarounds because
of this limitation.
For my professional work, the way inkscape renders gradients is a show-
stopper. The quality of my work suffers if I don't apply one of those
tedious workarounds discussed in this thread.
This bug has been reported about 8 years ago, and a lot happened since.
Maybe this time, with a new renderer there's something that can be done
to get it fixed?
Gez
7 years, 6 months
