length of a path

[dinasset]

Is it possible to know the length of a path?
Thanks

---

PS: I've seen there is the possibility to get the list of all strokes components of a path, and the possibiity to get the length of a single stroke. Is there an already written function to get the total length of the path or should I perform a loop to sum up the single lengths of each stroke?

[dinasset]

I wrote this piece of code, it seems to work. Is it OK?

Code:

#!/usr/bin/env python
from gimpfu import *
def TestPathLength (inImage, inLayer) :
   
   activevectors = pdb.gimp_image_get_active_vectors (inImage)
   totallength = 0
   (nrs, ids) = pdb.gimp_vectors_get_strokes (activevectors)
   for stroke in ids:
       length = pdb.gimp_vectors_stroke_get_length (activevectors, stroke, 1.00)
       gimp.message ("length = "+str(length))
       totallength = totallength+length
   gimp.message ("total length = "+str(totallength))
   pdb.gimp_displays_flush
   return(totallength)

register(
   "TestPathLength", "TestPathLength", "TestPathLength",
   "Diego", "Diego Nassetti ", "May 2017",
   "TestPathLength",
   "RGB*,GRAY*",
   [
     (PF_IMAGE, "image", "Input image", None),
     (PF_DRAWABLE, "idrawable", "Input drawable", None),
   ],
   [
     (PF_FLOAT, "tplength", "Total path length", 0.0),
   ],
   TestPathLength,
   menu="<Image>/Diego/Test",
   )

main()    

[Ofnuts]

It would sort of work, but... the last parameter in stroke_get_length is a precision. This is necessary because the length of a Bezier curve cannot be computed directly, it is approximated iteratively until the value doesn't change (within the precision). And when you add imprecise things, the result is even more imprecise. So if you start with one pixel on the strokes you could have several pixels of error on the whole path. Of course, using a very good precision (0.001) is not innocuous, the algorithm iterates more and takes longer (though on modern machine you may hardly notice it)

[dinasset]

Thanks Ofnuts.
I didn't know what to put in that parameter, I'll change to 0.001

[Ofnuts]

Don't over do it, .001 requires roughly 2000x the computations of 1. .1 or .01 are likely enough.

[dinasset]

Thanks, I'll do it.