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: