XEN-L001: Color library


Many hardware projects involve some light effects. To achieve the effects various colorful LEDs and LED strips are widely used. Color is not a trivial scalar. Several notations exist to define a color. For example RGB, HSV, and HSL. XOD should provide a standard library to hold and transfer color values so that library authors don’t reinvent color-related nodes again and again.

Read on: https://github.com/xodio/xod-xens/tree/master/XEN-L001


Are there details that could be added for format-hex? For example, is the output really RGB in the format “RRGGBB”? If not, how are the values determined?

If it is RGB, a corresponding function to convert to color would probably be useful. For people who want a specific color, having to convert 0-255 to 0-1 is going to be a pain. You need to keep node to convert 0-1 range to color for those who want to use POTs or other built-ins to select color.


Thanks for the feedback!

Yes, format-hex just outputs a six-character string without any possible adjustment. It exists as a tool to quickly observe a result as text (for watch, LCD, serial) created by, say, potentiometers. A final resort for human-to-human and device-to-human communication. That’s it.

Do you mean that the [0; 1] range is so uncommon for colors that we also should provide nodes to pack/unpack color from/to three 0-255 values? I tend to agree actually, but, but, but… Isn’t the hex form (#fd7412) is even more widespread? Regardless of what’s more popular (0-255 triple or hex), how does it matter? Are xoders going to find a color in the internet or graphical editor and then try to output it on a LED strip?

I wonder what scenarios do you see especially related to the educational process.


I think the hex form is usually just RGB values concatenated together (2 hex digits allowing for 0-255 for each color), so the two formats over-lap somewhat.

We could probably get away with a node that just maps 3 input values to 3 output values 0-255 -> 0-1; input could be decimal or hex. These could then be fed to color node (or color node included inside this mapping node). Maybe there wouldn’t be much demand for this & documentation could just suggest using map node (but that creates a lot of extra pins for a simple mapping…). A hex string input node could split string into 3 values & feed to this mapping node…

I doubt many XODers will be looking to exactly replicate some other color, but they might be trying to convert existing code, or see a color they want to get close to. 0-1 range makes sense from a XOD perspective since it is an internal standard, but there is no easy way to convert to “real world” representations of color (or even to feed-back your format-hex values back into XOD code). Also, keeping parallel with color-hsl, to-hsl, color(-rgb?), to-rgb for hex node(s) makes sense.


OK, got it.

What do you think, would addition of the following node make the lib unarguably better?


Constructs a color value from red, green, and blue components expressed as byte values. Use decimal (0d to 255d) or hexadecimal (00h to FFh) byte literals. For example, if a graphical editor shows a blue as “#287ec9” or “rgb(40, 126, 201)” use the following literals for R/G/B: 28h/7Eh/C9h or 40d/126d/201d.

Dir Pin Type Default Description
in R byte 0d Red
in G byte 0d Green
in B byte 0d Blue
out color


That would be perfect.

Should color be renamed color-rgb for consistency?

(The following very intentionally uses soft words like maybe, consider, perhaps. Are you looking to provide just what is needed, or a complete & consistent library?)

Also for consistency, maybe consider changing format-hex to to-hex & maybe adding color-hex (just a wrapper to split string & pass to color-rgb-bytes). More for consistency/convenience than because it is really needed…


I’m looking for a balance. New nodes might be added later, but the initial set should form a strong basis. Perhaps it is a good idea to postpone the addition of nodes that are too vague or controversial in the current moment. The real use cases can show an optimal solution later.

Should color be renamed color-rgb for consistency?

Well, now we have color, color-hsl, and color-rgb-bytes. Indeed, inconsistent. But we “cannot” rename color because it defines the type name. Otherwise, the type will be color-rgb everywhere. But we can hide the color node by making it a utility. Then we can provide the color-rgb node for constructing with [0; 1] range values. Makes sense, thank you.

maybe consider changing format-hex to to-hex

Format is a verb commonly used for converting something to its string representation. We have format-number, format-timestamp, etc :thinking: So the consistent name should even be format-color-hex. But isn’t it too long? If we are thinking about HEX as of an alternative form of color, then yes to-hex matches to-rgb and to-hsl perfectly. I’m not sure how should we think of HEX.

maybe adding color-hex

This opens many questions about input validity. Are the following should be considered valid?

  • "#ffd400"
  • "fd0"
  • " FFD400 "

What should we output for an incorrect input like "Hello"? I think some kind of universal approach should be established to make nodes that parse things (numbers, timestamps, colors, etc). They are by definition can be supplied with invalid input.

Because of these questions, perhaps, we should skip the color-hex for now.


Sounds good. I just figured these were questions that would be easier to address now than after library was created & people were using it.