In short: how to get, for example... #C990C0
from String data, as opposed to "#C990C0"
?
I am prototyping something in Processing so ideally looking for a solution with no additional Java libraries.
In my data (json) hex colour values are stored as Strings.
There is an unhex()
function in Processing that converts the String to an int, but this int is not meaningful as a representation of colour in Processing... and the hex()
function converts to a String, not a hex type.
You can hardcode, say fill(color(#C990C0))
, but you can't cast the String "#C990C0"
to #C990C0
to do this programmatically because there isn't a Hex primitive type.
Maybe the answer is to do something weird with the byte
primitive type?
You're on the right track using unhex()
.
Processing tries to be too nice in this case and it ends up being confusing.
Within the Processing editor you can use color(#C990C0)
(though this wouldn't work in other editors easily).
Similarly color
type is an int
behind the scenes.
(It stores the 4 bytes: alpha, red, breen, blue as a 32bit integer)
And there's yet another catch with unhex()
: number formatting.
You can use digits from 0
to 9
and letters A
to F
, but not other prefixes (such as #
or 0x
for example).
On top of that it expects colours in ARGB
(not RGBA
) and that means you do need to specify the alpha value (otherwise, if the first two hex digits(alpha channel) is missing 00
is implied so your colour will be invisible).
In your case, you'd format the colour as: "FFC990C0"
Here's a test sketch:
JSONObject myData = JSONObject.parse("{\"color\":\"FFC990C0\"}");
color myColor = unhex(myData.getString("color"));
fill(myColor);
rect(0, 0, 50, 100);
// notice the colour doesn't show because the FF alpha prefix is missing
fill(unhex("C990C0"));
rect(50, 0, 50, 100);
Update After a bit of digging around it was interesting to spot this:
println(JSONObject.parse("{\"color\":0xC990C0}").get("color") instanceof String);
It prints true
when I was expecting false
(expecting Integer
instead). (it does work as expected for 0-9
, but not A-F
).
Processing thinks 0xC990C0
is a String
(notice it has no double quotes surrounding the value), probably due to this.
Also, unhex()
uses Long.parseLong()
which limits the usage of 0x
, #
or similar prefixes.
You can use Long.decode("#C990C0")
instead though (e.g. color myColor = Long.parseLong(myData.getString("color")).intValue();
)
.