Actually, I have a couple of critical errors in that version that could make the results off by as much as a pixel radius (e.g., it can take the sample from a different pixel than the path crosses). I will get a fix out (hopefully before Sunday) but until then I would recommend not using the data in production.


I will make it so that all path segments outside of the layer boundaries are ignored. Actually, I've already done this but because of the aforementioned errors in my script, this doesn't behave well.


A single path can have different segments that are not connected. These segments are called "strokes". When creating a path, you can start a new stroke by holding down the SHIFT key when you click on a location, in which case the new point will not be connected to the previous one. I am not sure whether this feature will be useful; your idea of hiding paths might be more applicable (you also have the option to chainlink paths).


The script currently only processes the active path and ignores all others. If you duplicated the path than the duplicate becomes active and the original inactive. This can be changed to process all paths, or all visible, once I have a better idea of the work flow.

There are two parts here: but I don't know quite how I will use them until I know quite how I can use them.
1. contours
As in the example where I first posterized in order to generate edges for an edge-detector to select and save the edges en masse as a single path, I foresee being able to "break out" individual contours from the collection of them all produced in this way, so that a CNC could follow each contour at an associated height, raising to a safe height after each.
2. roads
Like contours a single "path" is generated from a set of curves defining "roads".
Unlike contours, because these cross, they are not separable into individual, simple paths. The intent is to have the CNC follow them in a continuous pattern (probably the same as 'stroking'), without raising the cutter until the very end, but admittedly then with the understanding that previous locations may and will be revisited.
(Actually, I just realized that contours will not always be separable either--at cliffs. But sufficient for the day is the evil therein. However, roads too, I see now, can be discontinous too.)

The essence here, seems to be that: there needs to be a flag at discontinuities, to let the CNC be raised before traversing to the next--whether what it's "going to" is considered to be a new path, or still part of the existing. In saying that I don't really have a good picture.

However, if flagging is possible within individual path traversal, there wouldn't seem to be any need to break out individual paths.

Maybe.

I don't know that a pixel's width is going to kill me.



Cool.



In this connection, I don't theen, as Inigo Montoya used to phrase it, in The Princess Bride, you are doing all the strokes. Consider the following:


After I process the CSV (just read, shift, and scale), this is the path:


The "disconnected paths" seem to have been missed (by one of us).



I'm happy with it being confined to "the Active Path"--but please consider identifying the non-contiguous strokes in the output, if that's possible.

And if you're approaching it "one path at a time," how about right-clicking on a path and running your script from there?

It's getting close... better not take a chance...

MERRY CHRISTMAS!

BTW, if anyone cares to see the Perl parser (and you should beware that it's customized for one particular machine and LinuxCNC), I attach it here.

I don't apologize for the code.

Or other miracles.
--
gramp

Umm, that would be me. Somewhere in converting the code from colors to gray levels I messed things up. The latest version rectifies this and is available at http://chiselapp.com/user/saulgoode/rep ... 27f36b9196


Well, the script is back to producing a separate CSV file for each stroke, but I can do something else if you should like. I wouldn't mind having the script write the G-code file directly, but I am uncertain as to what the cutting head is supposed to do between strokes. Is there such a thing as a CNC router simulator with which I can run G-code on my computer?

'tis upon us: Merry Christmas to All! And may you have all you require to see your dreams through in the New Year, and a little kick in the pants to go with it!



Let me see how this works--it might be just the ticket.



There is, there is! or was... I use a semi-commercial one now purchased with my MeshCAM software (recommended). Before that however, I used to use <strains head against restraints> "CNCSimulator" from <shakes head left-and-right> http://www.cncsimulator.info. It has a built-in "annoy-er" in that each operation uses a little bit of "petrol" which when gone requires returning to their "petrol station" to "refill." I found I was much less annoyed by the inconvenience than by the metaphor. ("What millennium is this?" :^) )

Basically, the cutter needs to raise up to "safe height" between any move to a non-contiguous stroke. As long as it stays on the same stroke it began on, it can be assumed it's supposed to cut. However, when moving to another stroke that is not connected, it must assume there's material in-between that's supposed to remain.

Consider cutting a "stepped" version of a mountain, top-down. The goal is a set of terraces. However, unless the cutter is raised after the cut of the first, highest one, (to be repositioned over the beginning of the next), there will be a channel cut from the end of the first to the beginning of the second--spoiling at least some of the first terrace. If this is also implemented as a typical rapid move, the noise, shaking, and general ensuing hub-bub can unexpectedly trigger biological functions.

@saulgoode

I've been doing some experimenting, and while the script doesn't seem to miss anything, it also seems to be "seeing things" too. :^)

By that I mean the output set of files contains a host of small-sized files (~50 bytes) which, when included in the G-code rendering, result in paths which do not appear in the original.

I had hoped that by skipping them, I'd also eliminate all the spurious paths, but at least one of the necessary files also contains some data for non-existent paths. I'm still trying to isolate where they are--and what values they are, with the hope of comparing it to ofnuts' dump-path-to-csv to see if they really are on the path.

[Still cranking away on the contours path: path-blend may finally have a fellow tortoise to swap adventures with...]

BTW, a triviality: having the files numbered with the same number of digits; e.g., NNNNN, would help with sorting and eliminating: as it is now, path-values-[1-9].csv are intermixed with path-values-[1-9][0-9].csv, etc.

Less trivial, I noticed from watching a simulation that the paths really are "out-and-back" which means every point will be visited twice by the cutter. I don't know how that even could be addressed programmatically but I suspect that one can't split an arbitrary path into two mirror images in order to follow only one. [EDIT: I have noticed about paths which I save from selections that they are closed, and narrow (because they typically enclose region 1-px-wide), and as I said, "out-and-back". Could it be as simple as following the path to the halfway point ("out"), and stopping? skipping the return? MORE EDIT: Only in the simplest case. Consider a (multi)path created from selecting pixels in a pair of crossing lines (a '+' sign). If the first node is at the top, and the path proceeds CW, visiting half the nodes will only get to the bottom, and the nodes on the right-hand arm will all be visited twice.]

I conclude that I need to start with simpler, paths than are to be had by selecting-by-color and saving-selection-to-path: ideally, a set of simple paths that run right down the center of selected lines. (I see some softwares that offer to create DXFs from image line drawings offer to trace the out-lines or the center-lines.)

Cheers!

[Update: Success! in a medium sort of way.]

Well, here it is, Eastertide 2021, SEVEN YEARS after my last post on the subject, shortly after CHRISTMAS 2014, and I'm back to say things are pretty bad if you COMPLETELY forget about a work-in-progress thread and only STUMBLE on it again when searching the WEB for something completely unrelated.

I am mortified.

I am deeply sorry for having left this hanging, and apologize to you all, saulgoode, ofnuts, graechan, who showed me so much patience and offered such help. I can't understand what happened myself, but as I read through the thread, I recognize only the tenor of my posts, but none of the work.

"Really?" I'm thinking, "I _did_ this?"

I'm not posting now to report a resumption of the investigation, although it would interest me and benefit the GIMP-CNC connection to have a solution (and I pray the thread remains available), but merely to post a long-overdue apology and "close the thread" for later readers. (I never advanced beyond my last post--apparently I just forgot about it--completely. And now, seven years on, it "feels" like I have even less time to divide among an even larger number of, probably ill-conceived, "projix." I'll hope for your understanding and forgiveness.)
--
gramp, the forgettable