View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0013113 | Scribus | - | public | 2015-06-04 23:45 | 2015-06-22 18:50 |
| Reporter | christoph_s | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Product Version | 1.5.1svn | ||||
| Target Version | Future Release - Nice to have | ||||
| Summary | 0013113: HLC Colour Picker | ||||
| Description | Now that we have CIELAB support, it would be great to implement an HLC colour picker. HLC is to LAB what HSV or HSB are to RGB. An example can be found here: http://tristen.ca/hcl-picker/#/hlc/6/1/124947/EFEE69 The JavaScript library is available on GitHub: https://github.com/tristen/hcl-picker/ | ||||
| Tags | No tags attached. | ||||
| Patch | No | ||||
|
|
This is a good idea, as HLC includes the advantages of Lab and is beyond this much more comprehensible and intuitive (HLC = Hue, Lightness, Chroma). Lab<->HLC is a simple rectangular <-> polar coordinate algorithm. Excel file: http://cielab-farben.de/downloads/lab2HLC_HLC2lab.xls VB and php code: http://cielab-farben.de/downloads/formeln.txt |
|
|
HLC is a rather uncommon naming for that space. In color management, the term LCh is much more frequently used. >> HLC includes the advantages of Lab It share also one disadvantage: lots of color of that space are physically not achievable, ie they simply can not be reproduced in real world. Also LCh has pretty big non linearity vs hues. Its especially noticeable in blue areas where blues often gets purple/violet when one decrease saturation. Because of that problem LCh space is in fact not used anymore for serious color management. One often prefer to use CIECAM based color space. |
|
|
I looked at the first implementation of LCh picker. Well it fell right in the trap I mentioned of physically unrealistic colors: with the default L* = 100, anywhere you click on the picker will generate a physically unrealistic color, unless C = 0. As a consequence the color preview is of course wrong, and there is no way it can be right in that case. |
|
|
>> HLC is to LAB what HSV or HSB are to RGB. There is one thing pretty different tho : LCh is not a circular/conical/cylindrical colorspace! It is pretty different in that respect from HSV or HSL. LCh coordinates are just the expression of Lab values in polar coordinates. Given the common range of a* and b* values for Lab values, usually -128 to 128, that means the acceptable range of C values depends of LCh hue. In fact a LCh picker is not different from a Lab picker, it's just the coordinates names and their values which change. |
|
|
Jean, "Given the common range of a* and b* values for Lab values, usually -128 to 128, that means the acceptable range of C values depends of LCh hue." Correct, hence the choice of HLC (i.e., Hue first) ;) |
|
|
>> Correct, hence the choice of HLC (i.e., Hue first) ;) Pointless remark. At the end that means the LCh/HLC color map is not any different from the Lab colormap. Otherwise you will get Lab <=> LCh conversion errors when switching between modes. So basically a proper LCh/HLC pciker is a Lab picker where you just rename the sliders and do a proper Lab => LCh conversion. |
|
|
I prefer the order HLC because it corresponds to our intuitive colour selection in the order "Hue, Lightness, Saturation (Chroma)" - it is the best understandable order. The ab range is normally -128..127 (in Photoshop). Concerning the physically unrealistic colors problem: These are also the case in Lab. Example: Lab 0 127 127/ HLC 45 0 135 shows a dark red. But this colour does not exist. Such Lab values cannot be generated by a spectral distribution. In other words, a lightness 0 can not have a saturation (a,b different to 0), same for white (L=100). The highest a;b values are possible in the middle L range. The Lab colour space is very uneven, there is no simple formula for the maximum a;b values depending on lightness. |
|
|
>> I prefer the order HLC because it corresponds to our intuitive colour selection in the order "Hue, Lightness, Saturation (Chroma)" - it is the best understandable order. Due to the hue linearity problems of Lab/LCh space, choosing hue first does not make much sense. Go explain a user that the blue he has choosen first turns purple once he change saturation... A better approach would be to use the CIELuv colorspace to compute hue. Not perfect, but that space behaves better in that respect than CIELab (but still worse than the CIECAM spaces). In the end, choosing some random value from a LCh color picker is probably not a common usage scenario. The values must be obtained from a measurement device or from some swatchbook to get predictable result and real world color. In such scenario choosing hue first does not make much sense either as it's more than likely that user will have L as the first value to enter. |
|
|
|
|
|
I still prefer HLC. CIELuv and CIECAM maybe more perceptual, but they are another colour space and, as CIELAB, they are hard to understand. I do not see that a blue turns purple when changing the CIELAB C value. Where is it? The uploaded file shows the complete CIELAB space in equal H-L-C variation. (It contains the CMYK gamut only, but the RGB's gamut additional squares do not behave different.) What behaves unforeseen: Non-existing colors. I mean if you vary a HLC 240 20 10 (which exists) to a 240 20 100 (which does not exist, it is no color) this will be not controllable. n my eyes The best would be to have an algorithm that goes down to the limitations of CIELAB's outer wrapping if a colour is outside. I do not know such an algorithm. (this is not to be changed with RGB/CMYK gamut - quite a different thing) |
|
|
>> I do not see that a blue turns purple when changing the CIELAB C value. Where is it? Start for example with a blue with H=270°C, L=60 and C=128. When you decrease the saturation the effect is pretty noticeable. In the PDF you uploaded the effect can also be seen in the area where H is around 250-280°C. This problem of Lab/LCh colorspace is well known. When computing ICC profiles for eg, Lab is only used as the colorspace to store end results. Intermediate computation use other spaces such as CIECAM02. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-06-04 23:45 | christoph_s | New Issue | |
| 2015-06-05 07:37 | christoph_s | Relationship added | related to 0013000 |
| 2015-06-08 08:37 | dtpholgi | Note Added: 0035339 | |
| 2015-06-21 23:25 | jghali | Note Added: 0035469 | |
| 2015-06-21 23:35 | jghali | Note Edited: 0035469 | |
| 2015-06-22 00:14 | jghali | Note Added: 0035470 | |
| 2015-06-22 00:18 | jghali | Note Edited: 0035469 | |
| 2015-06-22 01:00 | jghali | Note Added: 0035471 | |
| 2015-06-22 05:22 | christoph_s | Note Added: 0035472 | |
| 2015-06-22 08:47 | jghali | Note Added: 0035473 | |
| 2015-06-22 09:17 | dtpholgi | Note Added: 0035474 | |
| 2015-06-22 17:51 | jghali | Note Added: 0035476 | |
| 2015-06-22 18:15 | dtpholgi | File Added: andruck_lab.pdf | |
| 2015-06-22 18:25 | dtpholgi | Note Added: 0035479 | |
| 2015-06-22 18:50 | jghali | Note Added: 0035482 |
