http://bugzilla.opensuse.org/show_bug.cgi?id=911589 Bug ID: 911589 Summary: argyllcms-1.6.3: calibration is way too slow to be usable Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: All OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: GNOME Assignee: bnc-team-gnome@forge.provo.novell.com Reporter: Ulrich.Windl@rz.uni-regensburg.de QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- I have a Datacolor Spyder 3 USB color sensor suitable for monitor color calibration. When trying to calibrate my LCD monitor from the GNOME's "color" control center, it suggests that an average calibration takes 30 minutes, so I tried a low-quality calibration that takes 15 minutes... Before I continue, let me remark that I also use Datacolor's calibration software that runs under Windows, and that software needs less that 15 minutes for a full recalibration. What it does it a brightness and whitepoint calibration first, then calibration read, green, and blue (ramp from black to full power), then a gray ramp. Finally it applies calibration and re-checks the result for plausibility. Back to openSUSE, I found that the low quality calibration starts playing with the white-point (it seems) and the prgress bar advances for a few pixels, then no visible change could be found (neither color, nor progress bar) for minutes. That's where I cancelled the process! Considering that you should re-calibrate your monitor whenever the lighting conditions change, or after every few weeks, the amount of time needed for calibration is unacceptable (especially when considering the fact that in MS-Windows you can do the same thing much quicker). The obvious deficits are: 1) The calibration takes too long. I can only suspect that the software tries to average the measurement from the sensor over a very long interval; if a sensor is so noisy that it seeds much more than 10 seconds per measurement, it's better no to support such a sensor rather than having to let users wait for minutes for some progress. 2) There is no user-visible feedback during calibration. There could be some timer counting down, or a textual description of what is going on. (I would have liked to report the problem upstream, but they lack a reasonable bug tracker) Inspecting syslog, the application or parts of it may have crashed silently, because I found: org.freedesktop.ColorHelper[2046]: steps were set as [ 3, 97, -1 ] but should have been: [ 5, 95, -1 ] at cd-main.c:475 org.freedesktop.ColorHelper[2046]: *** Error in `/usr/lib/colord-session': double free or corruption (out): 0x00007fbbd0dfc420 *** org.freedesktop.ColorHelper[2046]: ======= Backtrace: ========= org.freedesktop.ColorHelper[2046]: /lib64/libc.so.6(+0x730bf)[0x7fbbcdbf80bf] org.freedesktop.ColorHelper[2046]: /lib64/libc.so.6(+0x7892e)[0x7fbbcdbfd92e] org.freedesktop.ColorHelper[2046]: /lib64/libc.so.6(+0x79636)[0x7fbbcdbfe636] org.freedesktop.ColorHelper[2046]: /usr/lib64/libglib-2.0.so.0(g_string_free+0x3a)[0x7fbbce4b5cea] org.freedesktop.ColorHelper[2046]: /usr/lib/colord-session(cd_state_done_real+0x309)[0x7fbbcf5f3859] org.freedesktop.ColorHelper[2046]: /usr/lib/colord-session(+0x7918)[0x7fbbcf5f4918] org.freedesktop.ColorHelper[2046]: /usr/lib/colord-session(+0x82e6)[0x7fbbcf5f52e6] org.freedesktop.ColorHelper[2046]: /usr/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x135)[0x7fbbce4968e5] org.freedesktop.ColorHelper[2046]: /usr/lib64/libglib-2.0.so.0(+0x4bc48)[0x7fbbce496c48] org.freedesktop.ColorHelper[2046]: /usr/lib64/libglib-2.0.so.0(g_main_loop_run+0x6a)[0x7fbbce496f0a] org.freedesktop.ColorHelper[2046]: /usr/lib/colord-session(main+0x23e)[0x7fbbcf5f23de] org.freedesktop.ColorHelper[2046]: /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fbbcdba6b05] org.freedesktop.ColorHelper[2046]: /usr/lib/colord-session(+0x559f)[0x7fbbcf5f259f] -- You are receiving this mail because: You are on the CC list for the bug.