gramp wrote:
I got this error with both versions however:
Dump Path Colors Message
Error while executing script-fu-sg-dump-path-colors:
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.
gramp wrote:
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.
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.
Attachment:
sub-sample-aliasing.png [ 10.66 KiB | Viewed 2862 times ]
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?).
gramp wrote:
Ideally, there would be a set of contour paths, featuring uniform elevations, and a second set of paths, roads, with changing elevations.
I think you have the right idea with your "stepped" contour layer, though the Posterize filter will only work properly for grayscale images.