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.
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!
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.
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-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-timestamp, etc 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-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 "
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.