GNOME Bugzilla – Bug 756019
Color pickers UX inconsistencies
Last modified: 2018-05-24 15:43:21 UTC
Created attachment 312608 [details] Which color picker has problem and why While producing a comprehensive color course, we discovered GIMP's color pickers are way off the conventions for intuitive color picking and the emerging color picker standards. 1. Hue should always be a horizontal axis (except on vertical slider), current: vertical 2. Dark of value axis (when vertical) should always be at the bottom and bright at the top, current: horizontal 3. Slider for saturation should display saturation, current: display value representation of saturation 4. hue wheel should follow clock wise direction, current: counter clockwise direction. note: red to yellow in CW direction. 5. Clear separation between different color space sliders, current: HSV is put next to RGB Attached image has the same info but in visual, easier to understand. Note: We submitted color picker UX inconsistency report to Mypaint project as well.
Where are these "conventions for intuitive color picking" defined and who sets "emerging color picker standards"? This sounds all pretty well thought through, but I wonder why we didn't get any complaint about it in so many years.
The convention is actually based off how we plot graphs and order by lettering. 1. the direction of axis: increase toward right/up/clockwise The convention is also support by color parameter when it is a slider. when vertical: increase always up. when horizontal: increase always right. 2. the order of axes: alphabetical order or which axis has more info. In color picker case, hue always has more info, thus always get X axis. When it comes to saturation and value, saturation always 1st by order. Always HV+S, SV+H, HS+V. 1st axis: horizontal; 2nd axis: vertical; 3rd axis: slider. For HSL, they will follow the HCY lettering. 3. Next hue: to the right/up/clockwise GtkHSV is incorrect (Counter clockwise)... It is intuitive to follow a circle in clockwise direction. (tested on real students) Position of the starting red is relative. The direction of the next hue is more important. Which software following these conventions? 1. Blender. 2. Krita. 3. Windows color picker. 4. Adobe Photoshop. 5. ColorZilla color picker for Firefox and Chrome. As of now, I have reported the color picker problem for 1. Krita (very minor problem as they stick to convention). 2. Blender (fixed many months ago). 3. Mypaint (they are getting rid of GtkHSV in favor of clockwise hue direction on their Square with wheel color picker). When it comes teaching time, these conventions make learning color picker easy. When the axis in the wrong direction (increase toward left or down), students always come back asking why, because they have seen value increment either up/right in math. I hope that clear things up. :)
Yes that makes more sense now :) Will look into it after the weekend.
1. I think we do follow that already, probably because it's obvious 2. I agree with the proposed changes here (HV+S, SV+H, HS+V) The spacing between the RGB and HSV groups is also pretty much a no-brainer. 3. Hue direction on a circle: I am not so sure here. When I look up color circles made by actual artists, or a simple "color circle" google search for images, I get a wild mixture. Do students no come back to you and ask why the angular direction is not anticlockwise in your pickers, as it is in math?
3. Maybe we should look at other open source software. Blender: Clockwise (even on circle pickers) Krita: CW (even on cicle pickers) Mypaint: Going Clockwise after my report (hue on Circle pickers are CW) GColor2: CCW (using GtkHSV) Gpick: CW Clockwise win here. ================== Proprietary software ColorMania: CW Corel Painter: CW Coolurus: CCW PAINTERSWHEEL CS6: CW ColorWheel Plugin for Photoshop CS4/5: CW Kuler: CCW DigitalColor Meter (OSX): CCW PaintTool SAI: CW Clip Studio Paint: CW MediBang Paint Pro: CW FireAlpaca: CW Clockwise also win, but not sure if sample size is big enough. =================== As for students, they do ask when they see CCW hue wheel or circle picker. My answer: those follow traditional hue wheel, where yellow is on top of the wheel and red toward the right. They respond: Why can't all hue wheel turn CW, easy to think. I think they are used to the idea of CW hue wheel.
This fixes the spacing between the HSV and RGB slider groups: commit 1debefb20f13272a02975f9eda7c7e90ed56dccb Author: Michael Natterer <mitch@gimp.org> Date: Tue Oct 6 23:39:49 2015 +0200 Bug 756019 - Color pickers UX inconsistencies Increase spacing between the HSV and RGB slider groups in GimpColorScales. Yes there was spacing before, but hardly visible. libgimpwidgets/gimpcolorscales.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
This switches the axes in the RGB/HSV color selector: commit 494398e3b89fcb6ec24488d337fe2062c1b75a2b Author: Michael Natterer <mitch@gimp.org> Date: Thu Oct 8 23:47:16 2015 +0200 Bug 756019 - Color pickers UX inconsistencies Switch the axes of the GimpColorSelect color area so that on the X axis, we always modify the first of the two channels of RGB or HSV that are edited here, and on the Y axis the second. libgimpwidgets/gimpcolorselect.c | 267 ++++++++++++++++----------------------- 1 file changed, 108 insertions(+), 159 deletions(-)
I think people are just "used" to CW because they have no clue. A circle's zero degrees is to the right, and angles grow CCW. This is implemented like that consistently all across GIMP, not only in the color pickers. We even have API that has "CW" and "CCW" in its name, also consistently. I tend to go with the scientifically correct direction and origin here...
*** Bug 781920 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/769.