Well, you could say I’ve been busy. I’ve had a couple of days off this week, and instead of relaxing like normal people, I wanted to fix ICC profiles on GNOME.
First the hard bit. You have to go to your screen vendors website, and download the “drivers” for your monitor. They’ll likely come in a zip file with other junk like .inf, .cat and other windows driver stuff. Somewhere in there should be a .icm or .icc file which contains the data you need specific for your monitor.
Then go to System->Prefrerences->Color Profiles and select the correct file for your monitor. There are also some other test files you can play with.
Then you can set any gamma or contrast or brightness settings if you wish. The gamma defaults to 2.2 just like newer Apple systems and Windows XP, but if you don’t like this you can set it back to 1.0.
You’ll need shared-mime-info from git master (for the double click to work) and gnome-color-manager from gnome git.
There’s still lots of work to do, such as:
New project icon
Help and man documentation
A website of some description
A mailing list
The calibration button to be wired up with hardware devices
I’ve ordered myself a Pantone Huey hardware calibration device, and soon hope to have this wired up to gnome-color-manager to make accuratly calibrating a device as easy as a single click.
Now, I’m all out of time for this little bit of fun, as I have to return back to fixing PackageKit and DeviceKit-power for the impending F12 release, but if anyone wants to help me with this I would be very grateful.
I’ve got a multi-monitor setup here, with my T61 being my primary display, and a 28″ LG flatpanel as my secondary display.
I also take a lot of photos, and do editing in GIMP and Rawstudio and have noticed the colours on the LG are very different to the colours on the T61 screen. And when I print them, they bear little resemblance to what I just saw on screen. I’m almost thinking of buying a macbook and OSX just so I can actually see the colours I’m about to print. Heck, even Windows XP does things better than Linux does now.
I’ve done quite a bit of research, and found the general state of colour profiling to be, well, pretty hardcore, and in GNOME practically unusable. I can set my xgamma table using xcalib or dispwin, but this isn’t aware of xrandr setups and only applies the profile to a single screen. It’s certainly not a persistent setting or easy to figure out as it’s not installed by default.
In an ideal world I would visit System->Preferences->Color calibration (which is installed by default) and then either import the .icm file I’ve downloaded from the manufacturers website, or click a button and calibrate my display using an external calibration device. Certainly no commands on the root prompt, or typing in a bunch of hex.
So what am I thinking:
A gnome-settings-daemon plugin that applies ICC profile when a monitor is attached (or just integrate with existing xrandr plugin)
A gnome-color-calibration configuration UI that lists the attached output devices and allows you to associate profiles with them
Available colour profiles installed system-wide and also in the users home directory
One click calibration using supported devices (for instance ColorVision Spyder2)
Now, this colour problem is very complicated. There’s lots of work in applications to support other colourspaces and profiles and lots of very clever colour libraries (e.g. ArgyllCMS or lcms) but not a lot of work is being done to actually make this usable on the desktop.
Now, I’m very short on time these days, but would be very willing to co-maintain a project (or join an existing one) if other people are interested in this. I’ve got more than enough work to do with PackageKit, DeviceKit-power, and gnome-power-manager but I can spare a few hours a week to this as I think it’s a very important problem to solve. If it’s annoying me with my photography hobby, then it’s got to be a really big deal for professionals trying to use Linux. So, anyone interested?
There’s been a lot of noise about PackageKit and debconf in the past, but not an awful lot of coding… Until now.
Daniel Nicoletti is the maintainer of KPackageKit, and a log time contributor to PackageKit. He’s also the guy behind all the recent SimulateX() methods that required quite a bit of clever coding to work properly on all backends. The simulate methods alone make PackageKit much more useful with apt (where updating a package can remove another) and now he’s dealing with the debconf problem.
I’ll not repeat what he’s planning to do as all the details are available on his blog, but it basically involves adding a DBus frontend on debconf and telling packagekitd a private connection of a helper program running in the session. This means debconf can work in the standard PackageKit “no blocking” modes when required (e.g. for an unattended update) but also ask required questions when setting things up like MySql when running interactively.
I’ve still not changed my stance on asking questions and blocking during a package install, but with this new helper program and secondary session interface, a lot of the debconf headaches can go away. I’m sure all the changes might take a few weeks to even be prototyped, but it’s nice things are going in the right direction.
A few people commented on my blog after my last post, and asked me if I actually liked GNOME Shell. My last post wasn’t meant to be stinging criticism, more pointing out things that need to be addressed before we can call this the shell of GNOME 3.0. I’ve filed lots of bugzillas (some already fixed!) and I’m pleased to say that most of the issues I’ve brought up the developers seem keen on addressing. Owen has been working hard on the theming code, so hopefully I can get a less white-on-black theme for my little old eyes. Dan has been working on multi-monitor support, and it’s much better already. I do heartily recommend installing mutter and gnome-shell from gnome git, rather than using the distro built packages, as it’s all being implemented / fixed so quickly.
I do think I’ll be sticking with GNOME Shell, as it really is some cool stuff.
Bad Behavior has blocked 2769 access attempts in the last 7 days.