Cartan Node Library 2.3: GetPixels() on a path(s)

Leveraging John's wonderful Image node in Cartan Node Library 2.3, I was interested in:

1. Dynamically defining points located on any type of geometry, e.g., a line or paths from an imported SVG file
2. Translating shapes (e.g., triangles) to those points along the path
3. Adjusting the orientation of the shapes to follow the direction of the paths. Uses the Shape On Path node to achieve this.
4. Getting the pixel color values from the underlying image based the points along the path
5. Using the color values from Step 4 to fill the shapes from Step 3

Version 1_1 is a cleaned up version based on very helpful tips from John. Note: There are 2 .ndbx files:

1. GetPixels_FromPtsOnCurves_v1_1_1_modifedCode.ndbx, which uses the modified image.py file located in the folder "Modified_Code" and,
2. GetPixels_FromPtsOnCurves_v1_1_2_originalCode.ndbx, which uses the original image.py file located in the folder "Original_Code" and an updated network (Steps 5_2_x) attempting to resolve the persistent error defined below.

File "/[your path]/Original_Code/image.py", line 101, in image_path
c = bi.raster.getPixel(x,y,[0.0,0.0,0.0])
TypeError: getPixel(): 1st arg can't be coerced to int

To convert the Numbers to Integers, I tried "extracting the x,y values, rounding them, and recombining them with make_point" in the file GetPixels_FromPtsOnCurves_v1_1_2_originalCode.ndbx in Steps 5_2_x. However, I believe the method for the Make Point node, makePoint(double x, double y) method within CoreVectorFunctions.java automatically converts the datatype back to a double.

Even when this error is resolved, the accuracy of the relationship between the Centroid points for each triangle and the background colors is off due to the node based conversion to Integers in Step 5_2_x.

When forcing the Numbers to Integers in the modified code, this challenge is resolved as can be seen in "GetPixels_FromPtsOnCurves_v1_1_1_modifedCode.ndbx". Conundrum!

Drew,

Thanks for sharing this as a new thread. I hope others will see this and maybe contribute their own experiments with this technique.

But first we have to resolve this registration/rounding issue.

When I suggested rounding the points to the nearest pixel, I meant just rounding the values, not changing the number format. Rounding the pixels would have a very subtle effect, probably too small to notice. Changing the number format, even if you could do it, would have no effect at all that I can see.

The error you got confused me at first - shouldn't happen. But then I noticed that the version of image.py in your Original_Code folder is not actually the original code. It's been slightly altered somehow which you can see if you get info and compare the exact file sizes. When I replaced it with a fresh copy of image.py (which I placed in the "Truly Original Code" folder), the error went away.

I think the misalignments you are seeing have nothing to do with rounding to the nearest pixel. Instead it is caused by the centroid node.

Nodebox shapes are located by their center point as determined by the centroid function. This function actually returns the center of the bounding box around a shape. For some shapes, particularly triangles, this may not be what you expect. For some skewed triangles, the centroid may even land outside the triangle! And if the triangle is rotated, the centroid will move in relation to the triangle - not what you want in this case.

So instead of centroid, for triangle shapes, I recommend another node from the Cartan Node Library: tri_center. This node returns the true center of any triangle.

In the attached folder I made a new copy of your code called GetPixels_Better_Centroid.ndbx which bypasses all the rounding and just substitutes tri_center for centroid. The resulting registration is much better as you can see by the screenshot.

Let me know if this works for you. If so, you can simplify your code and stick with the truly original version of image.py.

John

Hi John,

-2 pts for me for the mistake in terms of the original image.py file. This is great as it is!

In relation to the center point, I plan to use a wide range of shapes generated either from within Nodebox or imported from SVG files so I believe sticking with the centroid makes the most sense, but I could be wrong.

In terms of the registration, I did closer analysis today between the imported image and what is displayed. I noticed that even when the Image Quality is set to "Best put painfully slow", the details smaller than 4-5 pixels might not be displayed properly but still exist within the source image. This is to be expected in the conversion process when taking responsiveness into consideration. It's a great and worthy trade off for the ability to see a representation of the image within Nodebox!

Thank you John!

Drew