I don’t know how many of you are reading Planet GNOME, but I bet not too many. 😛 That’s why I’d like to draw your attention to this blogpost by Richard Hughes.
Color management is present in all modern operating systems, including Microsoft Windows and Apple OS-X, as well as GNOME has support for it since 3.0 (AFAIK).
Having color management on machines used for creative tasks (like painting/photography, etc.), is very important, because the human eye can only capture a certain range of colours as well as digital devices can only produce/display a specific range of colours. So you have different colour-spaces between devices, your printer, your screen, your camera:
When the graphics are processed by devices using different colour-spaces, you get results like this:
To keep the “genuine” colours of graphics while processing it, ICC profiles are used to translate between different colour-spaces. ICC is an ISO standard and used in many (all?) operating systems. It is supported by most image-processing devices.
colord now is (as you might guess from the name) a D-Bus activated system daemon to manage, install and generate color profiles to accurately colour manage input and output devices. colord is a Freedesktop.org project and therefore not tied to GNOME or any other desktop. But at the moment, only GNOME provides support for colord in it’s settings panel, so integration in KDE is wanted :). Richard Hughes, the author of colord, offers is help when someone wants to write a KCM for colord, which would be great to get full colour-management support on KDE too. Working with Richard is great, I am working with him on the PackageKit project, which really is a pleasure. 🙂 You just need to make very clear, why a certain bigger change is required and what the benefits are. (but that’s a good aspect for project maintainers, IMHO)
Unfortunately I am very busy with Listaller, PackageKit/Apper/Debian-DEP-11 and university stuff at the moment, so I can’t do much for this task. But of course I’d be willing to help a little, if I can, if someone would like to take this task. 🙂
P.S: If you find it weird that I first write about making System Settings easy to use and then ask for another KCM: The System Settings project hasn’t finished with the last blogpost, I’m already planning some stuff based on the comments on the last post. 🙂 I’ll write about it soon. (But as always, the critical factor is time…)
EDIT240212/12:24: Do be fair, I want to mention that there already is a “color-management” module, called Oryanos. At time, it looks like nobody makes use of it, although it has already been around for years. colord, in contrast, is already used by a wide variety of other tools and libraries, for example CUPS and GTK+. To be honest, I cannot really judge which technology is better, but I can see that the adoption of colord is far greater, while colord is the younger project. This means that colord seems to provide the necessary components, is functional & stable.
There is a FAQ-Document available, describing why colord was created instead of fixing Oryanos, it’s very interesting to read and describes nicely why colord is preferred.
This post was planned to be just a hint for interested people to see that the colord project is looking for KDE developers (there are already a few who are interested), but it looks like I ran directly into the colord vs. Oryanos crossfire. 😛
.. and oyranos?
while integration with colord would be nice to improve integration for OSes that base on that (read: Red Hat), we should perhaps recognize the efforts that have already gone into successfully integrating oyranos with KDE which is actually prefered by such groups as the Libre Graphics community.
this approach which ends up sounding very much like “but it’s a STANDARD, don’t you GET IT?” as a justification ends up muddying the waters and risks creating / reinforcing divisions that shouldn’t exist.
or put another way .. has colord implemented support for OpenICC? if not .. why? to be taken seriously as a cooperative effort, colord development needs to demonstrate it has cooperation in its DNA as well.
Hmm… I already talked about that with Richard, but as I am no Color-Management expert, I can’t judge the technical details. I just see that colord is already used by many applications, I know that Richard has the experience and knowledge about color-management and I know that he usually is very open to discussions.
BUT, and this is clear, an explanation which is understandable for everyone about why colord should be preferred over Oryanos is definitely required!
As far as I know, Oryanos is not integrated into KDE very much… AFAIK it uses Compiz instead of KWin and Elektra instead of D-Bus… Also, it is not available on any distribution yet. (Which is strange, if it is a working, usable tool)
I’ll ask to clearify the Oryanos vs. colord issue and then reply here or even update the article above with the information I got.
“has colord implemented support for OpenICC”
…err, openicc isn’t a standards body. Kai-Uwe has come up with lots and lots of specifications, and I’m certainly implementing the ones that make sense but not the insane ones. I certainly don’t want to replace a sqlite database with a json file dump for example.
This isn’t also a Red Hat project. I agree I work for Red Hat, but I’m working with people from Suse and Ubuntu just as much, if not more.
I’m also going to be fairly blunt about not interoperating with oyranos. I don’t think Oyranos has the market share or the user base to make it worthwhile on my part. Before you compare the projects, please download them and build them, then try to use them. Then you might see why I did something different with colord.
neither userbase nor market share tell *anything* about a projects quality or ability. naturally i’d want to have a rather powerfull framework — which you can make as “Just Works” as you want in that you wrap the functionallity –, instead of being limited by the “Just Works” philosophy in case i need some more options.
have to agree with Aaron Seigo here. colord seems to be another dumbed down GNOME “technology” which is pushed down the throat, where oyranos seems to be the better choice.
Yeah, I thought this was implemented here: http://www.oyranos.org/2011/11/colour-management-in-opensuse-12-1/
Here is the git: http://quickgit.kde.org/index.php?p=kolor-manager.git&a=summary
Colord is already in the wild, it would be great to have it in kde, once other technologies are available, the user can choose.right now it appears that neither technology is available for the kde desktop, or am I missing something? Thank you Richard for bringing it up and your offer, I’m certain a lot of I kde artists appreciate that very much. unfortunately a can draw, not code 😉
I think we need two things, first have colord available on KDE, why? because there are a bunch of GNOME tools (like GIMP) that use it. No matter if you want a tool that promises being powerful if it does the job eating your CPU .
I know Oyranos is around about 3 years, and still I don’t have packages for it (in Ubuntu), nor it is properly integrated into KDE, yes, they claim to be KDE integrated, but instead of using QtDBus it uses elektra, instead of KWin it uses Compiz! So just because it might use Qt inside and have a few KCM doesn’t really means it is integrated.
colord is a viable solution that will work right out of the box and well let apps be free to use what CMM they want to.
> I know Oyranos is around about 3 years, and still I don’t have packages for it (in Ubuntu),
Note colord is a mandatory dependency for gnome-settings-daemon >= 3.2, a pretty central component of GNOME, so distros that want to ship GNOME 3.2 must package colord too.
> instead of using QtDBus it uses elektra, instead of KWin it uses Compiz
You’re comparing apple with monkeys here:
– QtDBus is an inter-process system, while elektra is a library for handling configuration (ssomebody in the past wanted to do a KConfig backend using elektra)
– Oyranos doesn’t “use” compiz, it just provides an (optional) compiz plugin for handling color stuff or similar
>You’re comparing apple with monkeys here:
>- QtDBus is an inter-process system, while elektra is a library for handling configuration (ssomebody in the past wanted to do a KConfig backend using elektra)
ok my mistake, as richard stated they have creted theit own signaling system I understood it was elektra, but as you can see in the FAQ it seems dead.
>- Oyranos doesn’t “use” compiz, it just provides an (optional) compiz plugin for handling color stuff or similar
Right, I didn’t mean it use, but more like it integrated with compiz first instead of KWin even tho saying it’s a KDE project.
And what about fltk? Qt is already cross platform, why using another toolkit then? Really Apple is closing it’s doors on non-Apple Store things, they pretty much hate GPL things, I don’t need to mention how M$ like this too, so why worry at other platforms if they already have a solution, they are closing doors and we (Linux) don’t have it. Better to have a simple tool than a super thing that never gets ready.
if i got the “feature” list on the oyranos site correct, kai-uwe provides both fltk and Qt base configuration UIs; while the lib remains Toolkit agnostic.
@dantti The Compiz plugin started in 2008. At that time Compiz was still in it’s glory and OpenICC wanted to provide something useable by all DE’s.
I wasn’t aware that CMM had arrived to the linux desktop – that s awesome! Even if Oyranos would be better and has all the bells and whistles, it’s not there yet.
I’d love to have any CMM be it done right, ugly hacked or anything, available and working would do for now!
Hi,
Why did not you mention Oyranos in your post? It makes me sad when somebody deliberately does not give options to the users. The readers of planetkde has the right to know that there is another alternative pushed by other KDE dudes. You should have explained why you prefer colord over Oyranos, just because you a friend of Richard’s does not mean you should ommit information about colord’s competition.
If it was not because of the kde-core-devel thread I would thought colord is the only standard for color management available for Linux.
Why mention something that isn’t read? I run the last Kubuntu version and do not have packages for it, otoh colord is already there, just because one claims to be a KDE dude doesn’t mean he is, look at his integration (Compiz + elektra), really? The users will have a choice once one is available, this post isn’t about which tech is BETTER, is about adding a missing feature (yes missing since CUPS and a bunch of other software already use it…)
so just be quiet because there are no packages available for your distribution? nahh!
this aside, i’d hate to have to depend on Compiz, so this is a dealbreaker for me. the elektra dep is somewhat understandable as oyranos — as well as kde — isn’t supposed to be limited to linux. keep this in mind!
furthermore, i’d rather wait for a decent framework — and judging by the graphics dude, who prefer oyranos, it indeed seems to be the better choice — than have a half arsed solution poluting my system and run under root privileges.
Hi!
You might want to read this FAQ-Document on Oryanos: http://www.freedesktop.org/software/colord/faq.html#oyranos
And this one on colord running as root: http://www.freedesktop.org/software/colord/faq.html#why-root
🙂
Let’s be honest here: I can’t say of colord is better than oyranos but it IS clear that colord is simply pushed down the throat of GNOME users as Huges has an easy time pushing it due to being a RH employee. That doesn’t make it better – nor worse. I do know the artists prefer Oyranos so I tend to assume colord is the inferior piece of tech. I have no idea why the two guys don’t seem to collaborate as both claim to want to and say the other doesn’t…
See http://lwn.net/Articles/483366/
Colord works. I can install a Gnome distro et BOOM! Color management for my screen/printer/most of my software . I should feel violated that someone did this work and “shove it down my throat” (IE offering me a good piece of software that I use every day for the last year)? It work great, by default, with extreme simplicity. Where is KDE now? Unusable.
If GNOME choose colord (and nothing else), it’s “shoved down the throat of the users”
If KDE choose Oyranos (and nothing else), it’s great, it’s “choice”, and GNOME should adopt it or die.
Great.
there is a simple word for all this KINDERGARDEN.
first to all the idiots, who crying that Oyranos isnt packaged for all distributions. Since when is it a task for an upstream project to do that?
The problem here isnt what is better colord or Oyranos. As Aaron said there are other problems. As Kai-Uwe begun to work on color managment on free desktops there was nothing, so he putted a lot of effort in the foundations like OpenICC and other stuff. So he prepared the road on that rides colord now.
I remember a little FeSCo debate about Copyright violations on some ICC profiles colord used, you can guess from whom that profiles came.
It are thing like this: http://lists.kde.org/?l=kde-core-devel&m=132991162010595&w=2 Defintly wrong answer, I also read always “competing”, sure its true both systems have different architectures, philosophies or whatever but on the end they have the same goal – BRING COLOR MANAGMENT TO THE FREE DESKTOPS.
So there are definitly some point both have to work together and there is the problem. Hughsie and Kai-Uwe cant act together anymore, that makes me sick.
@Ximion Some comments from Oyranos to the points on the cited FAQ:
The CompICC plugin for Compiz is optional as was mentioned already. Oyranos does not depend on Compiz as was falsely stated. Keep in mind the CompICC plugin is still currently the only ICC colour correction mechanism for a full colour corrected desktop at the moment. Work on CompICC started as Compiz was well integrated into distros ad few other OpenGL compositors where available. Mutter and KWin have unfortunately no ICC support inside. But I discussed with many people how to simplify the implementation in order to ease implementation and make that concept more widely deployed:
http://www.oyranos.org/2012/02/x-color-management-0-4-draft1/
Elektra is not dead upstream even though, it is not as vocal as other projects, nor does Oyranos depend entirely on it. It would be easy to replace. I would like to continue to use it as a common configuration DB. But priority has the OpenICC JSON format, which was specified to be used by various CMS’es. At the moment Elektra-0.7 is maintained inline until 0.8 will be released or we switch directly to the mentioned OpenICC JSON format other projects are interested in too.
Oyranos does not expect applications to to use the CPU for colour correction. CompICC is a example of real time colour correction on the GPU.
Oyranos is far less monolithic than expressed in this FAQ. For instance it does not require patches to Gtk or CUPS in order to work. But that is my personal opinion. There are surely arguments possible to prove the opposite if one likes. You have to find out yourself.
Oyranos does not require FLTK nor Qt nor Gtk. Still there are projects out, which make use of Oyranos and these toolkits at the same time. So, the Oyranos core is toolkit agnostic. As was already mentioned.
Oyranos is packaged in all major distros. Even though the ubuntu packages I have seen are pretty old.
>Elektra is not dead upstream even though, it is not as vocal as other projects
Lets do a test. Is Elektra upstream dead?
* Last upstream commit more than 2 years ago
* Requires in Fedora 14 : 3 [oyranos, cinepaint, icc_examin]
* Requires in Fedora 17 : 2 [oyranos, cinepaint]
* Original maintainer and developer team left 3 years ago
* Last tarball release 3 years ago
I think it’s safe to say that the project is dead. Dead dead dead.
your behaivor is again like a kid kid kid
@oy: Looks like you have some more information about these things… Because I’m unsure about Oryanos-dependencies (building it failed when I tried it some time ago, but I haven’t put much work in it…), I removed this part from the article above, as it might be untrue.
Are you sure about Elektra? Their repo looks like a dead project and Ohloh stats indicate the same, so it looks dead to me…
If you’ve clearifications, please tell me. (Maybe I can make this article a little bit more neutral, but I doubt this is possible ^^)
@Ximian Do not wonder. I am the Oyranos maintainer 😉
http://www.oyranos.org/wiki/index.php?title=Oyranos/git links to scripts and a README to build Oyranos from git. That might be helpful.
The core of the Oyranos configuration DB story remains the intended switch to the OpenICC JSON format. Elektra is a internal detail as it is shipped with the Oyranos tar ball and is well integrated. If people have problems with building the Oyranos tar ball, please let us know, as we feel responsible to fix that.
The Elektra argument is unfortunately misused as a stick against Oyranos from people, which appear to have no interest in Elektra and even claim to be competitors to Oyranos. It is on one level with arguments like, Gnome is behind the moon because it uses glib or Qt is unusable because it uses C++. I can not take any of these arguments as serious.
Some more statements regarding Oyranos can be found here:
http://www.oyranos.org/2012/03/kde-end-to-end-colour-management/
Hi all,
Personally, I’m very much in the camp of… I just want to have colour management working under KDE.
Choice is good. Arguing about the choice when neither of them work easily, let alone seamlessly under KDE is a little counterproductive.
Please, feel free to work on your own solutions. Also, feel free to collaborate if you wish.
Please, please, please… For the sake of those of us who can’t code, and just want a working solution – please keep working until we have at least one of them working for us.
It’s easy for me to say when I can’t code – but a little less arguing and a little more coding would advance the situation much more quickly.
Apologies for the tone – I’m just a dedicated KDE fan who’s still waiting for full colour management. And I really don’t want to wait for another few years to see it materialise.
Willing to help in any small non-coding way I can… let’s just keep moving forward.
Thanks.
Mark.
Hello! I could have sworn I’ve been to your blog before but after looking at many of the posts I realized it’s new to me. Regardless, I’m definitely delighted I discovered it and I’ll be bookmarking it and checking back often!
Thanks for finally writing about > Ximion’s Blog
I have noticed you don’t monetize your website, don’t waste your traffic, you can earn extra cash every month because you’ve got hi quality content.
If you want to know how to make extra money, search for:
best adsense alternative Dracko’s tricks