HSL Granularity (8-bit x 3 -vs- 360/100/100)

[Duggeek]

(as of release version 0.47, packaged for Ubuntu Karmic)

The methods for setting a color are nicely varied; RGB values, HSL ("HSV" elsewhere), CMYK, the Gtk "color wheel" and even named definitions.

HSL is always my favorite; it lets me generate simple color-schemes and, to me, is the most functional of color selection methods. However, your implementation of HSL is very awkward to me.

The HSL selection sliders are coded to 8-bit (1 byte) values, or a range of 0-255. That makes sense for RGB mode, since colors in the web gamut are essentially three-byte values, but that shouldn't be the same for HSL. CMYK is properly ranged; using 1 through 100 for each value. (basically, each is a percentage)

Shouldn't HSL be a hybrid of value-ranges, not just a group of 8-bit registers?

My suggestion would be consistent with professional (including closed-source) tools; using a range of 1-360 for Hue (natural numbers; "degrees" on the color wheel and mathematically significant to color theory), where Saturation and "Lightness" (or Value) can be percentage (1-100) ranges, possibly sub-ranged to one decimal place. (0.1 to 100.0) Alpha can remain as an 8-bit register, since that ties into consistency with the other color-selection modes and your "RGBA" scheme.

As it stands, I believe this is a tremendous hurdle to overcome in making Inkscape a viable open-source tool for hobbyists and professionals alike. Of course, using the 360-degree range for Hue would also mean subscribing to the tenets of color theory and using precise standards of colormetrics, profile-matching and gamuts. (not only having "360" point to Pure Red, but also how to align equidistant points; additive model recommends 120 degrees is Pure Green, and 240 degrees is Pure Indigo-Blue) Since the preferences already ask for selections on Perceptual/Absolute/Relative colormetrics, I would think that the foundation is already in-place, no?

I know this is no small request, but as a designer it becomes an important aspect. In selecting a tool, this would be akin to whether I pick-up a Pantone-matched Letraset marker to do my work, or just pick up a Sharpie.

[Jon A. Cruz (jon-joncruz)]

Changing the number ranges are good, however anything beyond that is a bit of a loss. In his color FAQ, Poynton "explain[s] why HLS (HSL) and HSI are useless for the specification of accurate color".
http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html#RTFToC36

So subscribing to the tenants of color theory would cause us to abandon HSL altogether. We'll probably not do that quite yet.

[Duggeek (duggeek)]

Mr. Cruz,

That "FAQ" is not really Color Theory, per sé. Mr. Poynton talks about the precision and attenuation of colors, like the signals down a DVI or HDMI cable, but not actual Color Theory. He gives an opinion on the HSB color-selection model, but considering how ubiquitous HSB is in the design world, I'd hardly consider his word "gospel".

Color Theory is what we all learned in grade-school art classes; primary, secondary, harmonious and complementary colors. All of the definitions in Color Theory are based on a circle or "wheel" measured in 360 degrees.

I am happy to see that you agree with my core suggestion. I just want to see the new number-ranges under Fill and Stroke. It would give Inkscape the "feel" of a world-class design tool, IMHO.

For more on Color Theory:
http://en.wikipedia.org/wiki/Color_theory
http://www.colormatters.com/colortheory.html
http://www.worqx.com/color/

Thanks!

[Jon A. Cruz (jon-joncruz)]

No. It *is* color theory.

"Color Theory" is what I took classes on in college.

In the design world I would also posit that Munsell's contributions and color system are far more applicable than Brewster's. Additionally for the "design world", CMYK is far more prevalent than "RYB". RYB is what gets taught in grad-school art classes, but does not really cover the professional design world.

Oh, and HSB does have one *MAJOR* failing in that there is no solid connection to any real colors. Often things can wind up similar looking, but it can't be used to set absolute colors (like L*a*b*, Pantone, Munsell can).

[Duggeek (duggeek)]

Look, this is not supposed to be a forum for philosophical discourse or semantic bantering. This is about the development cycle, about the usability of Inkscape. All I introduced was a particular incongruence that is at odds with established conventions of design. Who else uses 0-255 range for Hue? That's my point.

Trolling in your own bug-base... honestly!

[pbhj (pbhj)]

Duggeek, not sure what tone that last line is but might I respectfully suggest that calling a bug team developer a troll isn't going to enamour you to them nor help progress a solution.

[Duggeek (duggeek)]

@pbhj -- Thank you for the sensible advice. The tone is disgust. I have no goals to enamor myself with dev's, especially when their only passion is touting some sense of superiority. My devotion in this context is to the Inkscape project; I use the app' frequently and would love to see it evolve into a world-class design tool. The aim of my suggestion was to improve Inkscape... that's it. My submission should be considered on its own merits, NOT based on the dev's ego. This is a bug-base, not a pissing contest.

[Pikadude No. 1 (pikadudeno1+launchpad)]

If Mr. Cruz is done spouting nonsense and Duggeek is done spouting anger and stereotypes of Inkscape developers, I'd like to throw in that fixing this bug would be a great favor for me; every other color picker in the universe, as well as CSS3 colors (which I use extensively in Chrome/Chromium extensions), all use 0-360 hues, and after all that, going back to Inkscape's HSL color picker is jarring.

[Jon A. Cruz (jon-joncruz)]

Patches welcome

[Pander (pander)]

Meanwhile Inkscape 0.48 provides HSL 3x 0-255.

For two reasons I would like to have the HSL 0-360 & 2x 0-100 also made available. For ease of conversation, lets call it HSV here.

First reason is to be compatible with other color pickers like gcolor2. I would like to enter the same HSV value and arrive at exactly the same RGB/whatever value, leaving the rounding errors outside the discussion. When rounding errors occur, please let them be the same error which other tools like gcolor2 make too.

Second reason is that I would like to request that two buttons be added in the color wheel called
  Hue +60°
and
  Hue -60°
These buttons allow users to quickly change the /temperature/ of a color.

When possible, these buttons could also be made available in the HSV tab. There the degrees can be added or subtracted directly to Hue. For HSL tab, it would be a stepsize of 16.66667 which could cause undesired extra rounding errors. I don't know what the internal representation of color is, so I leave that up to you.

Implementing the above would offer a HSV tab with 0-360 and improve compatibility with other applications (even if it is wrong, it is wrong in the exactly same way). Implementing Hue +60° and Hue -60° buttons for color wheel tab, HSV tab and HSL tab would offer users to quickly find colors in another /temperature/ but in the same /family/.

[Pander (pander)]

Small correction on previous comment, 16.66667 should be 42.5

[Alex Goncharenko (zigmarion)]

It's version 0.92 already, and nothing has been fixed yet. Has this bug been abandoned completely? For me, as a web developer, this renders whole coloring process unusable in Inkscape.
I would love to see some kind of response on this.

[Nathan Lee (nathan.lee)]

Closing because this is fixed in 1.0alpha (i.e. sliders now read 360, 100, 100). It was fixed in the MR https://gitlab.com/inkscape/inkscape/merge_requests/58 (bdea0d0b, 9effcd14, 5e59eeaf).

Can't speak to the internal representations.

Closed by: https://gitlab.com/nathanal