As the title says. I’m not finding a reason why Processing does not support the CIELAB color space.
That doesn’t clarify why Processing doesn’t support it natively.
It is impossible for the Processing developers to implement everyone’s wish list so there are loads of things not implemented in the Processing core.
Of course Processing can use contributed libraries created by third party developers so perhaps someone might create library to implement the LAB color-space.
This isn’t a feature request. LAB is incredibly useful for the kinds of things Processing is geared towards, so it’s no doubt a desirable feature. Also, it’s not something that’ll complicate the language.
My question if precisely to gather if it’s something that the devs just haven’t gotten around to yet, or if there’s a technical impossibility (and what), or if they don’t want to implement it (and why).
Well, since you could use it with a Library, that means that it is technically possible to implement it. So they probably just didn‘t do so for one of 2 reasons. Either they didn‘t want to/see the Need for it, or they didn‘t get around to doing so until now.
I have created several contributed libraries for Processing and it is impossible to provide every feature that every user wants so you aim for those features that most users are likely to use the most. I suspect that the Processing developers will not implement LAB because there is insufficient interest in using it. Of course lack of interest could be due to lack of awareness.
It seems to be to be an ideal candidate for a contributed library that can convert between different color spaces and is user extendable with new color spaces.
3 Likes
In that same vein, I’m surprised there’s no Processing library to add LAB support.
From my experience with Processing, plugging in a chunk of Java code to add functionality is seldom straightforward, always a bloody pain to get to work in a sensible way, and if you’re not a Java programmer, then forget it.
Well, since you could use it with a Library
Are you aware of specific library you can plug-and-play to Processing, to add LAB support? If so, could you please link me to it?
Sure, here is one:
It was hit #7 when I Googled “processing.org lab color”. I find that adding “.org” really helps with relevant results.
Note: I don’t see it in PDE Contributions Manager, but I do believe it is Processing 3 compatible – untested, but that version should be “Chroma-3,” here:
Or for methods to use standalone without a library, see the old sketch by @GoToLoop that @Lexyth posted below.
4 Likes
I‘m not sure if this is what you need specifically, but first of all, you can convert RGB to LAB like here :
Or you can take a Look at the Chroma library.
Edit : @jeremydouglass it was first hit for me with : processing library cielab colospace 
2 Likes
I’m not opposed to someone adding a colorMode(CIELAB) to Processing core in the future, but I can see why it made sense not to. There are competing interests – one is the artistic community (for whom perceptual uniformity is valuable), but another is code maintenance for a small project, another is performance (if you can switch modes there must be a base representation and multiple conversion points with potentially slow math), and another very important one is the teaching-programming or first-programming-language mission of the project.
First time programmers – including kids – know what red, green, and blue are, understand that they are directly related to pixels, and can quickly learn how to reason about them. Most have no idea what the * a * b * are in CIELAB, and even if you can explain it, those variables may remain challenging to reason about. That is not a good match for an early-learner focused API.
Now, there are a lot of things in Processing core that are similarly advanced (like PMatrix, PShader, or PVector.cross()) but that might be one reason why it makes sense that LAB was not baked in from the very beginning.
2 Likes
Yet processing supports HSB, and those concepts are just as obtuse to a beginner. Also, adding LAB doesn’t mean beginners are obligated to use it. They can just as well keep using RGB, and switch to LAB when they feel the need for it.
In addition, for first-time programmers Processing has way more problems than how to pick colours. The first one being the choice of language. Java is an absolutely atrocious and unforgiving language for beginners. I don’t even think processing files are worthy of being called sketches, because everything requires so much boilerplate (in comparison to other languages like Python, Ruby, or Javascript), doing just “a quick thing” (a sketch) takes considerably longer than it needs to. And I’ve seen one of the creators (don’t remember if it was Reas of Fry) say that if they were starting today, they definitely would not have chosen Java.
1 Like
Maybe it depends on the learner. I have found Hue and Brightness extremely easy to explain in most cases – hue as “a rainbow” or “a box of crayons” is sometimes easier for some beginners than RGB color mixing – in fact, some people show up expecting hue (“a box of crayons”) to be the base color model for computers. Saturation can get a bit tricky for some.
Totally agree with you there.
Yes, I think maybe both of them have said that. It is a fair point! p5js and even JVM-mapped modes like Python mode partially address that, but that historical Java-ness is also in the API, and parts of it show up even in non-Java modes.
1 Like
There is (almost) nothing more obtuse than trying to teach a child that in order to make yellow, you have to mix red and green.
1 Like
giCentre utilities — giCentre contains lots of use colour conversion helpers and is fully Processing compatible.
1 Like