[css-color-4] HWB with negative white or black

[svgeesus]

in Converting HWB Colors to sRGB, the sample code assumes that white and black are positive. It is not stated what happens if they are negative. This affects normalization (when white + black >= 100).

Negative values will not happen if sRGB color are converted to HWB but can happen if wider-gamut colors are converted to sRGB and also if specified manually.

color(prophoto-rgb 0 1 0) is rgb(88.92% -0.8% 56.2%) which converts into HWB just fine, giving hwb(321.87997894493725deg -0.799896411311526211 .075823374398276) and converting back to the original sRGB value complete with negative green component.

But I am concerned with things like hwb(120 -10 100) because -10 + 100 = 90 so it is not an achromatic color even though black is 100%.

[facelessuser]

Never mind, I see why CSS chose the HSL algorithm now, this can be ignored

Wouldn't such colors not naturally occur? Any non-achromatic color converting to HWB will never convert to a perfect 100 for black with a negative white. It would always be some non-100% black and a negative white.

HWB has a close relation to HSV, and you only get a perfect 100 for black when V is zero (achromatic black). Saturation for HSV in this case doesn't matter since V is 0. I understand that CSS defined HWB in terms of HSL (which I assume is so it didn't also have to include HSV in the spec), but algorithmically, this case wouldn't occur with any normal color.

Looking at the CSS HWB algorithm that uses HSL to calculate HWB, you could contrive a solution that creates such an HWB color with 100% black and a negative white by using something like color(srgb 0 -0.01 -0.01), but it's an imaginary color with negative lightness. It's not a color with any real application.

> new Color("color(srgb 0 -0.01 -0.01)").to('lab');
Color {
  coords: [ -0.543590598185336, 0.6922703323236079, 0.24785653090937942 ],
  alpha: 1
}

It may make sense to make the HWB conversion, which goes through HSL for CSS, mimic the actual HSV algorithm in this sense and say if black is 100, then white is zero. Then at least such colors won't occur naturally through conversion and it matches the behavior of the HSV -> HWB conversion.

function rgbToHwb(red, green, blue) {
    var hsl = rgbToHsl(red, green, blue);
    var black = 1 - Math.max(red, green, blue);
    var white = (black === 1) ? 0 : Math.min(red, green, blue);
    return([hsl[0], white*100, black*100]);
}

I guess something could also be done in the reverse for HWB to RGB. If black is equal to 100 and white is negative, then just return black as you cannot have negative lightness.

Then you can just explain them away with if black is equal to 100 and white is negative, the color is black because you can't have a negative lightness color.

HWB isn't the only color space that simply doesn't allow for negative lightness colors, Jzazbz will also convert similar colors as just black. It's just the limits of the algorithm.

> new Color("color(srgb 0 -0.01 -0.01)").to('jzazbz');
Color { coords: [ 0, 0, 0 ], alpha: 1 }

[facelessuser]

I guess I hadn't realized that the HSL approach that CSS uses allows for negative lightness values to roundtrip where the HSV algorithm does not, so I see the advantages of why CSS chose to use the approach they do. So I guess my previous statement can be ignored. Also, my statement only focused on the negative lightness case, not the HDR white case.

[tabatkins]

The sample code was definitely written under the assumption that it was only handling sRGB-gamut colors. I have no idea what the right answer is for wider gamuts.

[facelessuser]

It seems the only real thing you can infer from an HWB color is that w+b > = 100 is achromatic. w or b equaling 100 is not sufficient.

[romainmenke]

I also encountered some issues with the sample code for hsl and wider gamut colors : #9222