[EDIT: The solution, as you will learn from SaulGoode further down,
viewtopic.php?f=9&p=161255#p161253
begins with NOT hunting for Python syntax in a C function... The GIMP Library Reference Manual catalogs GIMP's underlying C functions, many/most? of which are accessible from Python--but that doesn't make them Python, does it?

If it was me, I'd read this thread from the end. But if you insist, here's me starting off on the wrong conclusion:]

I'm not sure how to call this function. (I think I may have gotten some bad information off the Internet. )

Referring to the GIMP Library Reference Manual:
http://developer.gimp.org/api/2.0/libgimp/index.html
In particular, this function,
http://developer.gimp.org/api/2.0/libgimp/libgimp-gimpvectors.html#gimp-vectors-stroke-interpolate
reads as follows:


My gut feeling from staring at this is that it actually returns THREE things: in addition to "returning" a "gdouble *" list of points on the path, it also indicates the number of points found ("gint *num_coords") and whether the path was open or closed ("gboolean *closed").

However, I'm asking what it really means, and also how to call it in Python.

My guess follows, but I get "TypeError: wrong number of parameters" for my troubles:


Anyway, as always, thanks. And always fun to be here.
--
gramp

There are two categories of libgimp functions: those that invoke PDB procedure and those that do not. (PDB = Procedural DataBase)

For functions that invoke PDB procedures, I recommend looking at descriptions in the PDB browser in the Help Menu ("Help->Procedure Browser").

As to your second query, in Python I believe you would place all of the symbols of the variables to receive the return values of the function before the '='. There is no need to create the variables ahead of time.

Strange question... If you don't know what it does why would you want to call it? (and anyway, as SG says, it's not available to scripts or Python plugins).

I had also visited the function there, but forgot about it, but seeing it again I can tell you I would've assumed it was different from the one in the GIMP Library Reference Manual. The PDB browser makes it clear which are inputs and outputs. I'll use that one as my pair-of-dime.



I had in fact seen an example like that, but it puzzled me, how it could be called that way when defined this way??[1]


and I quested to find a source for Python syntax confirming that in fact it could be, which quest eventually brought me back around to GimpChat. :^) (I can tell you I wanted not to ask for help here because I wanted to ride in on my chariot, like a Roman centurion returning from Visiting the Visigoths, generously tossing my new, first script to the worshipful masses. <awakes with a start>Wait. I had a 'moment' again didn't I?)



To me, strange answers! "If you don't know what's over the mountain, why would you go?" :^) But I at least suspected it will do what I want, and sometimes you, well, not you, necessarily, per se, I mean, but just take somebody like me who doesn't necessarily understand all the terms in an unfamiliar description, that person, me again, speaking now per se-wise, would understandably, well, at least forgivably, try it to see if it helped their, my, understanding.

And regarding it's not being available to scripts or Python plugins, I can only ask, "Are you quite sure?" because it's in the PDB browser, and what I presumptously call my 'script' does get error messages that appear to tell me I'm calling it incorrectly, which at least hints that it's calling it.

Now having come ineffably close to wearing out my welcome, I must hie me back to the Visigoths, who generously agreed to take five while I posted.
--
gram p
[1] Sorry. In the original post, I had the wrong function. I had highlighted the area to grab, but then resized the browser window before grabbing it, and that put a completely different function in view which I grabbed anyway because I was thinking about Visigoths.

@saulgoode
Your pointer to the PDB Browser was the ticket. I misled myself from the GIMP Library Reference Manual information to believe that the ORDER of the returned values should be:

but arranging them as:

has allowed my 'script' to advance to the Next Great Error Message which, unless I have stumbled into an infinite loop, and in which case I bid all a 'Fare well', is known as 'Progress.'
--
gra mp

(By the way, I bless the person who came up with the 'Edit' button for posts. They should be famous or at least have a PayPal account.)

[EDIT: Sorry, I know that's off-topic, but I've become fascinated by it.]

OK, so it is in the PDB, so it can be used in scripts. But not all functions defined in the C interface are.

As to its name and purpose, it creates a polygon that is as close to the actual path as possible within the precision factor. Of course, the better the precision (smaller number, because it looks like a distance), the more points you get. As to its usefulness in scripts... there are two things that are not easy to compute with Bézier curves: their length and the enclosed area, two things that are very easy to do on polygons, so if you have a polygon that approximates the curve, you can easily have a good approximation of this using the polygon interpolation. However there is already a direct and more accurate way to obtain the length of a stroke, and there is a rather fast way to obtain its area (make a selection from it, and use the histogram function to count the pixels inside). So the only use I would have for that is computing the "diameter" of the curve (greatest distance between two of its points) because there are algorithms for this for (convex) polygons...

@ofnuts
I gave a wrong impression. I was seeking an interpretation of the Python syntax of the function, rather than of the function itself. I was just going to see if what it returned looked anything like what I wanted by calling it.

An old professor of mine claimed that there were two types of investigators in the world, Newtonians and Edisonians. As you might guess, the latter try thousands of possibilities until they hit on one which glows when current is applied without being burned up. Newtonians on the other hand prefer to "seek the rule" behind a mere few observations. Edisonians, I think, perceive that "it's just quicker to try it, than to try to understand it." :^)

It may be that one is better than the other, but the old professor seemed to think the work of the world was divided roughly equally between them.

But he was a Newtonian. (And I should add that he put me down as an Edisonian.)

It might be observed that, for all his laws, Newton worked by candlelight. :^) (Oliver Heaviside, whom some identify as the "first electrical engineer" started using an "impulse function" to get answers long before mathematician Paul Dirac came along to invent it as the "delta function"--proving nothing, yes, I know, but it's like a GimpChat easter-egg.)

The libgimp function provides the interface for C plug-ins. It is actually a "wrapper" for the PDB function (for those functions where PDB corollaries exist). There are some -- typically low-level -- libgimp functions for which there are no PDB corollaries (such as tile and pixel region handling). In these cases the libgimp function will interface directly with GIMP's core functionality.

The PDB procedures provide the interfaces for various other languages (Script-fu, Python, Perl, etc) and is intended to be language agnostic and extensible.

The distinction is that PDB procedural calls can not alter the values of the parameters passed to it. C parameters can be altered -- if you pass the address of the variable in memory instead of the variable's value.

Furthermore, PDB calls can return multiple values, while C functions can only return a single value.

These two differences lead to the interfaces in libgimp being somewhat different as in the example of gimp-vectors-stroke-interpolate. The arguments in its libgimp invocation include &num_coords and &closed (the addresses of the two parameters), and there is only a single return value (the array of coords). The PDB version receives the actual values of num_coords and closed, and returns the three updated values of nb_coords, the coords, and closed.

So what I would recommend is that unless you are programming a plug-in in C, ignore libgimp. If you reach the point where you need to use libgimp functions that are not exposed in the PDB then 1) look for examples and documentation in your plug-in's language and 2) have a good foundation in writing simple plug-ins first (i.e., don't run before you can walk).

@SaulGoode
Thank you for connecting the dots. I confess to thinking that, since it obviously wasn't Scheme, I must be looking at Python.



...I should live so long.



Or in my case, "Don't crawl before you can creep."

The knot of incomprehension does seem to be loosening. (However another old professor of mine observed, "When something gets simpler, something else gets more complicated." so I must be on my guard.)

It works.

At least for a simplish open S curve. And for a simple stroked (closed) version of the same curve too.

When I choose a set of disconnected contours, some of which lead off the page, I get a
"RuntimeError: execution error"
so 't ain't perfect.

[Indeed, the problem is caused by nodes lying "off" the underlying layer being sampled. Editing them to drag them back "on," eliminates the error.]

What I'd like to do now, is to put dots on a new layer showing where all the samples were taken, to see how well the interpolations line up with the originals. That is, I would like to attempt running with scissors before I can run.

Suit yourself



NB: my script doesn't use the PDB but the Python classes/methods built over it... but this is a matter of style and doesn't change the result...

?? Oh ?? Glad to see you could make it. THANK YOU!

However, there goes another perfectly good daydream: shot to hell... I'm about to cross into the city limits with my script of many colors--now in a second-hand donkey cart, pulled by a bow-legged ox, and a large dog, when a well-known conqueror passes by in his well-known chariot, to the adulation of all the citizenry--and under the worshipful glances of self, and of dog.

A story was told about John von Neumann, the prodigious mathematician, who died too-soon, shortly after his arrival at Sandia National Labs, that goes something like this, from an uncertain memory. Famous as he was, people flocked around him at lunch time to hear him declaim, to the ire of one fellow who had formerly held that level of regard. He determined to show von Neumann up, and cast about for an obscure math problem which the latter likely had not yet discovered. He researched and studied and worked out the final answer, with the intent of casually introducing the subject during one of the lunchtime gatherings, and then proceeding to show up the great math "wizard."

Months later, he was ready, and during a lull he announced, "That reminds me of the problem posed by So-and-so..." to which von Neumann, replied, "Oh, yes, very interesting." indicating he was indeed familiar with it. The antagonist, a little rattled, went on, revealing a little of his results, "Well, it occurs to me that such-and-such..." and von Neumann engaged, and was off to the races. Working on a napkin, in the first 2 minutes he replicated what had taken the first fellow two months to work out. Now fearful, the fellow struggled to stay ahead of the wizard, and kept tossing out other results, which only accelerated v.N.'s progress to the answer. Finally, when it became clear that von Neumann was only moments away from the answer, the exasperated foe blurted it out, "...and the result is 'X!'" and stormed away.

A split-second later ofnuts, I mean, Neumann came to the same conclusion and looked up, stunned.

Finally, he asked, "Who was that fellow?"

And when response was made, he looked around, "He didn't even use a NAPKIN!!"

It's kinda like that...

My script--over a month in the making--is probably not so general-purpose as those typically presented. Mine leaves behind for me files of triplets, (x,y,pixelvalue), for individual strokes along a set of paths. My end goal is a CNC program. However, another was to earn that scar known as "first script." My production is very fragile because it's based on magic: mimicking others' approaches without understanding. In another month, I'll be wondering where it came from...

"Edison! Sah-Lute!"

[BTW, got the pixel-setting part to work now too.]

And fixed--no, addressed, no, kludged--the runtime error from trying to get_pixel() off the image layer.


(If you do zoom in, you'll see the 'pixels' marking the points sampled are actually 5-pixel crosses, to make sure they were big enough to be visible.)