Inkscape

Hi there! The gitlab link doesn't exist, and the linked user does not have any repositories that are visible. Can you fix up the link / the repo visibility?

Hi Maren,

Thanks ! I've set the project visibility to "public"

qpad

Thanks :) Wow, that looks like it has been quite a lot of work! I'd love to see an example in the README :)

Not sure if this is helpful, or perhaps just annoying:
- Some people like to use a subfolder for improving the overview.
- Have you taken a look at the convenience functions in simplepath.py and the unit conversion tools in inkex.py? Or have you intentionally done without them?

(and a licence file would be cool :) )

I was just answering this post earlier today: https://forum.inkscapecommunity.com/index.php?topic=871.0 Could this extension work for changing that relatively simple drawing to single paths?

Hi Maren,

Thanks for the comments and suggestions !
Just to be sure I understand correctly :

- Example : there's a doc/demo.svg file. But I guess you're suggesting I add explicit instruction in the README : good point, I'll do.
- subfolder : you mean putting my 'shapereco.py' and 'shapereco.inx' under something like 'src/' in gitlab ? Or do you mean they can go under a subfolder in the $HOME/.config/inkscape/extensions ?
- simplepath.py/inkex.py : to be honnest no I didn't have a look. I anticipated the task requests a lot of array manipulations and so started right away to use numpy for its performance and ease of use. But maybe I indeed re-wrote things that are already available in these modules and thus introduced an unnecessary dependency...
- Licence file : ok I guess I can find one from the GNU website... Is there any recommendation for inkscape extendions ?

Hello Brynn,

I'll give a try to the picture you point from the forum. But I don't have strong hopes : the extension is designed to work from hand drawn single paths, I'm not sure what it will give on vectorized pictures.

Hi qpad :)

No worries, those were mostly just more or less wild ideas.

As for the example, yes, instructions in the README would be cool - then people can see right away what they get when they visit the repo.

As for the subfolder, I was more referring to the huge .py file. Some people like to make smaller chunks and separate by functionality, and it's possible to use subfolders for this - I thought that if you wanted to do that, it would help to know that it will work.

Numpy isn't a rare dependency for third-party Inkscape extensions - but it's a difficult thing to add dependencies for Windows users, because they get their python 2.7 with Inkscape, in a subdirectory of the installation, and need to put numpy there, too (instead of globally).

Github offers to create a licence file automatically, you'd only need to choose which pre-made text you want. I know that option is available when you first create a repo, but it might also automatically pop up if you create a LICENSE file (not sure, though). As you've selected GPLv2 here, and Inkscape aims to be GPLv2+, I think the GPLv2 text with a 'or higher' added to the version number would be suitable. But of course, the Licence is entirely up to the author :)

Hello Marin,

Ok I've slightly updated the README as suggested. At least it has minimal instruction usage. And added a proper licence file (I just followed instruction on the GNU page).

I see you're point about subfolder. And if you mean the code is messy and hard to read, I agree. I've opened an issue on the gitlab page to keep remind this to me :)

Regarding numpy I didn't know about the Windows difficulties. I'll see what can be done, but I fear dropping numpy would result in much more code...

Thanks again for the suggestions !

I just looked it up. numpy shouldn't be a problem, it seems it's already included in the Windows builds:
https://gitlab.com/inkscape/inkscape/blob/master/buildtools/msys2installdeps.sh#L82

Great with elipses unless it's close to a circle,. then you get an elipse not a circle. not so great with rectangles, sides are made parralel, overruns and deviations are handled by straight lines n ot recognising the shape as a rectangle and normalising to one.

The first problem is easily solvable by using a tollarance for when an elipse should really be a circle, I'm not sure how easy it is to sort out the issues with rectangles but again there seems to be a tolarance from when a bunch of lines should really be racognised as a rectangle.

I may look at the code and see if I can come up with something, as it would be nice to have an open source smart whiteboard, especially with my handwriting and drawing ability being non-existant and reqiring cpomputer aid.

if two straight lines differ by only n degrees they should be made one straight line or parallel with each other, this should be before they are normalized to the predetermined fraction of pi angles if possible if not it would probabl;y want hard coding at pi/12 or a user option for pi/12 or pi /8. that should sort out one of the problems with rectangles and I may do the coding myself. the other problem is with overruns. I'll keep reading the code and see if I come up with a solution but both cases need to make the tolarance for being converted into an actual rectangle n ot just a set of straight lines.

I parameterized this, which worked a little and parameterized the merging angle tolerances which worked and caused a rectangle to be fitted.

def mergeConsecutiveParralels(segments):

extenstions go in the hidden folder: cx:\Users\username\Application Data\inkscape\extensions on windows

mergeConsecutiveParralels doesn't seem to do what I think it does and malso the angle seemzs to be taken from the first segment and doesn't take into account the other segments. so, I'm going to write some code that makes lines that are close to parralel, parralel and look at how the angle is calculated so that the whole shape gets taken into account. After the changes I made things seem better but a circle wasn't recognized correctly so I've got that to l;ookl into too.

I came across a few bugs and bits of coded that weren't finished, so I'm going to finish off those bits of code, paramaterize all the thresholds to see if there are some better defaults for them and get as many bugs quashed as possible and add a few new features.

Oh, wow. I've just rolled back to the currfent release version and loaded the failureL.svg document to see if there are any brakages with my changes and it looks like my changes recognise the shapes in failureL with nearly 100% accuracy, certainly a lot better than head, so it's been worth speading a night on it.

Hi Jeff,

Wow thank a a lot for spending some time on this little project. And congrats, the code is horribly documented and would need a lot of cleaning !
If you improved things, I'd be happy to merge your changes. Would you be able to open a Merge Request on gitlab where the code is stored ?

Hi Jeff,

I don't see where you made this changes. I tried to quickly adjust the code because it did not work at all with a recent version of Python, but it was way to much. Is your Version available somewhere?

tried updating to Python3 too but i failed

trail:
https://chat.inkscape.org/channel/general?msg=uwwtqzrAWdGGRoj5s

latest update (i guess):
https://lists.inkscape.org/hyperkitty/list/inkscape-devel@lists.inkscape.org/thread/VLW2YL5WWIDIMGS4PPFTC2OOZ6CDEDNM/

This is the effect of my changes so far:

https://ibb.co/gF7tfhm
t
I'm going to try and do a delta between your original and my enhanced version to see if I can get the shape recognition close to perfect.

Personally, I think this would be a nice feature to have real-time in Inkscape.

@#20, thanks. You beat me to it.

Here's my current code before I do the delta. From my comments there is one property that may need to be parameterized. I'll see how the delta works out.
https://pastebin.com/WuJPfNLj

I just noticed, I already parameterized it, so it should be more or less good to go. I'll do a little delta on the defaults to get the best default parameters.

What about this:
https://ibb.co/qpSBY5Q

I set the image to delete in a month... if it's all good I'll post the default parameters.

Actually, the default parameters are "merge lines tolerance 1" 0.2"merge lines tolerance 2" 0.35

this is better still https://ibb.co/87KV2jP with equal local set at 0.2 and equal global set at 0.02

All that's left is to see if I can tweak it so that everything remains good and that square wave is more accurate.

here's a selection of other variants:
https://ibb.co/album/w0Y4M6

password letmein1

It looks like I'll have to tweak the code to average out those angles and lengths for the square wave so it's better. It seems to be taking the LHS angle and using that.

ok, this is just about it. just two points left to try and resolve. The circle marked in red and the line that is now horizontal.

I believe the horizontal line is because were matching a bunch of things at once, so could possibly be called a desirable artefact, I'll have a bit more of a play and see if I can get that last circle recognized. It's quite a long thin ellipse and I think that's the difficulty.

https://ibb.co/k2wMzmb

I'm going to leave it at this for the time being.

Here's the updated code if you want to play around:
https://pastebin.com/ibB3xrCh

and the parameters are set as follows:
segments finding:
segment exctension:enabled
rel dist = 10.0
fit quality = 0.30
remove v small:enabled
merging
aligned:enabled
fit p at 0.5
merg tol 1 0.39
merge tol 2 0.180
len normz
equalise:enabled
len loc = 0.2
len glob = 0.05
unif
all:enabled

this is what it should look like with those parameters from fresh:
https://ibb.co/pwGbGBN

there seems to be an issue with things getting stale and different results for the same parameters. I expect there's either a global value not being cleared or it's because i have objects selected in multiple Inkscape windows.

you can see from fresh it's a bit better, at least the circle i highlighted is closer to a circle, and the small square(bottom left) hasn't vanished.

almost forgot:
you need this as well for setting the parameters:
https://pastebin.com/emF6SHPp

I expect a lot of the settings can go once the defaults are stable.

I think the real solution is a multi-pass, with circles, then rounded objects, then square objects or fragments of.

But I think I may save that for if we integrate into Inkscape as a real-time feature and leave the extension as of my last update pending any bug fixes as I think it's pretty good, though not perfect.

To get the square wave function looking mice I broadened the window for angle matching then took the mode angle instead of the mean.

I'll add my final thopughts so i don't forget them:

to get the rounded shapes working better broaden the window on the merging and look for a curve. Also size match curve segments with smaller fractions than straight line segments.

it should be possible to fit a real curve.

for instance matching 8ths of an ellipse to an arc, by looking for continuous curvature over a range.

I did it,
https://ibb.co/R3btpQL

All shapes substantially recognised.
It still seems to have some instability issues and support for curved edges still needs to be added.

setting are:
and the parameters are set as follows:
segments finding:
segment exctension:enabled
rel dist = 1.0
fit quality = 0.35
remove v small:enabled
merging
aligned:enabled
fit p at 0.5
merg tol 1 0.29
merge tol 2 0.280
len normz
equalise:enabled
len loc = 0.2
len glob = 0.05
unif
all:enabled

here's my first attempt at detecting arcs, you can see it's picked up quite a lot of square shapes. Maybe because they have rounded corners and missed a few curved lines:
https://ibb.co/D42GVXb

I think I'm going to leave it for now any maybe take a look at it another day. I'll have thought about it a bit more by then too.

I started inkscape fresh and had to click the dials up and down again in preview mode to get it to recognise the shapes again properly, so it's still a bit buggy or it may be a bug in the version of inkscape I'm using.

I think i need to use the derivative of deltasD to get arcs working.

Hi Jeff,

Thanks again for working on this ! I'm happy to update the extension with your changes if you agree.
I can't see all of the pastebin snippets you posted (some are password protected)
The latest I can see is https://pastebin.com/ibB3xrCh which I have no objection to merge and so I guess I also won't have objections to merge your latest tunings.

If you have a gitlab.com account, the easiest is probably you open a Merge Request with your changes to
https://gitlab.com/qpad/InkShapeReco
If not, no worries, post the latest version somewhere public and I'll manage to get it in.

what need to be done for curved segments is to follow the change in angle along the line by taking a tangent, rotation it to the origin horizontal plane, then take the tangent of the next segment as the angle increment.
Create an array of all the angle increments
and look for segments that curve (aren't too straight) and don't have acute angles that triangles, Squares and other none curved joins have.
the window need to be large enough to cover 1/4 pi curves and identify straight lines and acute angles.

circles are already identified and after arc segments are also taken out of the list, leaving only straight lines and acute angles a little more can be done to ensure they are accurately matched and tidied up nicely. With curved gone there's no need to be so 'fussy' about the shape

It should also be possible to use shape recognition in diagramming packages and for drawing around areas in a non-uniform fassion.

I was using either an alpha or beta version of Inkscape. IU've just upgraded to 1.0 and it found lots of bugs in the extension. I'm currently porting the extension to Inkscape 1.0 and hoping some assumptions I've made when there was a weird bug are valid. Some bugs may well explain the erratic behaviour when changing input values to the extension.

I'm also brushing up my linear algebra a little to implement curved segments. I think I'll keep having a bash at it and hopefully should have everything recognized nicely including curves.

Hi, Qpad.
I'm currently fixing some bugs and migrating to Inkscape 1.0.
I'll create a merge request once the extension is running on 1.0 properly.

it's NASA Jeff again:
I've migrated the script to 1.0, done a lot of refactoring and am currently developing it heavily.
I'm just about to add support for curved segments which should make identifying and aligning the straight lines a doddle and I should be able to greatly simplify the whole process in the code.
After migrating to 1.x I spent a lot of time refactoring the code, it's now spread across 7 .py files and I've separated out pre and post-processing from the main class which now just handles the basic plugin elements and recognition of shapes after all the pre-processing has been done.
After that I added support for all segment types in the SVG path and converted curved segments to straight fragments so that later recognition of curved surfaces and straight lines in uniform. I'm expecting to identify a boundary condition in the arc delta I'm using to differentiate between drawn curves and drawn straight lines.

After tidying all that up I have a cunning plan for identifying closed shapes and closing them.

The hope is to get this as a real-time feature in Inkscape at some point in the future.

Here's a Bézier and smooth Bézier W3G test SVG file with the curve fragmented into straight lines:
https://i.imgur.com/P7EIYjN.png

Hi NASA Jeff,

Wow, what you're describing looks impressive !
Again, feel free to submit a merge request to the project on gitlab.
Or maybe you want to start your own project since it seems you're much more advanced and I'm not sure I'll have much time to work on it.