(01-19-2021, 02:08 PM)Ottia Tuota Wrote: Fine, I shall look into the problem. Would you kindly post and attach the .xcf file. It would make debugging easier.
Just a 300 radius circle where I applied the plug-in. Attached is the xcf.
CropByPath03.xcf (Size: 243.64 KB / Downloads: 226)
Please report if any more errors occur. In the previous version I had overlooked the possibility that a splitting point may fall on an anchor of the path. I hope I got it now right, but it is rather complicated and I may still have missed something.
I know one more a little disturbing behaviour. A stroke, if it meets the cropping circle, is divided into two strokes even when that would not be necessary. I may do something about that in the future, or then I may not...
Please report if any more errors occur. In the previous version I had overlooked the possibility that a splitting point may fall on an anchor of the path. I hope I got it now right, but it is rather complicated and I may still have missed something.
I know one more a little disturbing behaviour. A stroke, if it meets the cropping circle, is divided into two strokes even when that would not be necessary. I may do something about that in the future, or then I may not...
With version 0.5 and using the same .xcf as before, the results were as expected.
Thanks for the correction and update of this plugin.
It seems to work correctly though it is slow. Please report any erronous behaviour.
As an example I use the Truchet path. Here I have drawn an additional path (red) from which to make a selection.
I did:
Path to selection from the red path.
Call the new plugin "crop path by general selection" (choosing the inside-outside option to be "both").
I got two paths. Here I display them separately. The red path does not belong to the cropped paths.
The input "Threshold" is meaningful if your selection is feathered.
In complicated cases the plugin is slow (the above run takes some 31 seconds), which is mainly due to the large number of calls to image.selection.get_pixel(). There may be some way to restrict that number of calls, but that would require further complication of the code. And it may not be so efficient after all. Currently I am not willing to try it. Going now to another project. Happy for having finished this. Please have fun.
(03-30-2021, 01:38 PM)Ottia Tuota Wrote: I added a new path-cropping plugin: Crop a path by a general selection. The new version is 0.6 and it is in the same place as before:
It seems to work correctly though it is slow. Please report any erronous behaviour.
As an example I use the Truchet path. Here I have drawn an additional path (red) from which to make a selection.
I did:
Path to selection from the red path.
Call the new plugin "crop path by general selection" (choosing the inside-outside option to be "both").
I got two paths. Here I display them separately. The red path does not belong to the cropped paths.
The input "Threshold" is meaningful if your selection is feathered.
In complicated cases the plugin is slow (the above run takes some 31 seconds), which is mainly due to the large number of calls to image.selection.get_pixel(). There may be some way to restrict that number of calls, but that would require further complication of the code. And it may not be so efficient after all. Currently I am not willing to try it. Going now to another project. Happy for having finished this. Please have fun.
There is a much more efficient way than get_pixel(). You can use a pixel_region, which ends up as an array directly usable in Python. Some exemple [here](https://www.gimp-forum.net/Thread-Gimp-python-and-numpy) (before the conversion to a numpy array of course).
03-30-2021, 08:32 PM (This post was last modified: 03-30-2021, 09:05 PM by Ottia Tuota.)
There should be no limitations. You have found bugs. I shall look at this tomorrow. It would help if you could run those trouble cases again and expand that "More information" in the error message and post here.
Edit: I think I found the reason for the first error. As for the second error, is the path the same checker, only denser? If so, then perhaps the error too comes from the same bug. It will be fixed in the next version where I hope I shall have also incorporated what Ofnuts just taught me.
03-30-2021, 09:34 PM (This post was last modified: 03-30-2021, 09:49 PM by Krikor.)
(03-30-2021, 08:32 PM)Ottia Tuota Wrote: There should be no limitations. You have found bugs. I shall look at this tomorrow. It would help if you could run those trouble cases again and expand that "More information" in the error message and post here.
Edit: I think I found the reason for the first error. As for the second error, is the path the same checker, only denser? If so, then perhaps the error too comes from the same bug. It will be fixed in the next version where I hope I shall have also incorporated what Ofnuts just taught me.
Ok,
(03-30-2021, 08:32 PM)Ottia Tuota Wrote: Edit: I think I found the reason for the first error. As for the second error, is the path the same checker, only denser? If so, then perhaps the error too comes from the same bug. It will be fixed in the next version where I hope I shall have also incorporated what Ofnuts just taught me.