HSV formats for ColorEdit consistent with Photoshop / GIMP etc.

[dougbinks]

The current HSV format for ColorEdit presented to the user is a byte integer (0-255) or float (0.0-1.0) however both Photoshop and Gimp use degrees for H (0.0-360.0) and % (0.0-100.0) for SV.

For example, from Photoshop color picker guide:

Using the HSB color model, the hue is specified in the color field, as an angle from 0° to 360° that corresponds to a location on the color wheel. Saturation and brightness are specified as percentages.

Note that Photoshop calls Value 'Brightness' hence HSB instead of HSV.

HSL in CSS3 also uses the angle/percentage format, HSL is, however, different from HSV / HSB.

If enabling having this form of presentation is desirable (which I think it is) the question is raised as to whether this should be as an additional optional format or to always use this format when displaying/editing HSV.

The version of Inkscape I have uses 0-255 as per dear imgui, but this has been noted as a bug: http://inkscape.13.x6.nabble.com/HSL-values-td4970095.html

Given the above my own preference would be HSV to always be floating point values represented as degrees and percentages as per the above, i.e.:

H: printf("%3.1f", H*360.0f); to get 0.0-360.0 S: printf("%3.1f", S*100.0f); to get 0.0-100.0 V: printf("%3.1f", V*100.0f); to get 0.0-100.0

My reasoning is that there is no exact equivalence as with RGB color bytes, so Uint8 format is not required for perfect color io, and there is always a translation so pure float also offers no benefits. Consistency with art packages and web tech is, however, very useful.

Thoughts welcome. I'm willing to investigate a PR for this if needed.

[paniq]

My feelings concerning HSV/HSL are growing more difficult lately. Many graphics editors have begun supporting YUV color spaces with uniform perceptual brightness and non-gamma compressed brightness levels because that way artists can change hue or saturation without having to readjust lightness, and gradients are interpolated in linear light space rather than in gamma space (interpolating in gamma space is imo a mistake).

As to the proper units for HSV/HSL/HSB, the latest editor I have been using is GrafX2, where each element of HSL (where S=100%, L=50% is the fully saturated color, L=100% is white) are visually mapped to three Uint8's in the range 0..255.

I don't care much about the units of HS specifically; 0..360° and 0..100% sounds good to me, if both are floating point values. As to the scale of L, I prefer 0..255, as at S=0%, these translate directly to the corresponding RGB value (e.g. at L=186, the resulting color is R=186, G=186, B=186.).

It is necessary to admit that different people need different behavior, and thus it would be enough for me to be able to build my own color dialogs; so as long as I get access to the label-less color wheel widget, I don't really care what the default prefab color dialog does.

[ocornut]

I'm terrible at color spaces so I'll leave it open for more commentary.

One thing to consider is that down the line we'll want better support for HDR colors (with maybe a gradient in the color preview + and no clamping in RGB space). It probably makes even more sense there to display some components in a format that can more naturally leave the 0..255 limit (200% looks more natural than 510...).

As to the scale of L, I prefer 0..255, as at S=0%, these translate directly to the corresponding RGB value (e.g. at L=186, the resulting color is R=186, G=186, B=186.).

Would you prefer to display both RGB and HSV together anyway, in which case this property is less valuable?

It is necessary to admit that different people need different behavior, and thus it would be enough for me to be able to build my own color dialogs; so as long as I get access to the label-less color wheel widget, I don't really care what the default prefab color dialog does.

As a reminder for readers: Most settings can overridden in the call to ColorEdit4 and ColorPicker4(). There is also SetColorEditOptions() (which is very unusual in the whole api) to override the default settings, which is meant to cover this sort of case (some applications/users may use different defaults). Finally a right click on any color widget allows to change the defaults (pictured below).

So we want to decide sensible defaults. We can also attempt to avoid adding new options if they are unnecessary. So ideally if there was a consensus decision that HSV should always be displayed as Ang/%/% it would be ideal.

Finally, if someone it interested in adding code to support HSL be my guest ;)