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.
Looks nice… will we see RPMs of this for F12 at some point?
Yup, hope so.
I’m not sure that it makes sense to have fine tuning of gamma, constrast & brightness after providing a ICC profile. When I created an ICC profile with argyllcms, those were things you had to tune before the profile was created and IIUC the resulting profile is only accurate when used with those same settings.
Sure, but when we’re using a vendor supplied ICC profile sometimes thing need tweaking. I agree the fine settings make no sense with a generated profile.
Should this perhaps be integrated with the Display-capplet instead?
I thought about that, but I really think it’s doing a different job. Also, in time, it will support colour profiles of scanners and printers, which doesn’t really fit with the display-capplet at all.
This looks fantastic – great work!
Seems to work as described, but it had pretty…radical effects on one of my monitors, making it look like an old NES game or something, I could only distinguish about 8 different colors! That was with what’s supposed to be the correct profile from the Windows driver package. Any idea what might be going on there?
Probably a bug in my parser. Due to some horrible patents (which I won’t go into) I rolled by own trivial ICC file parser based from the open specification, leaving out the colorspace stuff. It’s likely one of your monitor profiles is using a encoding scheme that:
1) I misunderstood from the spec
2) I didn’t test with data I had available
3) I didn’t code yet :-)
If you send me the icm file I can see if it’s on of the above. Thanks.
Would it be possible to use ‘lcms’ to parse the ICC profiles ? It is the library that GIMP, DigiKam, InkScape, etc all use for parsing / handling ICC profiles, and already present in all Linux distros.
Yup, version 2.29.2 now uses lcms.
Nice work! :)
But… Does this work as expected? I have only been reading the code, no success in compiling on my old Linux-system.
It looks to me as only gamma curves and/or single channel CLUTs is used – and everything else from the profile is ignored?
Is there a plan to support the _ICC_PROFILE atom? (Will this conflict with uploaded gamma tables?)
I would love to participate in a discussion about this at some point in time, it’s a really needed feature in GNOME.
One could start looking for answers at the CREATE list…
Sure, you’ll need pretty up to date Xorg drivers to use the new per-output-gamma table stuff. And I’ve deliberately only added support for CLUTs, and ignored the colorspace stuff completely (patents, there be dragons). As for _ICC_PROFILE I wanted to interoperate with the other projects, rather than just do a NIH implementation. It’s quite hard to do right, and I don’t think any of the existing projects are quite there yet. It certainly needs a lot more work.
Two questions…
Which part/algorithm is patented? The transformations used when “applying” ICC profiles are pretty basic and almost every color transforming application uses something similar.
What work is needed for using the _ICC_PROFILE atom? – and what is the hard part in doing it right?
You should be using Oyranos for most of the backend functionality. Also KDE playground had an app named Kolor Manager that implements a KDE front end for Oyranos that now does most of what you are proposing (IE. other devices like scanners, cameras, printers and X11 integration). Perhaps you should leverage that work for GNOME.
You know, anyone who cared enough to buy a meter and calibrate their display might be inclined to hit OK if they were presented with a “upload your profile to our database” button…When you find enough profiles that are similar enough…
That would not be trivial. First of, no two models of the same monitor is equal. And the generated profile would depend on the monitor settings. For example some monitors allow for a optional wide gamut colorspace (ie. AdobeRGB) and then you have the whole brightness/contrast/lightness/saturation and whatnot.
That’s what I was going to say – having something akin to what Jockey and OpenPrinting (https://wiki.ubuntu.com/PrinterDriverAutoDownload) does for printer drivers, but for colour profiles, would be really excellent.
Whilst I agree this would be a cool feature, colour profiles depend on the amount and colour of ambient light, the age of the monitor, the settings on the monitor at the time of calibration and that sort of thing. It would be a very complex problem to try and solve.
The problem with that is that monitors’ colour response tends to “drift” over time. This makes vendor supplied profiles not nearly as useful as you might think they are, and user supplied ones would not really be any better. You’d be going from ‘not calibrated’ to ‘wrongly calibrated’, neither of which is going to give you accurate colour – they’d merely be different. There’s no substitute for getting a hardware calibration device, and performing calibration on a monthly basis to deal with the monitors’ changing response over time.
Two words: Thank you!
And 2 more: a lot!!!
Now you need a central database to avoid the downloading/unzipping for non-power-users.
Just considering the boundary cases, are any of the maximum or minimum values enough to make a screen unreadable? If so you might want to ensure people can’t shoot themselves in the foot by either disallowing those values or having a timeout message like “Do you want to preserve this colour setting? If so click within 7 seconds…”
Thanks for all the hard work!
“The gamma defaults to 2.2” I don’t like this everything looks too bright with this changing this as default isn’t a good idea imho.
This looks amazing! Been needed for two long. Great work!
You Rock!
I’m glad to read you decided to buy a Huey, instead of a Spyder… DataColor has reknowned to be hostile to OSS, and their Spyders require non-re-distributable firmware, and some are even reported to have a broken USB implementation, which can break when hubs are between the colorimeter and the system.
I have a Huey too, and it works like a charm… X-Rite’s EyeOne should be great as well, these get rebranded alot like the LaCie BlueEye, Eizo, NEC and HP relabel them as well…
You might want to checkout my blog as well, I’ve written a couple things about color management on Linux as well, including digital camera profiling, I do need to update a couple of posts though.
I’ll be keeping a close eye on your blog.
Your efforts are MUCH appreciated.
Cool. So what about Oyranos? :)
I would vote for a close integration/cooperation with Oyranos, too.
Looks really great, you work at such an amazing pace. I never used to really care about the way colours look different on different monitors until I realised my colour-coded calendar entries looked almost completely different from device to device – this looks to to be the thing to solve it. Thank you.
Nice! I look forward to using it.
Please take a look at dispcalGUI which acts as a front end for ArgyllCMS. I’ve been using both of those with a DTP-94 with very nice results.
drago01: gamma 2.2 is the sRGB standard, what Windows has been using forever, and what Macs now use. If everything looks too bright then either your brightness setting is wrong, your profile is wrong, our you have got used to a badly calibrated display. :)
No, it looks too much like crap that it can’t be right, with 1.0 it just works i.e I plug the display in and it looks sane.
With 2.2 it is awefully bright/colors are way off … so I prefer the “just work” vs “you need to play with the settings to get decent colors” …
Also tested the same display under windows, the colors are the same no wierd “very bright” screen like with gamma 2.2 (and no this is not specific to one display)
What about double calibration? The display profile most probably has gamma 2.2 included already and setting another gamma additionaly is not needed.
If adjustments to vendor’s profile are required, I would expect +/- gamma instead (the same like xgamma utility).
Hi,nice work, congratulations, i installed it, and i v found a icm profile for my monitor but it doesnt work with double click,so what can i do to import my profile?
Muhammad,
Right click on the profile and click “Open with other application”. There should be a list of applications and one of the is “ICC profile installer”. Click that and there should be a pop up asking if you want to install the profile.
– Garrett
Hi,
It’s not thee either, i am sorry to bother you, but is there any solution?
You need to install share-mime-info from git master for the double click to work, you can either use gnome-color-manager 2.29.2 and just drag and drop the icc profile, or you can use 2.29.1 and just click import.