"Alls I wants for Christmas is" a present of a new path tool.

As I wrote to Santa (fogifying a little about my age), I want a script that can
follow a set of paths and
for each point (as defined by the resolution of the image) along the path
record a triplet in a CSV file: (x,y,color/graylevel)
of the (x,y) of the location along the path and
a graylevel on the underlying image level (read: "heightmap").

With such a tool, it would be possible to "terrain follow" the heightmap.

Now, as I put it to Santa, if I can't have that, what was the point of being so good?

Seriously, this seems so straightforward a thing to ask that I merely copy Rob A's path_blend script
(highly recommended for Christmas giving btw!) to Gramp_pathxyg_v0.1.scm, on the impulse
that I would just change anything that didn't look like path-following, cause I know it
has to follow paths.

When I regained consciousness...

I opted instead to draw a simple 2-node path, adding a simple curvature, and ran ofnuts' path_csv plugin
(another recommendation to bring a smile to the face of a happy Gimper). Opening the CSV
file expectantly, what do I find? The Christmas-gift equipment of 'socks' your mother said you needed
more than the Bowie knife anyway. I allude to the fact that it contained information only about the 2 end
nodes, making it clear as can be to gramp that he would have to figure out the points in between...

This made me study upon the calendar and cipher that maybe there's not enough days left for gramp to
be able to pull off a script that will make RobA and ofnuts and Graechan and all exclaim "Kudos!
gramp! Kudos! We didn't think you had it inya! (In fact we KNEW you didn't.)"

However, I know something you don't know... I am too dumb to give up just because I don't
have it inma.

If you don't want to read about gramp "dying at the helm of a keyboard, trying to create
his dream, with inadequate tools, having started off quite doomed-ly in the wrong direction"
you could offer some help or suggestions.

You know that Murphy's Law about "deep within the heart of every man is a scheme [no pun intended,
although the word seems strangely prophetic] which 'will not work'"? Well, right now, I'm content, because as
long as the idea is unrealized, it works Perfectly in my knotted head.

Merry Christmas, everyone!
--
gramp
BTW there are two corollaries to the Law that I know of:
Cor1: There may be more than one.
Cor2: It does seem to be sex-linked. Women do not seem to be afflicted in the same way, but exist to
explain after-the-fact why it had no chance of working in the first place.

Not very hard to make a derivative of path_csv... but instead of gray level, to remain generic(*), I would output RGB in three different columns for an RGB layer (but you can always apply a formula to create the required H, S or V value if needed). Of course is the image is grayscale there is only one value and if the image is RGB but gray all three values will be equal.

What is not clear is how you want the path sampled? Every X pixels (X being a parameter?). Or N points/stroke?

(*) read: possibly answering the needs of other people

[Whoops, I see ofnuts has replied, with a question: "N equally spaced points along the path," I would answer. "I want definitely to stay on the path at all points."

To that I can add: "the distance between adjacent points should be around 1-pixel distance."]

Running around with my head cut off, as Mother used to say, I investigated the plugins directory and there found ofnuts'
path_dump.py
script.

I had thought originally that if "path_csv.scm" summarizes a path only in terms of its endpoints so likely would path_dump.

But, oh, not so fast there, laddie.

The output (in the Path tab, right-click a path then Tools->Dump, after starting GIMP in a terminal window) is like, for a 5-node path (which I named 'DumpAlongPath' after my favorite cowboy hero) with 3 inner ones forming a curve:


There are a LOT of points(samples) along the path (yay!), and I'll guess the six numbers for each specified node are the (x,y) coords of the node and of the two "handles". An in-the-know person will know how to follow a curve between two endpoints from these 6 numbers, I'll hazard.

For each of the sample points, I'll guess the three numbers are the (x,y) of the sample point and a "slope" (given that the 3rd number does not change along a straight line, but varies for curves).

Also, python, although one of those "modern" languages, feels less MountEverest-y than Scheme, although the latter appears to be based on the ancient language LISP.

So, now it would fall to gramp [OR one of his benefactors HINT] to figure out how to harness the power of path_dump.py to get the (x,y) pairs along a path while simultaneously grabbing the RGB/graylevel from the layer. If not exactly easy-peasy, the chance that I might see this before I shuffle off is looking better.

Thank you.
--
gramp

Sorry. I managed to muddle up a reply to a simple question.

"Every X 'pixels' along the path" where the 'pixel' 'spacing' is the 'same' as the image. (Don't know if that's any better.)

Thanks.
--
gramp

Try the following:

http://chiselapp.com/user/saulgoode/rep ... 5f6d0f0e64

Command is in "Filters->Misc->Dump Path Colors..."

One CSV file will be produced per path stroke.

If only one stroke --> filename.csv
otherwise --> filename-1.csv filename-2.csv filename-3.csv etc

The number of values for each pixel is determined by the image mode and whether the layer has an alpha channel.
1 value == grayscale, no alpha
2 values == grayscale, with alpha
3 values == RGB, no alpha
4 values == RGB, with alpha

Me too! (Except for that part about "scripting skills...")

Would you look at that freshness date? "December 2014." <inhales> Smells like pine needles!

Thank you, Saul, from the bottom of my heart.
--
gramp

After doing some testing, I discovered that there is an error in my approach. I will have to modify it so that the points are evenly spaced ('gimp-vectors-stroke-interpolate' doesn't behave as I was expecting it to).

I will post an update later today (evening at the latest).

Here is the updated script:

http://chiselapp.com/user/saulgoode/rep ... c52d12831a

If it runs too slow, I can make some adjustments to speed it up (I probably oversample more than necessary), but I would prefer to delay such tweaking until after the holidays.

Saul,

Thanks for the rewrite. I was out helping a helper of someone else to get their family into their new home before winter. (Fail; new goal: before mid-winter.)

I got this error with both versions however:
Not gonna win a literature prize, but there it is. :^)

For comparison, an ordinary line looks like:


The error appears as this last line of the output file (dumped-path-colors_resn1.csv) itself:


However, this is also line #2516, so there are 2515 could data lines. Curiously, or not, I did this in two resolutions, 1 and 0.001, and got exactly 2516 lines in both files.

Ideally, there would be a set of contour paths, featuring uniform elevations, and a second set
of paths, roads, with changing elevations.

Attached is the tiny-project I'm trying it on.

No, no, nothing expected until after the holidays--which btw reminds, Merry Christmas to all! and a Happy New Year.
--
gramp

The problem is that my script does not check that the path lies entirely within the boundaries of the layer (sampling the color outside the layer generates an error). This is easy to fix but I may not get a chance for a few days.

If you want to run the script in its current state then you would need to increase the size of the layer (to completely surround the path) before running. This, of course, will offset all of values of the xy coordinates but you can at least verify whether things work.


The "X-Y Precision" argument only affects the appearance of the two coordinates in the lines of the output file; it does not affect how many samples are actually taken. For example, whether the X-coordinate would be shown as "1" or "1.8" or "1.82" or "1.829". Unfortunately, the 'gimp-drawable-get-pixel' function does not perform supersampling, so regardless of which of those values are displayed, the color is actually sampled at location X=1. This was really just done for my benefit so that I could see lines such as "286,433,0,0,0,0" rather than "286.9060939428,433.30969097,0,0,0,0" -- I figured allowing for millipixel precision should be sufficient but I would probably leave the full floating point precision in the output for future versions, especially if your ultimate goal is to generate G-code or somesuch.

As to the number of points being sampled, I chose a fixed value of five samples per pixel dimension. I considered this value to be a good compromise between accuracy and speed. It could probably be reduced to "2" without too much degradation in the accuracy of the output file (and a corresponding speed up of the execution) but I figured "5" would provide a good balance.

To understand this better, consider the following path winding through a 4x4 pixel region.



The red dots represent the points along the path at an interval of one pixel width while the blue dots represent the actual coordinate locations sampled. Note that this does not guarantee that every pixel the path "touches" will be sampled -- for example, the pixel directly above the first point of the path gets ignored (i.e., it is not sampled) despite the path cutting across it. If I were to shorten the distance between path coordinates (increase the number of red dots), I could probably ensure that that pixel would then be sampled, but then the pixel that is currently sampled by the fourth sample point might then be missed. By making the interval distance be 1/5th of a pixel, I ensure that the likelihood of "missing" such pixels is much less. None of this would be a problem if 'gimp-drawable-get-pixel' would interpolate the color values at the subpixel level (anyone for writing a PDB function that does this?).


I think you have the right idea with your "stepped" contour layer, though the Posterize filter will only work properly for grayscale images.

I was thinking about the very same lines, but my answer to this, instead of sampling more points, would be to do a barycentric interpolation of the color of the 4 pixels around the sample coordinates(*)

(*) round off the coordinates of the path point to nearest integer, the coordinates of the pixels are (x-1,y-1), (x-1,y), (x,y-1),(x,y).

I'd just use gimp-image-pick-color with a suitable radius, although it does average rather than interpolate.

Kevin

"Especially." ;^) In fact, to that end, it would be helpful to do this only for selected paths. Of course, I don't know what I'm asking.



[faints before asterisk]
--
gramp

Don't get too impressed by the name, it is actually quite simple. Conceptually you have your sampling point and find the nearest corner of 4 pixels:



Then you take the square that is 1/4th in each pixel, and divide it in 4 rectangles from the pixel on the path. Then the area of each rectangle is the weight of the opposite pixel (in other words you average the color over that square):

Thanks, Ofnuts, for going above and beyond.

gramp, here is a version you might try. It uses the barycentric interpolation* approach suggested by Ofnuts (thanks for that), however, it only produces the grayscale value even if the layer is color (I was basically being lazy, but also thinking this may be for your CNC work).

http://chiselapp.com/user/saulgoode/rep ... 47fd77ec25


* if performing linear interpolation is called "lerping" would this mean that doing barycentric interpolation should be called "berping"?

@saulgoode

Thank you! (When does the part about waiting until after the holidays kick in? I just want to be ready... ;^) )

I'm sure that when I in my kerchief settle down to a long winter's quiet contemplation of the project to be advanced, the entire horde of grandchildren will burst upon the scene and pile onto my lap and mount up to overtop my head. At those times, like Jack Benny when ordered to choose "Your money or your life!" replied, "I'm thinking, I'm thinking.", I often find myself of two minds.

I have been poking around with ofnuts path-dump.py script too because I have always been of the opinion that, to learn a new language, you need a good problem.

gimpchat rocks. [Readers happening upon this in the Year 3000, don't you agree?]
--
gramp

My family has rescheduled Christmas to be on Sunday, giving me a bit more time to prepare (and, of course, to have it completely interfere with my enjoyment of the NFC North championship game).

Q. First, a question: recalling some of the prior discussions here about the "closed" nature of paths (i.e., what looks like a line is actually two: a line "out" and a line "back") and the sometime need to "break the path" into unclosed components (as for example for stroked fonts), how are you following a path, in this regard?

[BTW, I was chuckling at the vagaries of your environment when Mother passed through and announced, "We're moving the family dinner to Sunday--you have four days to get cleaned up..." (oh)]

Your latest offering works famously. I even wrote (as in "copied liberally from websites") enough Perl to get a working G-code program! Still have to do all the stuff about orientation and scaling and registration, but "it's all in there."

I thought I could get away with creating a new path from a copy of the over-sized one cropped to the layer, and then merely increasing the canvas size by 2 pixels (and centering) in order to get a 1-pixel zone around the outside. However as you said, I did have to "Layer-to-Image-Size" the layer-of-interest to the new canvas size to avoid the error.

Q. I need to be able to distinguish the paths because of the necessity of raising the cutter during traverses from the end of one to the beginning of another. (Failure to do so, in CNC parlance, leads to "crashing" the cutter into the workpiece.) One way would be to add a pathID comment ahead of each path? (implemented as a toggle for people who don't desire it?) Another way might be to have your script toggle between processing all or only visible paths? (The script appends a "-1" to the filename I provided, but with two paths, I still only got one the one output file.)

Unexpected piece: I duplicated the single path in my example, and renamed it, expecting I'd get an output file of twice the size, but it came out identical--as confirmed by diff. I suspect your script recognized the duplicity, and that if I shifted the path, it would in fact result in a doubling of the size.

I mean, since you're just sitting around waiting for the game to come on anyway.

Take this with a grain of salt: I'm not entirely scientific with my "method."
--