Feature Request: Get HSV hue, saturation, value from color

[jmarquis]

I love the HSL color model and the functions for getting hue, saturation and lightness from a given color. Unfortunately, Photoshop only uses HSV (or HSB, as Adobe calls it). Converting to HSL is a pain when working with many PSDs from multiple designers. The hsv function in LESS is a fantastic help, but there's no reverse functions to help me adjust colors for gradients, etc. in my mixins.

Something like:

hsvhue(@color)
hsvsaturation(@color)
value(@color)

I found some JavaScript algorithms for converting the colors here:
http://axonflux.com/handy-rgb-to-hsl-and-rgb-to-hsv-color-model-c

Might this be possible? Thanks!

[Synchro]

It looks like some code we've got for colour functions came from the same place.

In my branch I've added support for toHSV() in the color object and added hsvhue(), hsvsaturation() and hsvvalue() functions (just to avoid any confusion with HSL, and value just doesn't seem like a sensible name for that function!) to use it, but the test case is failing on the hue part - any idea why? Got any test cases you could add?

[ricardobeat]

@jmarquis send this to your designer: http://en.wikipedia.org/wiki/HSL_and_HSV#Disadvantages :)

[Synchro]

@ricardobeat, they may have technical downsides, but both HSL and HSV are very practical in a way that the Lab space is not - you don't look a an image and think 'it needs a bit more b'. Lab has exactly the same shortcomings as rgb in that respect - changing hue or saturation will most likely require unintuitive changes in all three channels.

[ricardobeat]

The deal is that HSL/HSV look intuitive but they aren't, the models are not
correct with regards to their stated values (brightness, saturation). The
current saturate/desaturate functions in less do exactly what they state,
while changing hsvsaturation also affects lightness.

RGB is pretty easy to work with - increase all three components for
lightness, saturation is relative between them (equal values = gray), it's
plain color theory. It's also an absolute color space unlike HSL/V.

Anyway, this is not the place for this, sorry I started it. We can continue
the discussion over e-mail or twitter.

2013/1/23 Marcus Bointon notifications@github.com

@ricardobeat https://github.com/ricardobeat, they may have technical
downsides, but both HSL and HSV are very practical in a way that the Lab
space is not - you don't look a an image and think 'it needs a bit more b'.
Lab has exactly the same shortcomings as rgb in that respect - changing hue
or saturation will most likely require unintuitive changes in all three
channels.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1143#issuecomment-12585081.

[jmarquis]

I agree with you @ricardobeat, HSL is better (I've done my research before), but the problem is that Photoshop only has HSV/HSB, and Photoshop is the industry standard. So when a designer tells me "oh this color is always the base color +10% brightness," the fact that HSL makes more sense does nothing to help me.

The best solution would be for Photoshop to adopt HSL, but alas :/

Thanks @Synchro for the quick work! I assume this might end up in 1.4...? Not sure how things work here.

[Synchro]

Yes, it should be in 1.4.

[leeoniya]

for brightness/lightness/luma/value (whatever you want to call it :), i've been getting great results with the HSP color model. http://alienryderflex.com/hsp.html

though not standard, it's visually better than all the standard ones. if the sqrt is too computationally expensive, you can just fallback to plain weighted rgb values...either way the weights are still used. i found luma rec 709 values to be better than 601 personally on my sRGB displays. i use them for luminance calcs in my pXY.js canvas pixel analysis lib. https://github.com/leeoniya/pXY.js/blob/master/src/pXY.js#L214

[Synchro]

The luma color property and less function (which I just improved this morning) uses the rec 709 coefficients, mainly because that's what the W3C recommends.