Cropping and slicing a path

[Ottia Tuota]

I made a plugin to crop a path, similar to cropping an image or a layer. I don't know any such tool in Gimp previously, but what I know about Gimp is very limited, so please enlighten me if I am wrong.

Actually I made four plugins, two for cropping, two for slicing:

1. Crop path by convex polygon
   
2. Crop path by rectangle
   
3. Slice path by guides
   
4. Slice path by lines
   

Numbers 2 and 3 are the main plugins, that is, I expect them to be the most used. The other two came as by-products.

To get the plugins, go to Cropping and slicing a path, scroll to the bottom, and click the download button. You get a zip file. Unzip it and place the one file it contains (crop_path.py) in your user's plug-ins folder. Then (re)start Gimp.

To invoke the plugins, go to the Paths tab, right-click some path and follow the link
Tools > Cropping and slicing > ...

I explain now the plugins. They are very simple to use (quite an achievement from me).

Crop path by rectangle takes as input a path (the right-clicked one) and it allows four choices for the cropping rectangle:

1. a rectangular selection
   
2. four guides (two horizontal, two vertical)
   
3. image (canvas)
   
4. the active layer.
   

The first option (selection) allows in fact any selection, not only rectangular, but only its bounding box is used. In this sense it works just in the same way as the usual tool Image > Crop to selection works for images.

The second option (guides) requires that no other guides exist.

   

Crop path by convex polygon works similarly except that instead of a rectangle the cropping region is a convex polygon. The polygon is inputted as a path: closed, with straight edges, enclosing a convex region. ("Convex" means that all corners jut outwards.) Of the polygon path only anchors are taken into account; all curviness is ignored.

   

Then the two slicing plugins:

Slice path by lines takes as input two paths. One is the source path to be sliced (the right-clicked one), and the other is supposed to be a set of straight line segments, one line segment per stroke. Of each stroke the first two anchors are read and used to determine a line. You can think that each stroke is supposed to be a 2-anchor path, a straight line segment. Note that the line segments may be short, but the plugin sees and uses them as full infinite lines.

If the slicing path has only one stroke (only one slicing line), the source path is split into two parts. This is the situation in the following picture. For this picture, I moved the two halves of the result slightly apart just so that you can see what happened.

   

What happens here is more precisely the following. The path is splitted into two parts. Two new paths are created: if the original path has name 'path', the new ones will probably be 'path|slice' and 'path|slice #1'. If either of them is empty, it is discarded (not inserted in Gimp). But in some cases an additional new path is created. Namely, if the original path contains straight line segments which lie flat on the slicing line, there is no way to tell to which side they belong, so they are collected as a separate additional new path.

In the next picture the slicing path consists of three strokes (three slicing lines). Again I moved the sliced parts a little just to show the effect.

   

Slice path by guides works quite similarly except that the slicing lines are guides. You have the choice to use all guides in the image, or only horizontal guides, or only vertical guides.

A word of warning: The running time grows fast with the number of slicing lines (or guides). That is why I prevented the usage of more than 8 lines. Another advantage of this is that the number of created new paths also grows fast, and it is good to have some limit. If you want to change that number 8, find and edit in the code the line

MAX_SLICE_LINES = 8 # Maximum number of slicing lines allowed

But please, do not go over 10.

If you find some case where the plugins act strangely, please report. The code is a little messy, I admit, and I may have missed something.

[Ofnuts]

(10-09-2020, 11:31 AM)Ottia Tuota Wrote: A word of warning: The running time grows fast with the number of slicing lines (or guides). That is why I prevented the usage of more than 8 lines. Another advantage of this is that the number of created new paths also grows fast, and it is good to have some limit. If you want to change that number 8, find and edit in the code the line

MAX_SLICE_LINES = 8 # Maximum number of slicing lines allowed

But please, do not go over 10.

If you find some case where the plugins act strangely, please report. The code is a little messy, I admit, and I may have missed something.

I'm surprised. All that would be required is solving 3rd degree equations which is pretty fast. Your warning seems to indicate that the computing time is somehow quadratic or worse?

[Ottia Tuota]

(10-09-2020, 08:09 PM)Ofnuts Wrote:

(10-09-2020, 11:31 AM)Ottia Tuota Wrote: A word of warning: The running time grows fast with the number of slicing lines (or guides). That is why I prevented the usage of more than 8 lines. Another advantage of this is that the number of created new paths also grows fast, and it is good to have some limit. If you want to change that number 8, find and edit in the code the line

MAX_SLICE_LINES = 8 # Maximum number of slicing lines allowed

But please, do not go over 10.

If you find some case where the plugins act strangely, please report. The code is a little messy, I admit, and I may have missed something.

I'm surprised. All that would be required is solving 3rd degree equations which is pretty fast. Your warning seems to indicate that the computing time is somehow quadratic or worse?

I don't even try to pretend that I understand this problem. But I believe the difficulty comes from the number of the generated new paths, the slices.

Imagine a path. Imagine its bounding box. Then imagine that we put there a large number of slicing lines, criss-crossing the bounding box. They slice the bounding box into a large number of small regions, and the path becomes sliced accordingly into small slices. The number of the slices grows fast with the number of the slicing lines. I don't know how fast it grows, but it could be quadratic(??). I seem to remember vaguely that I have seen a theorem about this years ago, but I don't remember the exact result.

And it is not only the solving equations. It is also Gimp drawing the generated paths, and their number also grows fast. I have not done any systematic testing, only some experiments, but in one case there were 43 new paths. (I don't remember how many slicing lines there were.)

So, I think the problem comes from the nature of the task, the number of the generated slices.

[Krikor]

The plugin worked very well here. Fast and easy to use. Thx a lot!

Full Size - https://i.imgur.com/rMNIuHa.png

[Ottia Tuota]

(10-09-2020, 10:51 PM)Krikor Wrote: The plugin worked very well here. Fast and easy to use. Thx a lot!

Great!

---

(10-09-2020, 08:55 PM)Ottia Tuota Wrote: Imagine a path. Imagine its bounding box. Then imagine that we put there a large number of slicing lines, criss-crossing the bounding box. They slice the bounding box into a large number of small regions, and the path becomes sliced accordingly into small slices. The number of the slices grows fast with the number of the slicing lines. I don't know how fast it grows, but it could be quadratic(??). I seem to remember vaguely that I have seen a theorem about this years ago, but I don't remember the exact result.

I figured it out. No need for any old theorems. Consider a rectangular box. Cut it with n straight lines. The box becomes divided into small regions; denote their number by f(n). Then
    
     1+n <= f(n) <= 1+n(n+1)/2.

I can write and post the proof if somebody wants it. What f(n) exactly is, depends on how the lines are arranged. By choosing the arrangement suitably, either of the cases 1+n and 1+n(n+1)/2 can be realized. So, the worst case does indeed grow quadratically. I suppose this explains it.

[Ottia Tuota]

I uploaded a new version 0.3. A small bug fix. I don't think the bug should cause any problems to anyone, it was just that when splitting a closed stroke, sometimes a wrong tailing handle was attached.

The new version 0.3 is at:

http://kmarkku.arkku.net/Path_crop_files...aster.html

[Ottia Tuota]

The cropping and slicing package contains now a new member: "Crop path by circle". You get it from

http://kmarkku.arkku.net/Path_crop_files...aster.html

as before. With the new plugin you can cut a path to circular form. The result is a new path. In addition, instead of the cropped path you can use the plugin to cut a circular hole.

An example: I used Ofnuts' Truchet plugin to make an interesting path, and then I cropped it to circular form, and I made a circular hole in it. Here are both:

   

The cropping circle is input as a line segment (a 2-anchors path). The line segment can mean either a diameter of the circle, or the center and one point on the circle.

This plugin arose as a by-product of another project. It involves solving numerically an equation of degree 6. Please report if you find cases where it acts strangely. The code is a little tricky and anything is possible.

[denzjos]

Nice to make a detail view of a path assy :
     

[Krikor]

I tried to reproduce the example given in post #7 in order to learn about this 'new member', but I got an unexpected result.

In the image below you can see in blue the desired circle and its radius (in red), as well as the information in the 'Error console' window about the size of that diameter (300). It is also visible that there is still part of the 'truchet' that should have been removed.
   
By inverting and selecting the inner part, the result also shows an 'excess' (which was expected to have been cut)
   

[Ottia Tuota]

(01-19-2021, 01:22 PM)Krikor Wrote: I tried to reproduce the example given in post #7 in order to learn about this 'new member', but I got an unexpected result.

In the image below you can see in blue the desired circle and its radius (in red), as well as the information in the 'Error console' window about the size of that diameter (300). It is also visible that there is still part of the 'truchet' that should have been removed.

By inverting and selecting the inner part, the result also shows an 'excess' (which was expected to have been cut)

Fine, I shall look into the problem. Would you kindly post and attach the .xcf file. It would make debugging easier.

---

Edit: Never mind, I found an example myself where such thing happens. Now I try to find out what to do about it.