[p5.js 2.0 Beta Bug Report]: Ambiguity in how grayscale value should be evaluated in non-RGB color mode

[limzykenneth]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

p5.js version

2.0.0-beta.4 but applies generally

Web browser and version

No response

Operating system

No response

Steps to reproduce this

@perminder-17 Brought this up with me yesterday around difference in how color() (and in effect any function that accepts a color such as fill()) deals with a single numerical argument is given. The reference says that if only one numerical argument was given, it will be interpreted as grayscale value. However, there are ambiguity around how it should be interpreted precisely, especially in regards to maxes. See the following cases:

In colorMode(RGB) it is by default assumed that color(100) is equivalent to color(200, 200, 200) ie the value is effectively used for all RGB values, this makes sense. However, we can also set colorMode(RGB, 255, 200, 200) which creates an ambiguity when color(100) is called: what is the max value for this argument here? Is it 255, 200, or somewhere in between 200 and 255? (In 1.x, rather unintuitively, the blue max is used, not sure why)

In colorMode(HSB) or any other non-RGB color mode it is also not clear which max will be used if it were to create a grayscale color. In 1.x, it seems it is meant to use brightness/lightness max. We can possibly to the same for 2.0 for colors, so using lightness where available and brightness otherwise, although it can be a bit ambiguous still for HWB color which needs two values to get the full range of black to white color and for future potential color spaces where grayscale is not on a single dimension.

@ksen0 @davepagurek Do you have any thoughts on this?

[limzykenneth]

I'll fix the current behaviour to remove the breaking change, ie. single argument always provide grayscale color. How the maxes are interpreted will need to be worked out if necessary for certain color modes. Will try to do this in the next few days.

[ksen0]

"Single argument always provide grayscale color" I agree with this as the most common first use case that should not break. I think the max should be the smallest of the maxes: ie, if its an "uneven" color space, that means some channels can "go to 11" but the "grayscale" is still within the most "even" part of the color space.

Arguably doing something like colorMode(RGB, 255, 200, 200) may mean intending to do something more unexpected with a single-value color but that would introduce a lot of confusion in documentation.