HSL and CMYK pickers shift colors

Bug #166622 reported by ScislaC on 2005-06-15
48
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Inkscape
Low
Jon A. Cruz
inkscape (Fedora)
Won't Fix
Medium

Bug Description

Just done in current CVS on win32...

Once this happens, it tends to keep going... but, it
only happens sometimes, and with certain colors it seems.

1) Open inkscape and create a path or object (I used a
square in mine)
2) Open fill and stroke dialog and make sure it's on
the HSL color picker and fill the object with the
values set to H:0, S:66, L:238, A:255
3) Just alternate clicking between the spinboxes for S
& L, or hold tab to cycle through all boxes...

The numbers will shift (reproduced like 10x prior to
submitting this). I noticed that it will also sometimes
even shift the hue as well depending on what colors you
use.

I will say that I have seen the color chooser acting a
little strange sometimes, but this is the first time I
set out to be able to reproduce the problem.

Silsor-users (silsor-users) wrote :

Confirmed with current CVS on Debian.

This is most likely because the HSL->RGB and RGB->HSL
mappings are not 1:1. The HSV space has the same problem.
The only way to prevent this is to store the actual HSL
value in an extension attribute, which is very messy.

ScislaC (scislac) wrote :

I can somewhat understand the conversion not being 1:1
issue, but why would that cause continuous shifting when no
changes to color are being made?

For example, when you do what I described and hold down TAB
so it cycles through the fields, the end color ends up being
drastically different from the start color. I can understand
it bouncing up and down within some range to get as close as
possible to RGB (+/- up to 5 increments or so), but to keep
adjusting until it is stopped by the min/max value seems a
little... clunky.

If we do end up getting Color Management in, will that
alleviate this problem? Or will it always exist until the
SVG spec uses more than just the RGB color space?

You can answer your question yourself. The functions
sp_color_hsl_to_rgb_floatv and sp_color_rgb_to_hsl_floatv in
color.cpp are quite simple. They take values in 0..1 range.
Use them to convert your HSL value to RGB and the result
back to HSL, and do it several times in a cycle. If there's
drifting of values, this means it's in the conversion
functions and we cannot do anything about it. If such direct
conversions do not drift, the error is elsewhere.

ScislaC (scislac) wrote :

But I guess the thing I don't understand is, why is it
converted if there is no change/modification of the values?
If there was it would make sense...

In most gfx apps when you export to nearest websafe color
(or convert otherwise), the results will always be the same
if the values do not change, it only converts when
necessary.... so why do we convert even when no changes are
made?

I understand that exporting is a one time operation, but I
would assume that conversion would be the same... plus as I
said, it makes sense if it happens within a range, but for
it to continue in one direction and only stop when it maxes
out says it's got issues. (unfortunaty I use HSL more than
RGB... and I did prefer HSV even, but that's neither here
nor there because the same problem existed for that)

I'm not trying to give you a hard time, just trying to
understand why it works like it does w/ the constant
adjustment in one direction, and I can't figure out via the
source just quite yet.

Because you need RGB to save color to SVG. You can't store
HSL. SVG does not allow you that. So whenever an HSL value
changes, it is converted to RGB and saved. Whenever you move
focus or selection, it reads RGB back and converts to HSL to
update the sliders. So when you fiddle with it it goes
HSL->RGB->HSL->RGB etc.

Please do the experiment as I described, this will make it
more clear if it's only conversion or we have some other
problems with it (such as low precision).

Scislac: so did you do the experiment?

Rwst (rwst) wrote :

see also 1436232

Bug Importer (bug-importer) wrote :

This is a very counterproductive behaviour because graphic designers have
to deal with predefined colors from graphic manuals or CMYK translations of
spot colors (Pantone, RAL, Toyo etc...). If some color combinations cannot
be achieved (and it was my case), then it's a major problem for the users.

Mercury (mercury13) wrote :

What a heck, confirmed!!

The way to circumvent is rather simple. Store the object the color corresponds to. If the object is the same and current HSL/CMYK color maps to the same RGB color, change nothing.

But the problem is more fundamental. Inkscape uses SVG as internal format. In some aspects, Lack of CMYK colors if rather restrictive for those who design for paper. After some time, you'll end up with two separate formats: Inkscape internal (for example, *.ink) and W3c export (*.svg).

Changed in inkscape:
status: New → Confirmed

Description of problem:
Changing the Saturation value in the HSL color space is problematic due to odd interactions between color channel values.

Version-Release number of selected component (if applicable):
inkscape-0.46-5.fc10.x86_64
inkscape-0.46-6.fc10.x86_64

How reproducible: Always

Steps to Reproduce:
1. Create an object
2. Open 'Fill and Stroke' dialog to set its color
3. Select HSL color space
4. Set color to:
 H: X (any X > 0)
 S: 255
 L: Y (any Y > 0)
5. Decrease S by clicking repeatidely on the slider 'down' arrow

Actual results:
 First click: S goes 255 -> 254 (correct)
 Second click: S goes 254 -> 255 (bug, should go down to 253) AND H/L values are modified (bug, should not be altered)
 Subsequent clicks: S alternates between 254 and 255 (bug, should decrease by 1 at each click) AND H/L values are modified (bug, should not be altered)

The same kind of odd behaviour happens if the S value is modified by entering text. Example:
  type 250 in S component instead of 255, then RETURN -> value back to 255.

Expected results: Upon incrementing/decrementing (mouse click or enter text) the value of S, only this value should be modified accordingly, and values of H and L should remain unchanged.

Additional info:
This was _not_ introduced by the change from 0.46-5 to 0.46-6 (that fixed bug 467431).

I think some callbacks/signals updating the values must update/reset the wrong component somewhere.

Cheers.

Thanks for the report.

I'm able to reproduce locally (inkscape-0.46-2.el5.1).
Building the svn head to check whether it is fixed upstream.

On a second thought -- this might be due to the fact RGB is always used internally and not all HSL or CMYK combinations have corresponding 24bit RGB values.

The problem may come from the fact that the min/max values for HSL sliders (sorry I said HSV, inkscape uses the slightly different HSL color space), together with their mapping to real (H,S,L) values are simply _wrong_, and maybe the conversion RGB/HSL functions too.

HSL components are NOT addititive components on the same scale like RGB components are. Instead, HSL components are:
 H is a real number in degrees and should be in [0,360] (360 = 0)
 S is a real number in [0,1]
 L is a real number in [0,1] (Same thing for V in HSV color space BTW)

What applications (e.g gimp) use the following values in their color selection tool:
 H: integer in [0,360]
 S: integer in [0,100] (% Saturation)
 L: integer in [0,100] (% Lightness)

Inkscape uses [0,255] for all of them, which is valid ONLY if they map discrete values to real values as follows:
 H: [0,255] -> [0,360]
 S: [0,255] -> [0,1]
 L: [0,255] -> [0,1]

I suspect that inkscape has this all screwed up, as min/max values of [0,255] for HSL is _very_ uncommon and absolutely unintuitive.

I am not familiar with inkscape code. Could you check that the min/max values and conversion functions are correctly implemented in inkscape ?

Conversions functions are explained here:
http://en.wikipedia.org/wiki/HSL_color_space

Cheers.

(In reply to comment #3)
...
> I suspect that inkscape has this all screwed up, as min/max values of [0,255]
> for HSL is _very_ uncommon and absolutely unintuitive.
>
> I am not familiar with inkscape code. Could you check that the min/max values
> and conversion functions are correctly implemented in inkscape ?
>
> Conversions functions are explained here:
> http://en.wikipedia.org/wiki/HSL_color_space

Thanks for the explanation. I myself are very unfamiliar with HSL and HSV, thoguh what you say makes pretty good sense to me. While googling more about those, I stumbled upon a bug report [1] filed against inkscape which seems to describe the very same issue.

[1] https://bugs.launchpad.net/inkscape/+bug/166622

Given I'm not very familiar with inkscape internals either I suggest you add a comment there similar to comment #3. I'd be happy to include eventual patch for more sane values for ranges in HSL color space in Fedora package.

Changed in inkscape:
status: Unknown → In Progress

By the way, the relevant source file seems to be src/widgets/sp-color-scales.cpp [1], see the case after line 421 for how the sliders are set up (they all seem to have to be in the same range). Function sp_color_rgb_to_hsl_floatv() seems to do the conversion and look for uses of SP_COLOR_SCALES_MODE_HSV (actually a misnomer) macro for more HSL-related code.

http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/widgets/sp-color-scales.cpp?revision=17347&view=markup

I said I first though Inkscape used HSV and then HSL, but after looking at the code I am not sure they themselves know what they are using. Indeed, there seems to be confusion between HSV and HSL all over the place:
 - #define values all talk about HSV
 - functions all talk about hsl
as in:

<snip>
347 case SP_COLOR_SCALES_MODE_HSV:
348 sp_color_hsl_to_rgb_floatv (rgb, getScaled(_a[0]), getScaled(_a[1]), getScaled(_a[2]));
<snip>

If the goal is to confuse code readers, they couldn't do a better job.

As you mentioned, one needs to look at how the function
 sp_color_rgb_to_hsl_floatv()
does the conversion in order to know:
 - what really they are using: HSV or HSL
 - if values between 1 and 255 for color components are correctly used.

What remains clear is that:
 1. There is a problem in setting colors in HSL sliders (bug that should be fixed).
 2. The interface is _very_ confusing in setting all sliders in [0,255] for HSL. Nobody does this, it does not make sense (undesirable feature that should be changed to avid confusing users).
 3. The code is also confusing as whether it is using HSL or HSV (a problem for developpers, but a true one that calls for more documentation).

Note finally that restricting (H,S,V) to integers in ([0,360],[0,100],[0,100]) respectively, while being much better that it is now (and conforming to what gimp does), still has one drawback: not all 24-bit RGB values are accessible from other color spaces.

The REALLY NICE answer to this, if RGB values are used internally and they are restricted to 24bit, would actually be to set:
 - R,G and B components to 8-bit unsigned integers (in [0,255])
 - H, S and L components to FLOAT numbers (decimal to be exact):
 - H in [0,360]
 - S and V/L in either [0,1] (absolute) or [0,100] (percent)
  and each time a value is set, convert it to the nearest (R,G,B) valid color.
This way, all possible (valid) RGB values would be accessible through HSL and CMYK also.
But this may be too much to ask, in addition to being different from (but this time better than) what gimp does.

Cheers.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Changed in inkscape (Fedora):
status: In Progress → Won't Fix
SlaughterDog (slaughterdog) wrote :

Aye, I just tried to input a CMYK color in, and it kept changing it before I could even enter all the values.

Perhaps the CMYK color sliders should be scrapped, and instead, a feature which turns a CMYK color to the nearest RGB, but only once, so you can approximate it when given a color only in CMYK.

Jon A. Cruz (jon-joncruz) wrote :

Can't reliably do that. CMYK->RGB is a lossy conversion.

However, if you are really working in CMYK, you need to specify a color profile (since without one 'CMYK' numbers are meaningless). Had you set an ICC profile for the colors?

Carey Underwood (cwillu) wrote :

The problem isn't that the color doesn't exactly match the print color. The problem is that entering a cmyk value ends up giving a completely different color, because there's no way to tell inkscape "hold on a second, you don't even know what color I'm asking for yet".

A user who's been told that the company logo is c:81 m:18 y:34 k:0 is perfectly justified in think that he'll approximately that color when he types it in. Currently, the end result isn't even close, and depends on what order (!!) you type the cmyk values in.

Linking a color profile, setting that color profile and then entering the values is really long-winded and unintuitive for somebody who just wants "close enough".

(Commented on the right bug report this time)

Pablo Trabajos (pajarico) wrote :

Tested on 0.48 r9983. The HSL has gone. Jumping from a spinbox to another with TAB or mouse doesn't shift the values. Neither does it shift when switching from RGB<->HSL tabs in Fill&Stroke dialog. So The original report seems to have been fixed.

Pablo Trabajos (pajarico) wrote :

@Carey Underwood: As you may know or not, CMYK numbers don't mean a thing unless they are related to a CMYK profile. That's why Jon Cruz suggested you to use one.
If you already know the risks of not using color management and just want a "close enough" approximation the CMYK tab is your friend.

(I won't get into much detail about color management, I don't want to sound like an ass about it. If you feel I should get into more detail, let me know.)

However, I see your point. Values shift while writing them in each box which makes impossible to input some values verbatim. But I would say this is normal. What inkscape does is taking the common components of CMY and placing some "ink" on K. So when you have any value >0 on all three CMY spinboxes, the value on K and the rest of the spinboxes will change. But the resulting color seems rather logical.

For instance, you have 0/30/30/0, and then go to the C spinbox and input 30.
* What you would expect is this: 30/30/30/0
* What you get is this: 1/0/1/30
That's because CMY 30/30/30 is a neutral color[*] (i.e.: gray) so inkscape decides using K=30 and lowering CMY to 0 (or almost), since that's an equivalent neutral color.

So when you write c:81 m:18 y:34 k:0 the values shift because inkscape takes into consideration the three >0 values and looks for an equivalent color using K too.
In other words, even though values shift you're getting the "right" color (as right as it can which an unmanaged system like this).

[*] With real inks this equivalence is not right, C usually has to be higher than the rest to get a neutral color.

This is ridiculous, because most time when you do a print stuff you have to know exact colours, in order to make things as they have to, not some "close enough" stuff. It renders Inkscape useless, well, at least for me, and people alike, unless you do Web-related tasks-it's not production ready(able). Also, note that while you create something, espesially corporate ID-you'd rather work with CMYK numbers and Pantone colours, instead of "pointing thinger to the sky" saying RGB (HSL) values-"figure it out you self stuff". Design is about numbers, not about "close enough". Sincerely, SK (10 yrs. of ID and polygraph design).

jazzynico (jazzynico) on 2015-06-16
tags: added: ui
Changed in inkscape (Fedora):
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.