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

drew's Avatar


11 Jul, 2021 04:20 PM

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 file located in the folder "Modified_Code" and,
2) GetPixels_FromPtsOnCurves_v1_1_2_originalCode.ndbx, which uses the original 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/", 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 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!

  1. Support Staff 1 Posted by john on 12 Jul, 2021 10:12 PM

    john's Avatar


    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 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 (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


  2. 2 Posted by drew on 12 Jul, 2021 11:40 PM

    drew's Avatar

    Hi John,

    -2 pts for me for the mistake in terms of the original 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!


Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:


Already uploaded files

  • 492 KB
  • GetPixels_on_Path_v1_1.jpg 325 KB

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac

Recent Discussions

29 May, 2024 05:47 AM
29 May, 2024 05:15 AM
29 May, 2024 05:12 AM
28 May, 2024 07:37 PM
25 May, 2024 11:52 AM


24 May, 2024 07:39 AM
16 May, 2024 02:11 AM
14 May, 2024 01:29 AM
12 May, 2024 07:46 PM
05 May, 2024 04:38 PM
03 May, 2024 06:50 AM