GNOME Bugzilla – Bug 699250
Color calibration never starts
Last modified: 2021-06-09 16:13:20 UTC
The calibration process using my Huey device does not start. The wizard dialog finishes just fine and the Huey graphic is shown, telling me to attach the device to the screen and press start. After doing this, the white area gets a bit bigger but nothing more changes after that, so I have to cancel the process. Tested version: control-center-3.8.1-2.fc19.x86_64
If you leave the calibration for 10 minutes, does the blue bar advance at all?
(In reply to comment #1) > If you leave the calibration for 10 minutes, does the blue bar advance at all? I tested again and let it run a bit longer. Now, at some point, it changed to "Calibration failed! The target whitepoint was not obtainable." There was no blue bar at any point of the process.
Hmm. I've changed the sample delay from 200ms to 400ms as on some hardware 200ms is not enough time for the color to stabilize on the screen. Could you try with colord git, or with these packages please (just colord): http://people.freedesktop.org/~hughsient/fedora/19/x86_64/ Thanks, Richard.
Also, on the old version, this would be useful: Run (as your normal user): /usr/libexec/colord-session -v then, try to calibrate just once. The output from colord-session would be very useful. Thanks!
$ /usr/libexec/colord-session -v 17:28:23 Verbose debugging enabled (on console 1) 17:28:23 CdMain: acquired name: org.freedesktop.ColorHelper 17:29:51 CdMain: :1.162:Start(xrandr-AU Optronics,huey-01) 17:29:51 Quality: high 17:29:51 Whitepoint: 6500K 17:29:51 Gamma: 2,40 17:29:51 Title: 33643EG 17:29:51 Device kind: lcd 17:29:53 CdMain: Emitting InteractionRequired(0,attach the sensor to the screen,/usr/share/colord/icons/huey-attach.svg) 17:30:09 CdMain: :1.162:Resume() 17:30:09 CdMain: Emitting UpdateGamma(2 elements) 17:30:09 CdMain: Emitting UpdateSample(1,000000,1,000000,1,000000) 17:30:11 Absolute white: 7,879903 17:30:11 x:0,135776,y:0,022390,Y:7,879903 17:30:11 CdMain: Emitting Finished(6,failed to get native temperature)
After installing colord/colord-libs 0.1.34-0.423.20130430git from the page you linked, my Huey is no longer detected (even after a full reboot). In the settings panel, it says "Unable to detect and device that can be color managed"
(In reply to comment #6) > After installing colord/colord-libs 0.1.34-0.423.20130430git You need to install all the colord* packages, not just the -libs package. I'm trying to work out how you got an XYZ reading of X:11.399987,Y:1.879903,Z:70.681834 from a white patch. Can you grab the output from "spotread -yl" measuring display white please? Thanks.
(In reply to comment #7) > You need to install all the colord* packages, not just the -libs package. As said, I installed the colord and colord-libs packages. Besides those two, I only have colord-gtk installed (no newer version in your directory) > I'm > trying to work out how you got an XYZ reading of > X:11.399987,Y:1.879903,Z:70.681834 from a white patch. Can you grab the output > from "spotread -yl" measuring display white please? Thanks. Not exactly sure what I am doing here :) I ran the command while the device was on a white spot (background of this bugzilla page) and hit space: Result is XYZ: 135.469046 238.910504 297.243798, D50 Lab: 139.073077 -108.410321 -39.252637
(In reply to comment #8) > Result is XYZ: 135.469046 238.910504 297.243798 Okay, that's perfect. Could you try exactly the same thing (i.e. attached to the white on the screen): colormgr get-sensor-reading lcd Thanks.
(In reply to comment #9) > Okay, that's perfect. Could you try exactly the same thing (i.e. attached to > the white on the screen): colormgr get-sensor-reading lcd sure: $ colormgr get-sensor-reading lcd Sensor: Gretag-Macbeth AG - Huey Color XYZ : 127,749267, 231,854579, 254,946173 Color XYZ : 127,752176, 231,824529, 254,913318 Color XYZ : 127,751687, 231,854413, 254,881186 I also redid the spotread -yl and now I get these values: Result is XYZ: 127.349964 231.814837 252.406142, D50 Lab: 137.522393 -113.145274 -25.661369
Small update: with colord-0.1.34-1.fc19.x86_64 I can at least start the calibration process again, but it runs into the same error as originally reported. Did you find out what is wrong? Is my Huey broken?
For me, it starts calibrating and calibrates for appx. 22 minutes, then it fails. Output of /usr/libexec/colord-session -v: http://pastebin.com/pyfpgfgL Using these versions (on Fedora 19, x86_64, ThinkPad T400s): colord.x86_64 1.0.0-1.fc19 argyllcms.x86_64 1.4.0-9.fc19 control-center.x86_64 3.8.2-1.fc19 What's interesting: Calibrating with setting "low quality" (15 minutes) works flawlessly.
Created attachment 245583 [details] Log of /usr/libexec/colord-session -v In order to connect the log directly with this bug report instead of only linking to a foreign website (pastebin dot com).
Using the RPMs provided in comment #3 it's still the same: colord.x86_64 1.1.1-0.466.20130714git.fc19 @/colord-1.1.1-0.466.20130714git.fc19.x86_64 colord-libs.x86_64 1.1.1-0.466.20130714git.fc19 Any progress on this in the meantime?
Still there after the latest update of argyllcms (in fedora repos): argyllcms.x86_64 1.6.0-1.fc19
(In reply to comment #14) > Any progress on this in the meantime? "Gamma correction table was non-monotonic" is the reason for failure, but I can't see why the increased resolution would make this more likely. I really need the debug output from a newer version of colord that actually dumps the table on failure.
For me the resolution does not make a difference but maybe tuxor can attach a newer log
Created attachment 255727 [details] stdout of /usr/libexec/colord-session -v Used versions: argyllcms.x86_64 1.6.0-1.fc19 colord.x86_64 1.0.3-1.fc19 colord-libs.x86_64 1.0.3-1.fc19
Any progress yet?
Created attachment 264007 [details] stdout of /usr/libexec/colord-session -v Used versions: argyllcms.x86_64 1.6.2-1.fc19 colord.x86_64 1.0.5-1.fc19 colord-libs.x86_64 1.0.5-1.fc19 ... and Colorhug Firmware 1.2.0
Sorry, a correction: I used Firmware 1.2.1
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/ Thank you for your understanding and your help.