Review Request: include KolorManager in kdegraphics
Kai-Uwe Behrmann
https://bugs.kde.org/show_bug.cgi?id=295987
About:
KolorManager is a front end to the Oyranos Colour Management System (CMS).
Why:
Colour Management is a important part of modern desktops. It helps
designers to improve colour usability, artists to predict artwork
appearance on client computers and graphic professionals to work with
reliable colours. Oyranos is carefully designed to meet that demands. The
KolorManager configuration front end is a KDE systemsettings panel for
manual interaction in the otherwise automated process of configuring
devices and providing reasonable defaults. The device configuration inside
Oyranos CMS is a precondition to get DE colour management well working.
Some applications like Krita or Gimp support already common OpenICC
standards like the ICC Profile in X spec and will directly benefit from
KolorManager being inside KDE. Other need further work to integrate
Oyranos and ICC support.
About Oyranos: http://www.oyranos.org/about
Request:
After working on KolorManager and Oyranos in the past months for the last
Oyranos-0.4.0 release, we feel the stack is ready to review for inclusion
into KDE.
KolorManager resides currently in Playground/Graphics:
http://quickgit.kde.org/?p=kolor-manager.git&a=summary
Someone mentioned kdegraphics would be a appropriate target place inside
the KDE hierarchy.
kind regards
Kai-Uwe
--
Kai-Uwe Behrmann
developing for colour management
www.behrmann.name + www.oyranos.org
Daniel Nicoletti
> After working on KolorManager and Oyranos in the past months for the last
> Oyranos-0.4.0 release, we feel the stack is ready to review for inclusion into
> KDE.
> KolorManager resides currently in Playground/Graphics:
> http://quickgit.kde.org/?p=kolor-manager.git&a=summary
Just a quick question, currently we have two CMS stacks, colord and
oyranos, while
I have nothing against having two of them in KDE, I wonder if this would become
a problem for colord-kde [1] to enter in kdegraphics too? In that case
would be better
to both go to kdeextragear or is there some different policy in this case?
I'm actually targeting KDE SC 4.9 as gnome-color-manager is very mature and I am
pretty much just rewriting it with Qt/KDE libs.
1- http://dantti.wordpress.com/2012/03/12/coloring-you-desktop-with-colord-kde/
Best,
Daniel Nicoletti
Boudewijn Rempt
> > Request:
>
> > After working on KolorManager and Oyranos in the past months for the last
> > Oyranos-0.4.0 release, we feel the stack is ready to review for inclusion into
> > KDE.
> > KolorManager resides currently in Playground/Graphics:
> > http://quickgit.kde.org/?p=kolor-manager.git&a=summary
>
> Just a quick question, currently we have two CMS stacks, colord and
> oyranos, while
> I have nothing against having two of them in KDE, I wonder if this would become
> a problem for colord-kde [1] to enter in kdegraphics too?
There should be only one.
> In that case
> would be better
> to both go to kdeextragear or is there some different policy in this case?
No. There should be color management by default in KDE, that's really important; and there should be only one solution by default. We shouldn't let distributions, or even worse, users decide which solution they use. That way madness lies. KDE's Color management solution shouldn't be in extragear.
As to which one is selected, there are a couple of ways to decide.
The first is, first come, first go. Kolormanager has been in development for quite some time now, and colord is an upstart, gnome-derived technology. Integration of colord in kde was only started very recently. Everyone is free to start a competing project, even inside KDE, but to make that project block a pre-existing project isn't the way to go.
The second way to decide would be on technical merits. I'm not going to go into that discussion; I've seen too many tiresome discussions already, and I don't feel really competent anyway.
For me as an application developer, life sucks anyway, since I have to support Linux, Windows and OSX, so for the time being, the application will offer its own way to select profiles, in addition to using the X11 display atom that both colord and kolormanager support. (And I don't want to think about printing anyway.)
> I'm actually targeting KDE SC 4.9 as gnome-color-manager is very mature and I am
> pretty much just rewriting it with Qt/KDE libs.
>
> 1- http://dantti.wordpress.com/2012/03/12/coloring-you-desktop-with-colord-kde/
>
> Best,
> Daniel Nicoletti
>
--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Kai-Uwe Behrmann
>> Request:
>
>> After working on KolorManager and Oyranos in the past months for the last
>> Oyranos-0.4.0 release, we feel the stack is ready to review for inclusion into
>> KDE.
>> KolorManager resides currently in Playground/Graphics:
>> http://quickgit.kde.org/?p=kolor-manager.git&a=summary
>
> Just a quick question, currently we have two CMS stacks, colord and
> oyranos, while
> a problem for colord-kde [1] to enter in kdegraphics too? In that case
> would be better
> to both go to kdeextragear or is there some different policy in this case?
Would it work out to link kdegraphics components to kdeextragear?
> I'm actually targeting KDE SC 4.9 as gnome-color-manager is very mature and I am
> pretty much just rewriting it with Qt/KDE libs.
OpenICC colour experts have then a different view of maturity.
> 1-ï¿œhttp://dantti.wordpress.com/2012/03/12/coloring-you-desktop-with-colord-kde/
That including your later blog post shows a sub feature set of what is
implemented in KolorManager / Oyranos.
> Best,
> Daniel Nicoletti
kind regards
Kai-Uwe
Daniel Nicoletti
> important; and there should be only one solution by default. We shouldn't
> let distributions, or even worse, users decide which solution they use. That way
> madness lies. KDE's Color management solution shouldn't be in extragear.
>
> As to which one is selected, there are a couple of ways to decide.
>
> The first is, first come, first go. Kolormanager has been in development for
> quite some time now, and colord is an upstart, gnome-derived technology.
> Integration of colord in kde was only started very recently. Everyone is free to
> start a competing project, even inside KDE, but to make that project block a
> pre-existing project isn't the way to go.
I'm not talking about blocking pre-existing projects, I'm really looking forward a
solution where the two could live. Sure we don't want users/distributions to
decide but they do.
> The second way to decide would be on technical merits. I'm not going to go
> into that discussion; I've seen too many tiresome discussions already, and I
> don't feel really competent anyway.
>
> For me as an application developer, life sucks anyway, since I have to support
> Linux, Windows and OSX, so for the time being, the application will offer its
> own way to select profiles, in addition to using the X11 display atom that both
> colord and kolormanager support. (And I don't want to think about printing
> anyway.)
Well if we go into the merits discussion I really think we will get nowhere,
as we didn't sort this first we won't sort this out now, KDE and GNOME primary
goals is Linux, so I really don't think supporting platforms where they already
have good solutions for this is a way to go.
So how do we go into the merit discussion without creating yet another flame war?
Daniel Nicoletti
>> pretty much just rewriting it with Qt/KDE libs.
>
> OpenICC colour experts have then a different view of maturity.
>
>>
>
> That including your later blog post shows a sub feature set of what is
> implemented in KolorManager / Oyranos.
It's totally clear from my message that this is a work in progress thing, if you
want to demerit my work by saying yours is better this shouldn't be the kind
of thing to discuss in kde-core-devel. Please let's try to not offend
each others work.
About your opinion on maturity I'm talking as a developer which sees colord
as technology and still I'm really not comparing that to yours.
Best
Boudewijn Rempt
>
> > important; and there should be only one solution by default. We shouldn't
> > let distributions, or even worse, users decide which solution they use. That way
> > madness lies. KDE's Color management solution shouldn't be in extragear.
> >
> > As to which one is selected, there are a couple of ways to decide.
> >
> > The first is, first come, first go. Kolormanager has been in development for
> > quite some time now, and colord is an upstart, gnome-derived technology.
> > Integration of colord in kde was only started very recently. Everyone is free to
> > start a competing project, even inside KDE, but to make that project block a
> > pre-existing project isn't the way to go.
> I'm not talking about blocking pre-existing projects, I'm really looking forward a
> solution where the two could live.
Well, I am really not looking forward to that situation. Sometimes having a choice is a bad thing. Sometimes starting a new project instead of helping out an existing project is not the right thing to do.
> Sure we don't want users/distributions to
> decide but they do.
>
> > The second way to decide would be on technical merits. I'm not going to go
> > into that discussion; I've seen too many tiresome discussions already, and I
> > don't feel really competent anyway.
> >
> > For me as an application developer, life sucks anyway, since I have to support
> > Linux, Windows and OSX, so for the time being, the application will offer its
> > own way to select profiles, in addition to using the X11 display atom that both
> > colord and kolormanager support. (And I don't want to think about printing
> > anyway.)
> Well if we go into the merits discussion I really think we will get nowhere,
> as we didn't sort this first we won't sort this out now, KDE and GNOME primary
> goals is Linux, so I really don't think supporting platforms where they already
> have good solutions for this is a way to go.
No, Gnome's primary goal is Gnome, while KDE offers a framework for building applications on many platforms next as well as desktop environment. My own desktop environment is KDE's plasma, but my goal for Krita is to have it run everywhere, not just on the plasma desktop.
In fact, until Gnome 3 and Unity drove them away, most of my users were on Gnome... And that was fine, because colord and oyranos both set the relevant X11 atom, so Krita is fine, as long as I explicitly don't care about scanners and printing.
> So how do we go into the merit discussion without creating yet another flame war?
I don't know. I don't know of a extensive comparison between colord and oyranos. And I'm not sure it's possible anymore to find anyone who can do that competently, honestly and impartially.
Realistically speaking, we'll have colord on Linux as the "standard" whether we want it or not, because it's in Fedora, and whatever Redhat puts in Fedora will be the "standard" for Linux. Of course other distributions will package it, because they will want to package gnome. Even if we had been faster to the finish line and had had kolor-manager ready for KDE 4.6 or 4.7, no way colord would not have replaced our own work.
Apart from all technical merits.
Kai-Uwe Behrmann
>>> � I'm actually targeting KDE SC 4.9 as gnome-color-manager is very mature�and I am
>>> � pretty much just rewriting it with Qt/KDE libs.
>> �
>> OpenICC colour experts have then a different view of maturity.
>> �
>>> �
>> 1-�http://dantti.wordpress.com/2012/03/12/coloring-you-desktop-with-colord-kde/
>> �
>> That including your later blog post shows a sub feature set of what is�
>> implemented in KolorManager / Oyranos.
>
> It's totally clear from my message that this is a work in progress thing, if you
> want to demerit my work by saying yours is better this shouldn't be the kind
> of thing to discuss in kde-core-devel. Please let's try to not offend
> each others�work.
I welcome anyone, who works on Linux CM in a open minded way, including
you.
But you used GCM as a reference for your own project and surely know
the controversial issues around colord. My answere was in response to the
later.
> About your opinion on maturity I'm talking as a developer which sees colord
> as technology and still I'm really not comparing that to yours.
As you want to work with that project, how about reading the according
threads on the OpenICC ml [1] ?
> Best
>
kind regards
Kai-Uwe
Lamarque V. Souza
Em Wednesday 14 March 2012, Boudewijn Rempt escreveu:
> On Wednesday 14 March 2012 Mar, Daniel Nicoletti wrote:
> > > No. There should be color management by default in KDE, that's really
> > >
> > > important; and there should be only one solution by default. We
> > > shouldn't let distributions, or even worse, users decide which
> > > solution they use. That way madness lies. KDE's Color management
> > > solution shouldn't be in extragear.
> > >
> > > As to which one is selected, there are a couple of ways to decide.
> > >
> > > The first is, first come, first go. Kolormanager has been in
> > > development for quite some time now, and colord is an upstart,
> > > gnome-derived technology. Integration of colord in kde was only
> > > started very recently. Everyone is free to start a competing project,
> > > even inside KDE, but to make that project block a pre-existing project
> > > isn't the way to go.
> >
> > I'm not talking about blocking pre-existing projects, I'm really looking
> > forward a solution where the two could live.
>
> Well, I am really not looking forward to that situation. Sometimes having a
> choice is a bad thing. Sometimes starting a new project instead of helping
> out an existing project is not the right thing to do.
I agree.
Personally, what I think is really important is a community (not ony one person) commited to maintain the software. We already have problems with KDE software that lost the maintainer or nobody is willing to develop it anymore, those software are fated to disappear when we move to Qt 5.
> Realistically speaking, we'll have colord on Linux as the "standard"
> whether we want it or not, because it's in Fedora, and whatever Redhat
> puts in Fedora will be the "standard" for Linux. Of course other
> distributions will package it, because they will want to package gnome.
> Even if we had been faster to the finish line and had had kolor-manager
> ready for KDE 4.6 or 4.7, no way colord would not have replaced our own
> work.
Yes, I think oyranos needs more support from distributions or at least be easier to install. Of course, by the features oyranos includes there must be scenarios where colord does not help. The fact that colord is going to be the standard also does not mean we should drop oyranos. As long as oyranos team maintain the software and the KDE support in it we are ok.
--
Lamarque V. Souza
KDE's Network Management maintainer
Lamarque V. Souza
Em Wednesday 14 March 2012, Kai-Uwe Behrmann escreveu:
> Am 14.03.12, 06:01 -0700 schrieb Daniel Nicoletti:
> >>> I'm actually targeting KDE SC 4.9 as gnome-color-manager is very
> >>> mature and I am pretty much just rewriting it with Qt/KDE libs.
> >>
> >>
> >> OpenICC colour experts have then a different view of maturity.
> >>
> >>
> >>>
> >>
> >> 1- http://dantti.wordpress.com/2012/03/12/coloring-you-desktop-with-colo
> >> rd-kde/
> >> That including your later blog post shows a sub feature set of what is
> >> implemented in KolorManager / Oyranos.
> >
> > It's totally clear from my message that this is a work in progress thing,
> > if you want to demerit my work by saying yours is better this shouldn't
> > be the kind of thing to discuss in kde-core-devel. Please let's try to
> > not offend each others work.
I do not read a demerit of your work the words above. Unless you are talking about something Kai-Uwe Behrmann wrote outside this mailling list I think we should not be that agressive in a response.
> I welcome anyone, who works on Linux CM in a open minded way, including
> you.
>
> But you used GCM as a reference for your own project and surely know
> the controversial issues around colord. My answere was in response to the
> later.
And you should also help make things calm, ok?
> > About your opinion on maturity I'm talking as a developer which sees
> > colord as technology and still I'm really not comparing that to yours.
That is partially wrong. A KDE developer is already working on the project that your project is meant to replace, you must really talk about why you want that in technical terms. Kai-Uwe is right about your work is controversional by nature and also because you do not even consulted the KDE developer that is already working on color management in KDE. That is at least impolite in my oppinion.
Thomas Zander
> So how do we go into the merit discussion without creating yet
> another flame war?
I'm sorry, but merit has to be the metric, that's the basis of both
open source in general and KDE specifically. I'd like KDE to avoid
sliding towards a social support group ;)
We had a little talk about those two projects recently on k-c-d as
well, where colord was proposed and Kai used that opportunity to plug
his project.
I then went and downloaded both codebases and looked at them.
First thing that I'm worried about is that the whole project is
designed around user roles (called policies). As I have been involved
with KDE usability I have seen discussions and concepts of user roles
a lot. Frankly, they don't work. There is almost no research to
support them, there is plenty of research stating they don't work.
Then there is the technical dependency tree of Oyranos; this shows a
subsection of its deps;
http://pkgs.org/fedora-16/fedora-x86_64/oyranos-libs-0.3.1-1.fc16.x86_64.rpm.html
Thats a lot of dependencies; some of them anything but easy to find packaged.
Compare to http://packages.debian.org/wheezy/colord
All of this could be ignored, as long as there is real cooperation and
willingness to work together; so I looked at how lively the Oyranos
community is.
http://sourceforge.net/mailarchive/forum.php?forum_name=oyranos-devel
I don't know why colord was created instead of working with Kai on
his mostly one-man project, it may have been for very good reasons, it
may have been just not-invented-here. But the end result is that the
new project is quickly replacing the longer existing one both in
developer community and in usage.
And thats a good point; how many people use it in the wild? I find
the debian popularity contest insightful;
http://qa.debian.org/popcon.php?package=colord
If you don't have a good idea what those numbers are, compare to;
http://qa.debian.org/popcon.php?package=k3b or
http://qa.debian.org/popcon.php?package=kdebase-workspace both of
which have a lower install score than colord.
So, last time the colord and oyranos projects where mentioned on
kde-core-devel, this amounts to the data I looked through and got my
impressions on.
I personally came to the conclusion that KDE is probably better off by
focusing on colord, even if there is currently no KDE gui for it.
--
Thomas Zander
Sune Vuorela
>> Request:
>
>> After working on KolorManager and Oyranos in the past months for the last
>> Oyranos-0.4.0 release, we feel the stack is ready to review for inclusion into
>> KDE.
>> KolorManager resides currently in Playground/Graphics:
>> http://quickgit.kde.org/?p=kolor-manager.git&a=summary
>
> Just a quick question, currently we have two CMS stacks, colord and
> oyranos, while
> I have nothing against having two of them in KDE
I would really prefer to at least have one common gui. preferably just
one stack. But if we have to have two competing stacks until one of them
dies, then I guess we will just have to live with it. But do it with a
common gui. pretty please.
> I wonder if this ï¿œwould become
> a problem for colord-kde [1] to enter in kdegraphics too? In that case
> would be better
> to both go to kdeextragear or is there some different policy in this case?
I hope that we aren't going to select a solution based on who is a month
faster than the other.
/Sune
Thomas Zander
>> I'm actually targeting KDE SC 4.9 as gnome-color-manager is very
>> mature and I am
>> pretty much just rewriting it with Qt/KDE libs.
>
> OpenICC colour experts have then a different view of maturity.
Kai,
the two projects clearly have a different set of ideas about what they
should do. Which is fine.
What is not fine is write statements like the one I quoted above, you
imply bad things about Daniel personally (his view of what is mature)
which makes this a personal attack.
In KDE we want to focus on the facts. We talk about merit.
While its fine to give an opinion on a (technical) idea, the above is
not acceptable.
Please respect these values we hold dear here in KDE :)
--
Thomas Zander
Matthias Klumpp
Colord - just to mention that - is also not a GNOME project, it's a
FreeDesktop project. (Doesn't mean it's "standard", but does mean that
it's not GNOME) So everyone is free to contribute to it, and the
maintainer is interested in collaborating with KDE. (which he already
does very nicely)
There's one thing about Oryanos I'd like to mention: I wanted to find
out why Oryanos is not packaged yet on many distributions. Reasons are
the strange build system it uses (looks like a custom thing to me),
which makes it difficult to build it on multiple architectures. It
also has dependencies like Elektra, which looks dead to the public.
(But is still developed, as it's maintainer says) Oryanos requires a
special version of Elektra packaged. There's also some other stuff
going on which needs to be clearified before Oryanos can be shipped in
distributions easily. It also has some legacy stuff, like Compiz
plugins - a KWin plugin would be better for KDE, IMHO ;-)
On the other hand, colord has a clean codebase, less dependencies and
it "just works" for GNOME. Although I don't have experience in color
management, seeing the younger project replacing the older one so fast
shows me that colord at least provides enough and well-working
functionality for color management on Linux.
Therefore, it might be a good thing for KDE to choose it.
(Maybe do some tests with it first)
I also want to point you to this comparison colord against Oryanos:
=> http://www.freedesktop.org/software/colord/faq.html#oyranos
Maybe also interesting, this comment of the Oryanos maintainer
(regarding the FAQ):
=> http://blog.tenstral.net/2012/02/wanted-kde-color-management-kcm.html/comment-page-1#comment-48661
Kind regards,
Matthias Klumpp
2012/3/14 Thomas Zander <zan...@kde.org>:
Kai-Uwe Behrmann
> We had a little talk about those two projects recently on k-c-d as well,
> where colord was proposed and Kai used that opportunity to plug his project.
>
> I then went and downloaded both codebases and looked at them.
>
> First thing that I'm worried about is that the whole project is designed
> around user roles (called policies). As I have been involved with KDE
Policies are grouped preferences for rendering intents and default profile
settings. The advantage is, they can be stored instead of switching each
single option. The policies feature was recommended to implement.
What would you suggest to improve that feature to gain more simplicity?
> usability I have seen discussions and concepts of user roles a lot. Frankly,
> they don't work. There is almost no research to support them, there is plenty
> of research stating they don't work.
The policies in Oyranos are not forced other than normal settings. So each
user is free to choose what she/he likes. There is no artificial
limitation.
> Then there is the technical dependency tree of Oyranos; this shows a
> subsection of its deps;
> http://pkgs.org/fedora-16/fedora-x86_64/oyranos-libs-0.3.1-1.fc16.x86_64.rpm.html
That comes from the device plugins being included inside the Oyranos
source tree. However users can install a minimal Oyranos library and add
X11, CUPS or othe device plugins later. KolorManager panel has no direct
dependency to these device modules. The advantage is that the CMS can care
about even complex device configuration and needs minimal device driver
interaction.
> Thats a lot of dependencies; some of them anything but easy to find
> packaged.
> Compare to http://packages.debian.org/wheezy/colord
I guess components needs device access somewhere in the stack to obtain
informations about the actual device. The advantage is a small core, but
on the other side the components need to do all device interaction themself.
> All of this could be ignored, as long as there is real cooperation and
> willingness to work together; so I looked at how lively the Oyranos community
> is.
> http://sourceforge.net/mailarchive/forum.php?forum_name=oyranos-devel
When talking about cooperation, then it is appropriate to look at the
OpenICC channel. That is the place where colour management project
interaction happens and many Oyranos developers, write there directly to
get opinions from the community and discuss technical ideas.
http://lists.freedesktop.org/mailman/listinfo/openicc
> I don't know why colord was created instead of working with Kai on his
> mostly one-man project, it may have been for very good reasons, it may have
> been just not-invented-here. But the end result is that the new project is
> quickly replacing the longer existing one both in developer community and in
> usage.
It might be that Oyranos core appears slow evolving. But that is as well
due to being involved in following other ICC related projects:
OpenICC default profiles - research, creation, quality control
basICColor default printing profiles - tals with many vendors, licensing
CinePaint - ~second open source ICC graphics editor, 3 year maintainance
ICC Examin - profile viewer
KolorManager - you know
libCmpx - long long discussions for relyable print concept, implementation
CompICC - idea, mentoring, maintainance, many improvements
Taxi - idea, concept, new standards
These projects and some others belong to the Oyranos path of finding out,
what might be useful for good colour management support on Linux. Of
course other projects can continue more easy and faster based on that
previous work and on the experiences made. And surely they do.
> And thats a good point; how many people use it in the wild? I find the
> debian popularity contest insightful;
> http://qa.debian.org/popcon.php?package=colord
It was pointed out that such results are influenced by colord being
mandatory inside Gnome.
How does that relate to (?):
http://qa.debian.org/popcon.php?package=nautilus
> If you don't have a good idea what those numbers are, compare to;
> http://qa.debian.org/popcon.php?package=k3b or
> http://qa.debian.org/popcon.php?package=kdebase-workspace both of which have
> a lower install score than colord.
>
> So, last time the colord and oyranos projects where mentioned on
> kde-core-devel, this amounts to the data I looked through and got my
> impressions on.
> I personally came to the conclusion that KDE is probably better off by
> focusing on colord, even if there is currently no KDE gui for it.
>
> --
> Thomas Zander
kind regards
Kai-Uwe
--
Kai-Uwe Behrmann
http://www.oyranos.org
Boudewijn Rempt
> Hi!
> Colord - just to mention that - is also not a GNOME project, it's a
> FreeDesktop project. (Doesn't mean it's "standard", but does mean that
> it's not GNOME)
Well, no, having something on freedesktop.org doesn't mean it's not a
gnome project; it is a gnome project, and it's widening its scope. The
reason it's used at all is that is is used inside gnome.
> So everyone is free to contribute to it, and the
> maintainer is interested in collaborating with KDE. (which he already
> does very nicely)
>
> There's one thing about Oryanos I'd like to mention: I wanted to find
> out why Oryanos is not packaged yet on many distributions. Reasons are
> the strange build system it uses (looks like a custom thing to me),
> which makes it difficult to build it on multiple architectures. It
> also has dependencies like Elektra, which looks dead to the public.
> (But is still developed, as it's maintainer says) Oryanos requires a
> special version of Elektra packaged. There's also some other stuff
> going on which needs to be clearified before Oryanos can be shipped in
> distributions easily.
It's easy enough to package -- the opensuse packages I use work perfectly
fine, so I cannot imagine that there are any real and relevant problems
for other distributions.
> It also has some legacy stuff, like Compiz
> plugins - a KWin plugin would be better for KDE, IMHO ;-)
So that is irrelevant -- it used to be relevant some years ago, which sort
of shows that oyranos is a project that has been going already for quite
some time and has made several transitions already. Which is a good thing.
>
> On the other hand, colord has a clean codebase, less dependencies and
> it "just works" for GNOME.
And oyranos + kolormanager "just works" for KDE.
> Although I don't have experience in color
> management,
Well, that's the issue really: nearly nobody has a real and thorough
understanding of color management. I've been working with color management
in Krita since 2004, and I still have to admit that I don't have a good
overview of all issues.
> seeing the younger project replacing the older one so fast
> shows me that colord at least provides enough and well-working
> functionality for color management on Linux.
The only reason colord spreads is because it's by default part of gnome3.
That in itself doesn't show anything about its technical merits. And
within gnome, it is actually barely used. In the end, it's the
applications that make the difference.
> Therefore, it might be a good thing for KDE to choose it.
> (Maybe do some tests with it first)
>
> I also want to point you to this comparison colord against Oryanos:
> => http://www.freedesktop.org/software/colord/faq.html#oyranos
Given the extremely tense and nasty discussions we've had, with Alexandre
Prokoudine calling Kai-UWe a liar and so on, I am not sure that relying on
one project's assesment of the other project is a good idea. In fact, I am
sure it is not.
I'm also sure unless people are prepared to spend some time on figuring
out what color management is all about instead of posting lists of
"statistics", the question is not being considered on its technical
merits. pop-contests, lines-of-code, dependencies and so on are all
non-technical when it comes to determining whether the color management
works.
But then, as I've said before, for me, as the author of an application
for which color management is actually essential, both colord and oyranos
work fine.
Boudewijn
Sune Vuorela
> It's easy enough to package -- the opensuse packages I use work perfectly
> fine, so I cannot imagine that there are any real and relevant problems
> for other distributions.
Sure it can be done. but it is just useless churn if it doesn't really
provide anything that matters to the end user that colord doesn't.
I could package oyranos and the weird things it requires. but in the
same time I_could probably fix 20 small annoyances for all users and
package the new nice nepomuk ioslaves. What is the best use of my time?
/Sune
Boudewijn Rempt
> On 2012-03-14, Boudewijn Rempt <bo...@valdyas.org> wrote:
>> It's easy enough to package -- the opensuse packages I use work perfectly
>> fine, so I cannot imagine that there are any real and relevant problems
>> for other distributions.
>
> Sure it can be done. but it is just useless churn if it doesn't really
> provide anything that matters to the end user that colord doesn't.
And, of course, the other way around -- but that's the point isn't it?
Until a library is used, it isn't packaged. And until we actually have
input from people who know what they are talking about, or listen to them,
we cannot decide whether anything "provides anything that matters to the
end user".
I think it's true, though that What _is_ missing is a clear list of what
oyranos provides right now -- apart from making it possible to select the
display profile for X11.
And then, if that list is available, it's of course very much the question
whether enough people can understand it properly.
> I could package oyranos and the weird things it requires.
I wish we could do without being pejorative.
> but in the
> same time I_could probably fix 20 small annoyances for all users and
> package the new nice nepomuk ioslaves. What is the best use of my time?
That depends. If KDE uses kolor-manager, then oyranos needs to be
packaged. Should we let that decision depend on whether it's already
packaged? Sounds like the wrong way around.
Boudewijn
Kai-Uwe Behrmann
> Hi!
> Colord - just to mention that - is also not a GNOME project, it's a
> FreeDesktop project. (Doesn't mean it's "standard", but does mean that
> it's not GNOME) So everyone is free to contribute to it, and the
> maintainer is interested in collaborating with KDE. (which he already
> does very nicely)
>
> There's one thing about Oryanos I'd like to mention: I wanted to find
> out why Oryanos is not packaged yet on many distributions. Reasons are
> the strange build system it uses (looks like a custom thing to me),
That is correct. I would appreciate any help to get that cleared, as some
packagers mentioned it to me. One offerd already a helping hand and
started converting libXcm, which is now autotooled. Oyranos might go
better cmakified.
> which makes it difficult to build it on multiple architectures. It
Which on did not work? The recent released stack compiles on i586,
xf86_64, armv7l, osX and win32, the later being not yet very functional.
> also has dependencies like Elektra, which looks dead to the public.
> (But is still developed, as it's maintainer says) Oryanos requires a
Please Oyranos, like my nick, which is oy ;-)
> special version of Elektra packaged. There's also some other stuff
Where do you get that information from? Oyranos build fine with the
last released Elektra version. For easy of build it is included in the
source tar ball. Sorry for repeating that.
> going on which needs to be clearified before Oryanos can be shipped in
> distributions easily. It also has some legacy stuff, like Compiz
> plugins - a KWin plugin would be better for KDE, IMHO ;-)
That is a different topic. But basically I agree. It is maybe for an other
thread?
> On the other hand, colord has a clean codebase, less dependencies and
> it "just works" for GNOME. Although I don't have experience in color
> management, seeing the younger project replacing the older one so fast
> shows me that colord at least provides enough and well-working
> functionality for color management on Linux.
> Therefore, it might be a good thing for KDE to choose it.
> (Maybe do some tests with it first)
>
> I also want to point you to this comparison colord against Oryanos:
> => http://www.freedesktop.org/software/colord/faq.html#oyranos
Matthias, you help spreading false assertions here.
> Maybe also interesting, this comment of the Oryanos maintainer
> (regarding the FAQ):
> => http://blog.tenstral.net/2012/02/wanted-kde-color-management-kcm.html/comment-page-1#comment-48661
http://www.oyranos.org/2012/03/kde-end-to-end-colour-management/
> Kind regards,
> Matthias Klumpp
kind regards
Kai-Uwe Behrmann
--
Lamarque V. Souza
Em Wednesday 14 March 2012, Sune Vuorela escreveu:
> On 2012-03-14, Boudewijn Rempt <bo...@valdyas.org> wrote:
> > It's easy enough to package -- the opensuse packages I use work perfectly
> > fine, so I cannot imagine that there are any real and relevant problems
> > for other distributions.
>
> Sure it can be done. but it is just useless churn if it doesn't really
> provide anything that matters to the end user that colord doesn't.
You are talking as if colord is the default standard and well used in KDE and then out of a suden comes oyranoes trying to replace it. Colord is not wide used in KDE and since oyranos includes a wider feature set I guess it is more usefull for a wider range of users. As said in other e-mails colord is required in Gnome3, so why not add oyranos to kdegraphics since other KDE software already work with it?
> I could package oyranos and the weird things it requires. but in the
> same time I_could probably fix 20 small annoyances for all users and
> package the new nice nepomuk ioslaves. What is the best use of my time?
You devide what is the best use of your time. I still commit patches to Kopete from time to time even though I know it is going to fade away once we move to Qt 5 (Kopete still uses Qt3Support in several places).
Sune Vuorela
> You are talking as if colord is the default standard and well used in
> KDE and then out of a suden comes oyranoes trying to replace it. Colord is not
> wide used in KDE and since oyranos includes a wider feature set I guess it is
No. colord seems to be the default standard for linux. unless we have a
good reason, I don't see why we should go for anything else.
> more usefull for a wider range of users. As said in other e-mails colord is
> required in Gnome3, so why not add oyranos to kdegraphics since other KDE
> software already work with it?
erm. kolor-manager is currently the only tool working with oyranos as I
understood it. so we should add it because it is already there?
/Sune
Thomas Zander
> Colord is not wide used in KDE and since oyranos includes a wider feature
> set I guess it is more usefull for a wider range of users.
This assumption seems to not be supported by the documentation. The specific
set of user-groups also speaks against this assumption.
> As said in
> other e-mails colord is required in Gnome3, so why not add oyranos to
> kdegraphics since other KDE software already work with it?
I'm not following this sentence; becaues gnome uses X, kde should not use X.
If thats what you are saying, I want to say I disagree.
Could you explain what you mean with the
"since other KDE already works with it"
part?
AFAIK there is no KDE software that would function better with oyranos than
with colord. Which means there is no clear advantage on that basis. Am I
missing some piece of software?
--
Thomas Zander
Matthias Klumpp
2012/3/14 Kai-Uwe Behrmann <ku...@gmx.de>:
> Am 14.03.12, 15:54 +0100 schrieb Matthias Klumpp:
>> [...]
>> I also want to point you to this comparison colord against Oryanos:
>> => http://www.freedesktop.org/software/colord/faq.html#oyranos
>
> Matthias, you help spreading false assertions here.
Then please clarify these! ;-) I find the FAQ very convincing :)
I also linked your commend, so everyone can read both views (and not
only colord FAQ)
About Elektra: The last release is from 2008, it will definitely be
difficult to convince distributors to packqage it if there's no
visible upstream activity. From Richard, who contaced the Elektry guy,
I know Elektra is alive, but thereÄs no sign of life ^^
Please do a similar table for Oryanos vs. colord than the colord
maintainer did, so we can compare them. I guess that might be helpful
even for people who don't understand color management very well.
Best,
Matthias
2012/3/14 Kai-Uwe Behrmann <ku...@gmx.de>:
Matthias Klumpp
> Em Wednesday 14 March 2012, Sune Vuorela escreveu:
>
>> On 2012-03-14, Boudewijn Rempt <bo...@valdyas.org> wrote:
>> > It's easy enough to package -- the opensuse packages I use work
>> > perfectly
>> > fine, so I cannot imagine that there are any real and relevant problems
>> > for other distributions.
>> Sure it can be done. but it is just useless churn if it doesn't really
>> provide anything that matters to the end user that colord doesn't.
> You are talking as if colord is the default standard and well used in KDE
> and then out of a suden comes oyranoes trying to replace it. Colord is not
> wide used in KDE and since oyranos includes a wider feature set I guess it
> is more usefull for a wider range of users. As said in other e-mails colord
> is required in Gnome3, so why not add oyranos to kdegraphics since other KDE
> software already work with it?
Colord is also integrated with many other parts of the stack. And that
Oryanos includes a wider feature-set doesn't necessarily mean it's the
better choice. Which other KDE software works with Oryanos already?
And btw. colord is a XDG project, not a GNOME project. Yes, it was
started by a GNOME developer, but this doesn't make it a GNOME
project. It is developed independent from GNOME.
Regards,
Matthias
Thomas Zander
> > Hi!
> > Colord - just to mention that - is also not a GNOME project, it's a
> > FreeDesktop project. (Doesn't mean it's "standard", but does mean that
> > it's not GNOME)
>
> Well, no, having something on freedesktop.org doesn't mean it's not a
> gnome project;
Little semantic confusion here :)
He said it *IS* a freedesktop project. Which means it is not a gnome
project, which seems to me to be true.
> it is a gnome project, and it's widening its scope. The
> reason it's used at all is that is is used inside gnome.
Projects should be judged on merit, irregardless of who pushes it.
If gnome is using it and that makes it grow acceptance, thats a good thing in
my book. Why; *because* acceptance is growing. I don't care if its gnome or
any other player pushing it.
That said; Cups also depends on colord. And IMO that has a bigger impact than
the gnome components that pull it in.
--
Thomas Zander
Lamarque V. Souza
Em Wednesday 14 March 2012, Sune Vuorela escreveu:
> On 2012-03-14, Lamarque V. Souza <lama...@kde.org> wrote:
> > You are talking as if colord is the default standard and well used in
> >
> > KDE and then out of a suden comes oyranoes trying to replace it. Colord
> > is not wide used in KDE and since oyranos includes a wider feature set I
> > guess it is
>
> No. colord seems to be the default standard for linux. unless we have a
> good reason, I don't see why we should go for anything else.
I should stop working in Plasma NM then since for distributions that ships Gnome as default desktop nm-applet is the standard.
If colord has a small dependency set and Dantii created the kcm is a couple of weeks, why not add support to colord in kolor-manager and add oyranos to kdegraphics. You already talked about that to Kai-Uwe and he ageed with that.
I usually in favor of the most versatile project, that is why I started to use KDE in the first place. Oyranos seems more versatile than colord, although I am also not an expert in color management.
> > more usefull for a wider range of users. As said in other e-mails colord
> > is required in Gnome3, so why not add oyranos to kdegraphics since other
> > KDE software already work with it?
>
> erm. kolor-manager is currently the only tool working with oyranos as I
> understood it. so we should add it because it is already there?
Krita too as says the other guy in the list. We do not know who is using oyranos, if oyranos is importnat to big part of KDE users then I am in favor of adding it to kdegraphics and since there is willingness to add support to colord in kolor-manager then why not?
Lamarque V. Souza
Em Wednesday 14 March 2012, Thomas Zander escreveu:
> On Wednesday 14 March 2012 16.59.55 Lamarque V. Souza wrote:
> > Colord is not wide used in KDE and since oyranos includes a wider feature
> > set I guess it is more usefull for a wider range of users.
>
> This assumption seems to not be supported by the documentation. The
> specific set of user-groups also speaks against this assumption.
Which documentation and which user-groups?
> > As said in
> > other e-mails colord is required in Gnome3, so why not add oyranos to
> > kdegraphics since other KDE software already work with it?
>
> I'm not following this sentence; becaues gnome uses X, kde should not use
> X. If thats what you are saying, I want to say I disagree.
>
> Could you explain what you mean with the
> "since other KDE already works with it"
> part?
> AFAIK there is no KDE software that would function better with oyranos than
> with colord. Which means there is no clear advantage on that basis. Am I
> missing some piece of software?
I meant that there are other KDE software that works with oyranos. I did not mean they have it as dependency.
Lamarque V. Souza
Em Wednesday 14 March 2012, Thomas Zander escreveu:
> On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote:
> > > Hi!
> > > Colord - just to mention that - is also not a GNOME project, it's a
> > > FreeDesktop project. (Doesn't mean it's "standard", but does mean that
> > > it's not GNOME)
> >
> > Well, no, having something on freedesktop.org doesn't mean it's not a
> > gnome project;
>
> Little semantic confusion here :)
> He said it *IS* a freedesktop project. Which means it is not a gnome
> project, which seems to me to be true.
That controversional. Do you know how freedesktop is working in the last years? If you did then you would not say that.
> > it is a gnome project, and it's widening its scope. The
> > reason it's used at all is that is is used inside gnome.
>
> Projects should be judged on merit, irregardless of who pushes it.
> If gnome is using it and that makes it grow acceptance, thats a good thing
> in my book. Why; *because* acceptance is growing. I don't care if its
> gnome or any other player pushing it.
>
> That said; Cups also depends on colord. And IMO that has a bigger impact
> than the gnome components that pull it in.
I use cups here and no colord.
Sune Vuorela
> I should stop working in Plasma NM then since for distributions that
> ships Gnome as default desktop nm-applet is the standard.
erm. you are aware that colord better can be compared to NetworkManager
than to Plasma NM ?
/Sune
Kai-Uwe Behrmann
> On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote:
>>> Colord - just to mention that - is also not a GNOME project, it's a
>>> FreeDesktop project. (Doesn't mean it's "standard", but does mean that
>>> it's not GNOME)
>>
>> Well, no, having something on freedesktop.org doesn't mean it's not a
>> gnome project;
>
> Little semantic confusion here :)
> He said it *IS* a freedesktop project. Which means it is not a gnome
> project, which seems to me to be true.
It was developed specifically for Gnome Color Manager and then turned into
a Glib depending library. So it bears all the specifics in it's concept.
>> it is a gnome project, and it's widening its scope. The
>> reason it's used at all is that is is used inside gnome.
>
> Projects should be judged on merit, irregardless of who pushes it.
> If gnome is using it and that makes it grow acceptance, thats a good thing in
> my book. Why; *because* acceptance is growing. I don't care if its gnome or
> any other player pushing it.
>
> That said; Cups also depends on colord. And IMO that has a bigger impact than
> the gnome components that pull it in.
CUPS has a own CM spec, which works for vendor side profiles. That
CMS exists completely outside of any DE or other CMS.
colord print CM:
CUPS does not depend in any way on colord. But colord depends on CUPS to
support it's concept of placing colord's session centric configuration
into each job on server side. I do not know how to support per session
configuration remotely or how to assign to the proper users.
It does not scale well and will likely be difficult to maintain. That is
one of the major and long standing critique points. The colord author
repeatedly said it is fine, without delivering arguments, except it is
the fastest way to implement.
OpenICC print CM:
One idea of OpenICC members is to let users configure a per queue
device profile with CUPS' own means. Thus it is best support inside CUPS.
We would like to support that in KolorManager or where appropriate
The worked on alternative is libCmpx, which embedds the user selected
device profile inside the print job PDF/X-3. PDF/X-3 as a standard will
likely work cross platform, which will be important to scale clouds and
elsewhere. These two concepts appear much robuster and are proven to work
on other operating systems. Mike Sweet confirmed that for the later, while
the other concept is deployed on Windows by some drivers.
Here some more details about the later aproach:
http://www.oyranos.org/2012/02/linux-printing/
kind regards
Kai-Uwe
--
http://www.oyranos.org
Lamarque V. Souza
Em Wednesday 14 March 2012, Sune Vuorela escreveu:
I am not comparing colord to Plasma NM, I am comparing oyranos to Plasma NM.
Alexander Neundorf
> Em Wednesday 14 March 2012, Thomas Zander escreveu:
> > On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote:
> > > > Hi!
> > > > Colord - just to mention that - is also not a GNOME project, it's a
> > > > FreeDesktop project. (Doesn't mean it's "standard", but does mean
> > > > that it's not GNOME)
> > >
> > > Well, no, having something on freedesktop.org doesn't mean it's not a
> > > gnome project;
> >
> > Little semantic confusion here :)
> > He said it *IS* a freedesktop project. Which means it is not a gnome
> > project, which seems to me to be true.
>
> That controversional. Do you know how freedesktop is working in the last
> years? If you did then you would not say that.
I agree.
Stuff which is needed for Gnome is put on xdg, and because it doesn't link to
libgnome or something like this they say it is independent from gnome.
Just the same way as all the other stuff coming from RedHat for the desktop is
independent from Gnome ;-)
Alex
Lamarque V. Souza
Em Wednesday 14 March 2012, Alexander Neundorf escreveu:
> On Wednesday 14 March 2012, Lamarque V. Souza wrote:
> > Em Wednesday 14 March 2012, Thomas Zander escreveu:
> > > On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote:
> > > > > Hi!
> > > > > Colord - just to mention that - is also not a GNOME project, it's a
> > > > > FreeDesktop project. (Doesn't mean it's "standard", but does mean
> > > > > that it's not GNOME)
> > > >
> > > > Well, no, having something on freedesktop.org doesn't mean it's not a
> > > > gnome project;
> > >
> > > Little semantic confusion here :)
> > > He said it *IS* a freedesktop project. Which means it is not a gnome
> > > project, which seems to me to be true.
> >
> > That controversional. Do you know how freedesktop is working in the last
> >
> > years? If you did then you would not say that.
>
> I agree.
> Stuff which is needed for Gnome is put on xdg, and because it doesn't link
> to libgnome or something like this they say it is independent from gnome.
It was not that I was refering to.
> Just the same way as all the other stuff coming from RedHat for the desktop
> is independent from Gnome ;-)
What happens if the stuff does not please RedHat?
Thomas Zander
> Am 14.03.12, 17:46 +0100 schrieb Thomas Zander:
> > On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote:
> >>> Colord - just to mention that - is also not a GNOME project, it's a
> >>> FreeDesktop project. (Doesn't mean it's "standard", but does mean that
> >>> it's not GNOME)
> >>
> >> Well, no, having something on freedesktop.org doesn't mean it's not a
> >> gnome project;
> >
> > Little semantic confusion here :)
> > He said it *IS* a freedesktop project. Which means it is not a gnome
> > project, which seems to me to be true.
>
> It was developed specifically for Gnome Color Manager and then turned into
> a Glib depending library. So it bears all the specifics in it's concept.
Notice I still maintain that we should judge a solution on merit, not on who
pushes it.
> > That said; Cups also depends on colord. And IMO that has a bigger impact
> > than the gnome components that pull it in.
>
> colord print CM:
> CUPS does not depend in any way on colord.
This opinion seems to conflict with the facts stated by others. Debian for
instance has 'rec' (recommend) colord for cups.[1]
Notice that colord allows components to use it without linking it in at
startup using the dbus interface for instance.
> But colord depends on CUPS to
> support it's concept of placing colord's session centric configuration
> into each job on server side.
Which makes total technical sense. No color management system will work 100%
without support in the individual components. If Cups needs to be patched to
support a new feature, that sounds sane to me.
Does it not make more sense to have color management support in cups than cups
support in the color management software? It certainly does to me :)
> It does not scale well and will likely be difficult to maintain.
As someone that is also a software developer, I disagree, with the reasons I
wrote above. :-)
Bottom line for me really is that a project that has been around for a year
has managed to grow fast and get accepted widely.
Some may argue thats because of political issues, but in the end thats not
really relevant. The end result is still 'market' acceptance.
As mentioned before, accepting kolormanager in kdegraphics is kind of a "no"
to colord. And I think thats would be cutting our own fingers.
1) http://packages.debian.org/wheezy/cups
--
Thomas Zander
Alexander Neundorf
The wiki page somebody pointed to mentioned that colord is linux-only, while
oyranos also works on Windows and OSX.
If we chose colord, how does our solution for Windows and OSX look like ?
Does kolormanager work under Windows and OSX ?
Alex
Matthias Klumpp
color-management, deeply integrated into the stack? (ColorSync on OS-X
and ColorManager on Win)
Regards,
Matthias
Thomas Zander
> The wiki page somebody pointed to mentioned that colord is linux-only,
> while oyranos also works on Windows and OSX.
>
> If we chose colord, how does our solution for Windows and OSX look like ?
> Does kolormanager work under Windows and OSX ?
Matthias answered your question very well, and I agree with him.
Let me ask you a return question; with the heavy dependency on X11 in oyranos
but with colord already starting work on wayland, how will we support wayland
soon?
--
Thomas Zander
Daniel Nicoletti
> oyranos also works on Windows and OSX.
>
> If we chose colord, how does our solution for Windows and OSX look like ?
> Does kolormanager work under Windows and OSX ?
> The wiki page somebody pointed to mentioned that colord is linux-only, while
> oyranos also works on Windows and OSX.
>
> If we chose colord, how does our solution for Windows and OSX look like ?
> Does kolormanager work under Windows and OSX ?
Imagine you put your software on OSX with windows/oxygen style wouldn't it look awful?
To have your application properly integrated there you need to integrate a bit
deeper sometimes, a plugable layer might be nice to have? not sure, and this is not what
is being proposed by any of the discussed solutions.
Alexander Neundorf
I know basically nothing about color management systems.
Don't some applications needs some kind of interface to use the color
management system ?
Or is it only for setting up X, the printer, Wayland, etc.
In the first case, if applications (e.g. krita) need some way to work with the
color management system, wouldn't it be good if KDE provided one interface on
all platforms ?
Alex
Kai-Uwe Behrmann
> On Wednesday 14 March 2012 18.12.13 Kai-Uwe Behrmann wrote:
>> Am 14.03.12, 17:46 +0100 schrieb Thomas Zander:
>>> than the gnome components that pull it in.
>>
>> colord print CM:
>> CUPS does not depend in any way on colord.
>
> This opinion seems to conflict with the facts stated by others. Debian for
> instance has 'rec' (recommend) colord for cups.[1]
CUPS is a cross platform solution. It works with colour management on osX
fine. IMO that recommendation on Debian has to do with colord in Gnome and
that colord needs compiled in support inside CUPS. No more no less.
> Notice that colord allows components to use it without linking it in at
> startup using the dbus interface for instance.
That is non relevant to the fact, that CUPS vendor colour management works
since years and without colord.
>> But colord depends on CUPS to
>> support it's concept of placing colord's session centric configuration
>> into each job on server side.
>
> Which makes total technical sense. No color management system will work 100%
I still do not see merit in the user session in CUPS server hook concept.
I would really like to understand why it is a good design, but no one gave
so far a satisfying answere on OpenICC. Maybe it can be found here?
Look at the details. colord is called inside CUPS server. CUPS servers can
be remote without any DBus connection, which colord relies upon. The CUPS
server is, well, a server, not client software. It takes print jobs
through a well defined communication path after lots of security checks.
Now colord breaks these security check on a local host and says to CUPS to
use a certain ICC profiles. colord needs special rights to take the user
configuration from a central DB. As long as the actual user is printing a
actual job with a actual colord profile it is fine. Laptop and one
person systems might work this way. But imagine that now on a multi user
system. A remote print jobs comes in. CUPS prints that with the profile of
the local user. These users are likely not the same person or account.
That is why the Oyranos project did reject the offer to place a similiar
Oyranos hook inside CUPS and why it is criticised inside OpenICC without
sufficient answeres.
The colord printing configuration architecture fits maybe to a one person
system like Android, provided that it uses a direct connection to the
actual printing device. Ironically Android does not allow for DBus.
> without support in the individual components. If Cups needs to be patched to
> support a new feature, that sounds sane to me.
There is a half new feature. The other half cuts into existing well
defined behaviour. Colour Management for vendor configured profiles
resides inside CUPS since quite some years. The rastertoprinter
filters do colour correction through the respective poppler and
ghostscript filters. The CUPS CMS configures that fine. Again CUPS does
not need colord to do robust CM. It looses robustnes through colord
introduced ambiguity. See above.
> Does it not make more sense to have color management support in cups than cups
> support in the color management software? It certainly does to me :)
That sentence covers only part of the conditions needed to judge. See
above.
>> It does not scale well and will likely be difficult to maintain.
> As someone that is also a software developer, I disagree, with the reasons I
> wrote above. :-)
My impression is, here are made assumptions that are based on abstract
ideas, which do only in parts fit to the situation. That is irritating.
> Bottom line for me really is that a project that has been around for a year
> has managed to grow fast and get accepted widely.
> Some may argue thats because of political issues, but in the end thats not
> really relevant. The end result is still 'market' acceptance.
>
> As mentioned before, accepting kolormanager in kdegraphics is kind of a "no"
> to colord. And I think thats would be cutting our own fingers.
You are broadly speculating. May I ask for what reason?
> 1) http://packages.debian.org/wheezy/cups
> --
> Thomas Zander
>
regards
Kai-Uwe Behrmann
--
http://www.oyranos.org
Kai-Uwe Behrmann
The printing concept, which we discussed in OpenICC and which we are
intessted to introduce into Oyranos / KolorManager are design to be cross
platform. We think that is important as we work daily in heterogenous
environments. So we need to rely on
A) CUPS doing the right thing in the right place. And CUP's own CM appears
fine. We can adapt our behaviour to use it for vendor and in parts for
user configured profiles.
B) or we rely on standards for print job transportation. PDF is choosen by
Linux as print format. PDF/X-3 is a international standard providing
print profile embedding. That is used by osX as well. And let me
speculate for good reasons. It is cross platform.
> Alex
Kai-Uwe Behrmann
> On Wednesday 14 March 2012, Thomas Zander wrote:
>> On Wednesday 14 March 2012 21.29.09 Alexander Neundorf wrote:
>>> The wiki page somebody pointed to mentioned that colord is linux-only,
>>> while oyranos also works on Windows and OSX.
>>>
>>> If we chose colord, how does our solution for Windows and OSX look like ?
>>> Does kolormanager work under Windows and OSX ?
>>
>> Matthias answered your question very well, and I agree with him.
>> Let me ask you a return question; with the heavy dependency on X11 in
>> oyranos but with colord already starting work on wayland, how will we
>> support wayland soon?
That might be a missconception. Oyranos core itself does link against
libc, libxml2, yajl, libdl and depending on the availability to
elektra/ltdl. The X11 device support comes inside a module. So you can
select on osX X11 or ColorSync depending on your needs. Same will work out
for a separate Wayland module once a spec is available to implement that.
> I know basically nothing about color management systems.
> Don't some applications needs some kind of interface to use the color
> management system ?
> Or is it only for setting up X, the printer, Wayland, etc.
It can do both. Provide profile lookup, options for rendering and defaults
and device setup.
> In the first case, if applications (e.g. krita) need some way to work with the
> color management system, wouldn't it be good if KDE provided one interface on
> all platforms ?
Oyranos has platform abstraction for two Linux/BSD and osX. We would be
glad to add win32 support in the not too distant future and provide a
similar crossplatform support like e.g. ArgyllCMS.
> Alex
kind regards
Kai-Uwe
--
www.oyranos.org
Daniel Nicoletti
> Don't some applications needs some kind of interface to use the color
> management system ?
> Or is it only for setting up X, the printer, Wayland, etc.
>
> In the first case, if applications (e.g. krita) need some way to work with the
> color management system, wouldn't it be good if KDE provided one interface on
> all platforms ?
Applications need a CMM, lcms2, AngryCMS, those libraries do the color correction,
the application has just to know 2 things*: Which profile the whole screen is using,
and which profiles are available that it could use. With this information it calls
what is best lcms2 or AngryCMS, be it on Windows/OSX... now imagine if
you are on Windows and there something conflicting there, which stack will
you trust the native one or a third part software?
*basically before someone kills me...
Best
Daniel Nicoletti
> Don't some applications needs some kind of interface to use the color
> management system ?
> Or is it only for setting up X, the printer, Wayland, etc.
>
> In the first case, if applications (e.g. krita) need some way to work with the
> color management system, wouldn't it be good if KDE provided one interface on
> all platforms ?
Applications need a CMM, lcms2, AngryCMS, those libraries do the color correction,
Daniel Nicoletti
> CUPS is a cross platform solution. It works with colour management on osX
> fine. IMO that recommendation on Debian has to do with colord in Gnome and
> that colord needs compiled in support inside CUPS. No more no less.
This sentence is hard to read but Recommends in Debian means recommends,
it is not required to run, so no there is no linking, no link by CUPS to colord and
no link by colord to CUPS. All DBus magic.
>> Notice that colord allows components to use it without linking it in at
>> startup using the dbus interface for instance.
>
> That is non relevant to the fact, that CUPS vendor colour management works
> since years and without colord.
It is indeed relevant because now we have a central place to configure it.
>>> But colord depends on CUPS to
>>> support it's concept of placing colord's session centric configuration
>>> into each job on server side.
>>
>> Which makes total technical sense. No color management system will work
>> 100%
>
> I still do not see merit in the user session in CUPS server hook concept.
> I would really like to understand why it is a good design, but no one gave
> so far a satisfying answere on OpenICC. Maybe it can be found here?
>
> Look at the details. colord is called inside CUPS server. CUPS servers can
> be remote without any DBus connection, which colord relies upon. The CUPS
> server is, well, a server, not client software. It takes print jobs through
> a well defined communication path after lots of security checks. Now colord
> breaks these security check on a local host and says to CUPS to use a
There is no security break, sorry, I know CUPS, CUPS is the one calling
an extra thing not the other way.
I'm not sure if this is what happens currently so I'm going to say what I would do:
First regular users don't touch /etc/cups/client.conf - The file that makes
your cups calls go away. They don't need that to talk to remote printers
CUPS is smart enough to talk to another CUPS over the network.
So a process that uses less than 1MB can just be installed on each Linux
machine (as is the case today).
If CUPS is locally installed this means it can just send the job color corrected!
Plain simple...
> The colord printing configuration architecture fits maybe to a one person
> system like Android, provided that it uses a direct connection to the actual
> printing device. Ironically Android does not allow for DBus.
I see no irony we do not target Android instead our users which lack CM.
Daniel Nicoletti
> CUPS is a cross platform solution. It works with colour management on osX
> fine. IMO that recommendation on Debian has to do with colord in Gnome and
> that colord needs compiled in support inside CUPS. No more no less.
it is not required to run, so no there is no linking, no link by CUPS to colord and
no link by colord to CUPS. All DBus magic.
>> Notice that colord allows components to use it without linking it in at
>> startup using the dbus interface for instance.
>
> That is non relevant to the fact, that CUPS vendor colour management works
> since years and without colord.
It is indeed relevant because now we have a central place to configure it.
>>> But colord depends on CUPS to
>>> support it's concept of placing colord's session centric configuration
>>> into each job on server side.
>>
>> Which makes total technical sense. No color management system will work
>> 100%
>
> I still do not see merit in the user session in CUPS server hook concept.
> I would really like to understand why it is a good design, but no one gave
> so far a satisfying answere on OpenICC. Maybe it can be found here?
>
> Look at the details. colord is called inside CUPS server. CUPS servers can
> be remote without any DBus connection, which colord relies upon. The CUPS
> server is, well, a server, not client software. It takes print jobs through
> a well defined communication path after lots of security checks. Now colord
> breaks these security check on a local host and says to CUPS to use a
There is no security break, sorry, I know CUPS, CUPS is the one calling
an extra thing not the other way.
I'm not sure if this is what happens currently so I'm going to say what I would do:
First regular users don't touch /etc/cups/client.conf - The file that makes
your cups calls go away. They don't need that to talk to remote printers
CUPS is smart enough to talk to another CUPS over the network.
So a process that uses less than 1MB can just be installed on each Linux
machine (as is the case today).
If CUPS is locally installed this means it can just send the job color corrected!
Plain simple...
> The colord printing configuration architecture fits maybe to a one person
> system like Android, provided that it uses a direct connection to the actual
> printing device. Ironically Android does not allow for DBus.
I see no irony we do not target Android instead our users which lack CM.
Weng Xuetian
why CUPS depends on colord.
http://libregraphicsworld.org/blog/entry/richard-hughes-on-color-management-in-linux-and-gnome
Which oyranos don't like to, to be more concrete, use existing
protocol / interface.
No offense on both side. Just for more information.
Matthias Klumpp
> Am 14.03.12, 21:10 +0100 schrieb Thomas Zander:
>>
>> On Wednesday 14 March 2012 18.12.13 Kai-Uwe Behrmann wrote:
>>>
>>> Am 14.03.12, 17:46 +0100 schrieb Thomas Zander:
>>>> That said; Cups also depends on colord. And IMO that has a bigger impact
>>>> than the gnome components that pull it in.
>>> colord print CM:
>>> CUPS does not depend in any way on colord.
>>
>> This opinion seems to conflict with the facts stated by others. Debian
>> for
>> instance has 'rec' (recommend) colord for cups.[1]
>
> CUPS is a cross platform solution. It works with colour management on osX
> fine. IMO that recommendation on Debian has to do with colord in Gnome and
> that colord needs compiled in support inside CUPS. No more no less.
MacOS-X it uses ColorSync, for example. Cups itself has a patch
included which makes it use colord DBus-API to talk to colord. That's
the reason for CUPS recommending colord on Debian.
>> Notice that colord allows components to use it without linking it in at
>> startup using the dbus interface for instance.
> That is non relevant to the fact, that CUPS vendor colour management works
> since years and without colord.
It does - on MacOS-X, because it uses ColorSync there :P
Regards,
Matthias
Boudewijn Rempt
> On Wednesday 14 March 2012, Thomas Zander wrote:
> > On Wednesday 14 March 2012 21.29.09 Alexander Neundorf wrote:
> > > The wiki page somebody pointed to mentioned that colord is linux-only,
> > > while oyranos also works on Windows and OSX.
> > >
> > > If we chose colord, how does our solution for Windows and OSX look like ?
> > > Does kolormanager work under Windows and OSX ?
> >
> > Matthias answered your question very well, and I agree with him.
> > Let me ask you a return question; with the heavy dependency on X11 in
> > oyranos but with colord already starting work on wayland, how will we
> > support wayland soon?
>
> I know basically nothing about color management systems.
Well, that's true for nearly everyone in this discussion. It's not a discussion based on facts, it's a discussion based on impressions, guesses, hunches and misconceptions.
> Don't some applications needs some kind of interface to use the color
> management system ?
Yes. Right now, the only interface Krita uses is the X11 atom to set the monitor profile, and for the rest, we let people select profiles from disk. This is very limited. We're not interested yet in printing or scanning, but once that comes we need to talk to the platform color management system directly.
Unless there is something cross-platform that we can talk to instead. That's worth any amount of dependencies in my book.
> Or is it only for setting up X, the printer, Wayland, etc.
>
> In the first case, if applications (e.g. krita) need some way to work with the
> color management system, wouldn't it be good if KDE provided one interface on
> all platforms ?
That is definitely true. If oyranos papers over the differences between the Linux, Windows and OSX color management systems, that is absolutely fantastic. I don't want to write my own abstraction library to query colorsync, colord and so on.
I actually started doing that last year, in fact, and then decided not to continue. It was when I tried to implement colord support during LGM, and figured that I'd need to implement similar support on Windows and OSX since my cross-platform app now was using platform-dependent things.
--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Lamarque V. Souza
Em Wednesday 14 March 2012, Daniel Nicoletti escreveu:
> 2012/3/14 Kai-Uwe Behrmann <ku...@gmx.de>:
> > CUPS is a cross platform solution. It works with colour management on osX
> > fine. IMO that recommendation on Debian has to do with colord in Gnome
> > and that colord needs compiled in support inside CUPS. No more no less.
>
> This sentence is hard to read but Recommends in Debian means recommends,
> it is not required to run, so no there is no linking, no link by CUPS to
> colord and no link by colord to CUPS. All DBus magic.
Debian applies a patch to add colord support to cups, that is what Kai-Uwe is talking about. Cups itself does not require colord, so it cannot be used in favor of colord.
> >> Notice that colord allows components to use it without linking it in at
> >> startup using the dbus interface for instance.
> >
> > That is non relevant to the fact, that CUPS vendor colour management
> > works since years and without colord.
>
> It is indeed relevant because now we have a central place to configure it.
As long as you patch cups and all other applications to use. Oyranos is also a central place to do color management as far as I know, this argument is valid for both.
Daniel Nicoletti
>As long as you patch cups and all other applications to use. Oyranos is also a central place
> to do color management as far as I know, this argument is valid for both.
It is valid once it's written, once there is a line of code doing it's job. Or we can just play politics.
You say you want the best one, have you tried them both?
Lamarque V. Souza
Em Wednesday 14 March 2012, Daniel Nicoletti escreveu:
So you are saying your original argument is not valid anymore?
I said I wanted the most versatile, which means one that satisfies my needs *and* somebody else's needs. You are completey ignoring the fact that there are people using oyranos too, it has been developed for years, do you think it's fair to drop all that work now? I am in favor of adding support to both colord and oyranos in kdegraphics. One way of doing that is adding support to colord to kolor-manager, which talks has already started.
And no, I have not tested either of them and how computer color management is supposed to work for a daltonian (like me)? Even if I had tested by what everybody already said here, nobody is an expert in color managament to judge the merits of either project, so let's add support to both. As I wrote before, as long as the project has a community to maintain it, I do not see why not use it.
Daniel Nicoletti
far as I can tell he didn't decide the best way to do it, OTOH we have
something that already works for a bunch of people.
> I said I wanted the most versatile, which means one that satisfies my needs
> *and* somebody else's needs. You are completey ignoring the fact that there
> are people using oyranos too, it has been developed for years, do you think
> it's fair to drop all that work now? I am in favor of adding support to both
> colord and oyranos in kdegraphics. One way of doing that is adding support
> to colord to kolor-manager, which talks has already started.
Tell me, who is using besides Cine Paint?
I never said a word on dropping Oyranos development, but I do believe from
a technological point of view it hasn't succeed in all these years. We now
have telepathy. Who will be willing to keep kopete which has far more years
than even Oyranos in favor of a nicer user experience? Or even dolphin why
stop using konqueror file management when a file driven experience has come
in place?
> And no, I have not tested either of them and how computer color management
> is supposed to work for a daltonian (like me)? Even if I had tested by what
> everybody already said here, nobody is an expert in color managament to
> judge the merits of either project, so let's add support to both. As I wrote
> before, as long as the project has a community to maintain it, I do not see
> why not use it.
Surely even daltonians would like to see on their computers colors more
close to reality, I don't see why this have to be different if you are daltonian or not.
I don't believe anyone needs to be a color expert to tell which is best, we
are developers we know development if you need to maintain a piece of software
what matters is your development skills. I can't maintain a complex piece
of software few people understand.
Best.
Matthias Klumpp
=> https://www.ohloh.net/p/colord
=> https://www.ohloh.net/p/oyranos
Of course there metrics are unfair to both projects (metrics always
are), but they might provide some information about activity,
contributors and codebase. (although I don't think we should pay too
much attention on these)
2012/3/15 Lamarque V. Souza <lama...@kde.org>:
Lamarque V. Souza
Em Wednesday 14 March 2012, Daniel Nicoletti escreveu:
> > So you are saying your original argument is not valid anymore?
>
> Where is the Oyranos CUPS patch? All I see is a planning since as
> far as I can tell he didn't decide the best way to do it, OTOH we have
> something that already works for a bunch of people.
Oyranos were against the patch, Kai-Uwe already said that and explained why. The fact that there is patch does not mean it is the correct way to do things. The fact that it is not integrated upstream can also mean cups developers to do not like it. Do you know what they think about the patch?
> > I said I wanted the most versatile, which means one that satisfies my
> > needs *and* somebody else's needs. You are completey ignoring the fact
> > that there are people using oyranos too, it has been developed for
> > years, do you think it's fair to drop all that work now? I am in favor
> > of adding support to both colord and oyranos in kdegraphics. One way of
> > doing that is adding support to colord to kolor-manager, which talks has
> > already started.
>
> Tell me, who is using besides Cine Paint?
I was talking about people using oyranos, not programs. I think people matters more than programs (that is what the rebranding of "KDE" to mean the community was all about). I do not how many programs use oyranos, I am very new to this color management world. I know Krita can use it, then so far two programs. Not counting compiz because most KDE users (people) use kwin instead. I really think oyranos should integrate better with cups and kwin, which I think are the most used programs that can benefit from it.
> I never said a word on dropping Oyranos development, but I do believe from
> a technological point of view it hasn't succeed in all these years. We now
> have telepathy. Who will be willing to keep kopete which has far more years
> than even Oyranos in favor of a nicer user experience? Or even dolphin why
> stop using konqueror file management when a file driven experience has come
> in place?
What do you think is going to happen if Oyranos lose support from all major desktops? That is a dead end for any user-oriented opensource project. I still commit patches to Kopete, but I already know and said that its fate is to disappear. OBS: I am going to use Kopete until there is no metacontact implementation in telepathy-kde :-P or until I can keep it working. By the way, telepathy-kde was meant to be a KDE 4 project. Before KDE 4.0.0 was released most Kopete developers tried to implement a KDE telepathy client and failed. I do not know if that was the cause of Kopete developers lose interest in Kopete but that for sure made Kopete 4.0.0 sub-par to 3.5.10 feature wise speaking. That was why I started to commit patches to Kopete, I wanted to implement the missing features from 3.5.10, that was in 2009. I do not use file managers, so I did not try to make Konqueror still work :-D but I am in charge of Plasma NM, which has less features than nm-applet. If I followed your examples I would be using MacOS or even Windows by now instead of helping develop KDE sofware.
> > And no, I have not tested either of them and how computer color
> > management is supposed to work for a daltonian (like me)? Even if I had
> > tested by what everybody already said here, nobody is an expert in color
> > managament to judge the merits of either project, so let's add support
> > to both. As I wrote before, as long as the project has a community to
> > maintain it, I do not see why not use it.
>
> Surely even daltonians would like to see on their computers colors more
> close to reality, I don't see why this have to be different if you are
> daltonian or not. I don't believe anyone needs to be a color expert to
> tell which is best, we are developers we know development if you need to
> maintain a piece of software what matters is your development skills. I
> can't maintain a complex piece of software few people understand.
You tell me, I do not know how to test color management. How did you test colord for instance? You are saying colord is best based on your personal use of color management (and the number of colord users, which is mandatory for Gnome3 by what I know). Have you ever considered that your personal use is not what other users of color management software need? I am maintaining a complex piece of software few people (fully) understand.
Lamarque V. Souza
Em Wednesday 14 March 2012, Matthias Klumpp escreveu:
> Speaking of project activity:
> => https://www.ohloh.net/p/colord
> => https://www.ohloh.net/p/oyranos
> Of course there metrics are unfair to both projects (metrics always
> are), but they might provide some information about activity,
> contributors and codebase.
Ok
> (although I don't think we should pay too
> much attention on these)
^^^^^^^ ???????
Have you ever used google trends with kde and gnome words? We should stop using KDE software.
Daniel Nicoletti
>there is patch does not mean it is the correct way to do things. The fact that it is not integrated
>upstream can also mean cups developers to do not like it. Do you know what they think about the patch?
they are currently removing all non-OSX filters, which is why a fork idea is surrounding us.
So yes, they won't accept patches for Linux only things.
>> > I said I wanted the most versatile, which means one that satisfies my
>> > needs *and* somebody else's needs. You are completey ignoring the fact
>> > that there are people using oyranos too, it has been developed for
>> > years, do you think it's fair to drop all that work now? I am in favor
>> > of adding support to both colord and oyranos in kdegraphics. One way of
>> > doing that is adding support to colord to kolor-manager, which talks has
>> > already started.
>>
>> Tell me, who is using besides Cine Paint?
>
>I was talking about people using oyranos, not programs. I think people matters more than programs (that is what the rebranding of "KDE" to mean the community was all about). I do not how many programs use oyranos, I am very new to this color management world. I know Krita can use it, then so far two programs. Not counting compiz because most KDE users (people) use kwin instead. I really think oyranos should integrate better with cups and kwin, which I think are the most used programs that can benefit from it.
Well PackageKit, upower, NM all integrates well in KDE all of them are FDO and you
even help one of these with a frontend, I myself help PackageKit and now colord since
Dario is already doing awesome work with upower.
(except from NM, colord, packagekit and upower comes from Richard).
>What do you think is going to happen if Oyranos lose support from all major desktops? That is a dead end for any user-oriented opensource project. I still commit patches to Kopete, but I already know and said that its fate is to disappear. OBS: I am going to use Kopete until there is no metacontact implementation in telepathy-kde :-P or until I can keep it working. By the way, telepathy-kde was meant to be a KDE 4 project. Before KDE 4.0.0 was released most Kopete developers tried to implement a KDE telepathy client and failed. I do not know if that was the cause of Kopete developers lose interest in Kopete but that for sure made Kopete 4.0.0 sub-par to 3.5.10 feature wise speaking. That was why I started to commit patches to Kopete, I wanted to implement the missing features from 3.5.10, that was in 2009. I do not use file managers, so I did not try to make Konqueror still work :-D but I am in charge of Plasma NM, which has less features than
nm-applet. If I followed your examples I would be using MacOS or even Windows by now instead of helping develop KDE sofware.
Again the story is simple QtDBus didn't had support for some features
Telepathy needed, I don't know when the patches got accepted Qt upstream,
but that was actually the problem. I tryied too give Kopete new life but felt
like Richard trying to change a rock. Some people tho being open minded
can still reject your ideas, and I myself find it easier to gave up or to start a new
project than keep arguing with something that won't change.
>You tell me, I do not know how to test color management. How did you test colord for instance?
First you need to build the software or use the packaged version, see how things work,
now I started a replacement for system-config-printer because it has authentication
problems and is written in python. when I go to Oyranos I found a bunch of tech I don't
like, not just I don't like but many developers don't, so who will maintain those technologies
if few people like/use it?
sytem-config-printer is better than print-manager but no one fixed the authentication
bug till today, and will likely never do, print-manager in a few months got real acceptance.
I don't want to kill Oyranos but I do think the choices based on wrong use cases might
lead to an end, a good project done with a wrong design won't succeed. Take smart for
example, PackageKit in a few years was able to do what they tried for many years,
and stop saying that Gnome or Red Hat is pushing it, you can have Gnome without it,
FDO also plays by it's own rules, let's focus on what really matters which is the code. No user
will help you maintain a line of code, they will use what we best choose to them.
Sven Langkamp
On Wednesday 14 March 2012 Mar, Daniel Nicoletti wrote:There should be only one.
> > Request:
>
> > After working on KolorManager and Oyranos in the past months for the last
> > Oyranos-0.4.0 release, we feel the stack is ready to review for inclusion into
> > KDE.
> > KolorManager resides currently in Playground/Graphics:
> > http://quickgit.kde.org/?p=kolor-manager.git&a=summary
>
> Just a quick question, currently we have two CMS stacks, colord and
> oyranos, while
> I have nothing against having two of them in KDE, I wonder if this would become
> a problem for colord-kde [1] to enter in kdegraphics too?
No. There should be color management by default in KDE, that's really important; and there should be only one solution by default. We shouldn't let distributions, or even worse, users decide which solution they use. That way madness lies. KDE's Color management solution shouldn't be in extragear.
> In that case
> would be better
> to both go to kdeextragear or is there some different policy in this case?
Distribution shouldn't decide that, but I think they will do it. If Fedora and Ubuntu both push colord, then it will practically become the standard, no matter which one is actually better. From past experience it's more than likely that they would patch it otherwise. Beside if e.g. Krita is running under Gnome it would have to interact with colord.
This could become the next Betamax vs VHS. My feeling is that colord currently is on the way to win this, as it backed by more projects.
As to which one is selected, there are a couple of ways to decide.
The first is, first come, first go. Kolormanager has been in development for quite some time now, and colord is an upstart, gnome-derived technology. Integration of colord in kde was only started very recently. Everyone is free to start a competing project, even inside KDE, but to make that project block a pre-existing project isn't the way to go.
Well it's not nice, but it happened before e.g. DBUS/DCOP or telepathy. Still it's sad what happened here.
The second way to decide would be on technical merits. I'm not going to go into that discussion; I've seen too many tiresome discussions already, and I don't feel really competent anyway.
As can be observed in this thread both solutions have some advantages and disadvantages. They are hardly comparable and we have no experts to look into this.
For me as an application developer, life sucks anyway, since I have to support Linux, Windows and OSX, so for the time being, the application will offer its own way to select profiles, in addition to using the X11 display atom that both colord and kolormanager support. (And I don't want to think about printing anyway.)
Michael Pyne
> I would really prefer to at least have one common gui. preferably just
> one stack. But if we have to have two competing stacks until one of them
> dies, then I guess we will just have to live with it. But do it with a
> common gui. pretty please.
I agree that whatever we do there should be only one main KDE GUI to an
underlying color management system (CMS).
Going off-topic to discuss the thread in general, I have some thoughts on the
matter:
First off, I'm quite sympathetic to the plight of the Oyranos devs. Much like
KDE, they have tried to make a user-customizable, modular, extensible,
feature-complete system with efforts made at cross-platform functionality,
standards development and compliance, and feature implementation in a "as
correct as possible" fashion.
The problem is that the software is /like/ KDE but doesn't use any KDE
technologies. To best utilize a given subsystem we would typically use at
least a light abstraction layer, using Oyranos (at this stage) entails a KDE
abstraction layer on top of a KDE-like abstraction layer (unless KDE apps code
to Oyranos directly, which I don't see as likely in general). This API
impedance mismatch is undesirable for much the same reasons that we don't
typically code to glib or gobject APIs.
Additionally I don't see any good reason to /not/ support colord. Ignoring the
other parallel about KDE-like software being reimplemented by a glib-based
"simpler application", the fact is that colord is widely distributed on Linux
and can (AFAICT) be driven over a fairly simple DBus API. If KDE is going to
support CMS at all there's no reason not to support that if it's present and
installed.
However this by itself doesn't mean KDE necessarily shouldn't or can't support
Oyranos. There's a few major points which I think if can be answered would
help clarify what that would look like:
* What feature(s) does Oyranos support over and above colord? I think we're
all in agreement that Oyranos does /more/, but what specifically does that
mean?
* What of those extra features are "a big deal" for a desktop environment
(i.e. would specifically would we *not* be providing our users by supporting
colord and not supporting Oyranos).
If these extra features are things that are ONLY "professional grade" then it
may make more sense to have Oyranos configuration be an e.g.
extragear/graphics type of thing that software like Digikam and Krita could
use and/or depend on.
On the other hand if there are things that a mere 'power user' might find
useful (that colord will not be supporting due to scope) then it might make
sense to have extra U/I if Oyranos is available. Perhaps multi-monitor CMS
would fit the bill (assuming colord will not support).
* Finally, assuming no direct support for Oyranos in a KCM, what would be
needed to allow a user to use Oyranos in a KDE Desktop? E.g. let's assume that
colord is always available on Ubuntu and so KDE can interact with it, but the
user wants to use Oyranos... what does KDE have to do to allow the user to
manually control their color profiles without a KDE daemon interfering?
Regards,
- Michael Pyne
Lamarque V. Souza
Em Wednesday 14 March 2012, Daniel Nicoletti escreveu:
> >Oyranos were against the patch, Kai-Uwe already said that and explained
> >why. The fact that there is patch does not mean it is the correct way to
> >do things. The fact that it is not integrated upstream can also mean cups
> >developers to do not like it. Do you know what they think about the
> >patch?
>
> If you follow the news you'd now how CUPS is driven, Apple doesn't like
> Linux, they are currently removing all non-OSX filters, which is why a
> fork idea is surrounding us. So yes, they won't accept patches for Linux
> only things.
I did not know about that problem with Apple. That's going to be a big problem for Linux users.
> >> > I said I wanted the most versatile, which means one that satisfies my
> >> > needs *and* somebody else's needs. You are completey ignoring the fact
> >> > that there are people using oyranos too, it has been developed for
> >> > years, do you think it's fair to drop all that work now? I am in favor
> >> > of adding support to both colord and oyranos in kdegraphics. One way
> >> > of doing that is adding support to colord to kolor-manager, which
> >> > talks has already started.
> >>
> >> Tell me, who is using besides Cine Paint?
> >
> >
> >I was talking about people using oyranos, not programs. I think people
> >matters more than programs (that is what the rebranding of "KDE" to mean
> >the community was all about). I do not how many programs use oyranos, I
> >am very new to this color management world. I know Krita can use it, then
> >so far two programs. Not counting compiz because most KDE users (people)
> >use kwin instead. I really think oyranos should integrate better with
> >cups and kwin, which I think are the most used programs that can benefit
> >from it.
>
> Well PackageKit, upower, NM all integrates well in KDE all of them are FDO
> and you even help one of these with a frontend, I myself help PackageKit
> and now colord since Dario is already doing awesome work with upower.
> (except from NM, colord, packagekit and upower comes from Richard).
Like I also help with Wicd support in KDE, Kopete, and other areas of interests for KDE users. I do not use Wicd, but I help KDE users of Wicd even before I was the Network Management maintainer. By the way, I am not driven by FDO interests. We are using upower/udisks because there is no other choice in Linux, hal is unmaintained as you probably know. That is why I think we should have a community to maintain the software we depend upon.
> >You tell me, I do not know how to test color management. How did you test
> >colord for instance?
>
> First you need to build the software or use the packaged version, see how
> things work, now I started a replacement for system-config-printer because
> it has authentication problems and is written in python. when I go to
> Oyranos I found a bunch of tech I don't like, not just I don't like but
> many developers don't, so who will maintain those technologies if few
> people like/use it?
That's too personal oppinion and you sound like nobody likes oyranos.
> sytem-config-printer is better than print-manager but no one fixed the
> authentication bug till today, and will likely never do, print-manager in
> a few months got real acceptance.
>
> I don't want to kill Oyranos but I do think the choices based on wrong use
> cases might lead to an end, a good project done with a wrong design won't
> succeed. Take smart for example, PackageKit in a few years was able to do
> what they tried for many years, and stop saying that Gnome or Red Hat is
> pushing it, you can have Gnome without it, FDO also plays by it's own
> rules, let's focus on what really matters which is the code. No user will
> help you maintain a line of code, they will use what we best choose to
> them.
I have never used PackageKit and said nothing about it. Are you talking about PakcageKit or colord here? If it is about Gnome without colord I am not sure if that is possible, anyway, why would they patch cups to add support to colord if it is not going to be used in the desktops? Users can help with patches from time to time, that is important, and I was only a Knetworkmanager user before I started to contribute. Your statement is completely wrong in an opensource world.
Daniel Nicoletti
Right so which community you are talking about, because
Kai likes KDE, it seems that you are putting FDO/Gnome as things we should
get away, instead of actually looking at how maintainable these two things are
and yet share code which is really important.
>> First you need to build the software or use the packaged version, see how
>> things work, now I started a replacement for system-config-printer because
>> it has authentication problems and is written in python. when I go to
>> Oyranos I found a bunch of tech I don't like, not just I don't like but
>> many developers don't, so who will maintain those technologies if few
>> people like/use it?
>
>That's too personal oppinion and you sound like nobody likes oyranos.
It's a personal opinion indeed but this doesn't mean nobody likes Oyranos,
it simply means that looking at the code there won't be much devs willing
to maintain that. The deps speak for themselves.
>> I don't want to kill Oyranos but I do think the choices based on wrong use
>> cases might lead to an end, a good project done with a wrong design won't
>> succeed. Take smart for example, PackageKit in a few years was able to do
>> what they tried for many years, and stop saying that Gnome or Red Hat is
>> pushing it, you can have Gnome without it, FDO also plays by it's own
>> rules, let's focus on what really matters which is the code. No user will
>> help you maintain a line of code, they will use what we best choose to
>> them.
>
>If it is about Gnome without colord I am not sure if that is possible, anyway, why would they patch cups to add support to colord if it is not going to be used in the desktops?
Gnome works pretty much the same way as KDE we have modules, so the do,
you can just remove/disable and Gnome will run without it, but why remove
a cool feature? It's non sense, it's obvious that every distro would push because
they want the missing feature, if Oyranos was there first maybe colord didn't had
to exist.
>I have never used PackageKit and said nothing about it. Are you talking about PakcageKit or colord here? Users can help with patches from time to time, that is important, and I was only a Knetworkmanager user before I started to contribute. Your statement is completely wrong in an opensource world.
You don't get it, I'm giving an example of how good projects dies because
from a technical point of view they become unmaintainable.
Sure, pretty much everyone is first an user then a developer but this doesn't mean
you can expect from users of a software to maintain that, otherwise most of these
projects wouldn't go into an end.
Daniel Nicoletti
> find
> useful (that colord will not be supporting due to scope) then it might make
> sense to have extra U/I if Oyranos is available. Perhaps multi-monitor CMS
> would fit the bill (assuming colord will not support).
I'm sure you were just giving an example but as someone earlier mentioned
something about NVIDIA here's the explanation:
Multi monitor color correction works as long as your video driver supports
XRandR 1.3, which means NVIDIA proprietary driver is the only one not
supporting this. If we support XRR 1.2 both monitors get the same correction.
Best,
Stas Verberkt
> There's a few major points which I think if can be answered would
> help clarify what that would look like:
answers. As someone who has no understanding of colour managemant
whatsoever
and without any bias, I, indeed, see some questions to be answered, in the
hope this will provide us with some structure.
* First of all, how expensive would it be to provide a small abstraction
allowing drop-in replacement of Oyranos by colord and the other way
around, e.g. have one interface and two backends?
* If the platforms supported by the backend are different from the
platforms targetted by KDE, how do we cope on these other targets? Should
we answer question one with: indeed one interface, however, four backends
-- given whatever Windows, MacOSX, or whatever platform you like and KDE
targets uses.
> * What of those extra features are "a big deal" for a desktop environment
> (i.e. would specifically would we *not* be providing our users by
> supporting
> colord and not supporting Oyranos).
>
* Maybe reformulated to: What are the target audiences of the
applications? If one is more aimed at the default user and another at
certain professionals this calls for a different view at the situation. As
some people tend to say: one size does not always fits all.
Furthermore, I expect that there should be some communication between the
goals of KDE and those of the solution we prefer.
> * What feature(s) does Oyranos support over and above colord? I think
> we're
> all in agreement that Oyranos does /more/, but what specifically does that
> mean?
>
* A feature-wise comparison, although that quite easily gives a false
impression. For example, a product may have way more features, but because
of some fundamental design decisions we do not like, or the other way
around, something may be over simplified. Thus, such a comparison requires
real expertise and no bias.
It would probably be best if the developers explained what makes there
software great and not so much what makes other software less worthy.
> * Finally, assuming no direct support for Oyranos in a KCM, what would be
> needed to allow a user to use Oyranos in a KDE Desktop? E.g. let's assume
> that
> colord is always available on Ubuntu and so KDE can interact with it, but
> the
> user wants to use Oyranos... what does KDE have to do to allow the user to
> manually control their color profiles without a KDE daemon interfering?
>
* Maybe this should be asked for all possible solutions? Also, given the
fact that there are people working or willing to work on KDE integration
of both, this hould not be too much of a problem, I would guess.
As a final remark, please note that the diversity in the open source world
in general and the Linux world specific is, most of the time, considered a
good thing. Competing projects are generally responsible for more
innovation than monopolies.
If we can embrace this, it would be wonderful.
Kai-Uwe Behrmann
> 2012/3/14 Kai-Uwe Behrmann <ku...@gmx.de>:
>> Am 14.03.12, 15:54 +0100 schrieb Matthias Klumpp:
>>> [...]
>>> I also want to point you to this comparison colord against Oryanos:
>>> => http://www.freedesktop.org/software/colord/faq.html#oyranos
>>
>> Matthias, you help spreading false assertions here.
> Please do a similar table for Oryanos vs. colord than the colord
> maintainer did, so we can compare them. I guess that might be helpful
> even for people who don't understand color management very well.
The table you link to is biased and, in my opinion, unfair. It would
probably just as unfair if I started a similar comparison table. That
is really a job for a third party reviewer. But instead I will list
here the features Oyranos has right now, which I think will be directly
useful to end users.
I think it is worth noting that Oyranos and colord aren not the only
players. There is also the very powerful and very valuable ArgyllCMS.
Anyway, here about what Oyranos provides:
Oyranos properties
General Concept
* cross platform API (Linux, BSD, osX, started win32)
* abstraction from platform specific conventions
* interfacing native OS specific CMS'es
* cross desktop
* toolkit independent library
* standalone front end Synnefo in Qt (similiar to KolorManager)
* selfcontained and modular design
* most dependencies reside in runtime switchable modules
* lightwight core
* modules can be easily maintained, exchanged, fixed or extented
* installations can be customised (e.g. skipping X11 module for pure
print servers)
* adhering to existing standards and work on new ones inside OpenICC / ICC
* OpenICC is a fd.o project
* we help creating and maintaining proposals and specs
* Oyranos just works
* KolorManager enables even nonexpert users to configure their devices
* new BSD License
Settings
* complete CM settings like in advanced graphics applications
* CinePaint
* ICC Examin
* optional, apps decide what they want to support
* hybrid approach possible like
explicitely syncing internal settgings with Oyranos
* users can share CM options across supporting applications
e.g. enabling proofing and selection of a proof profile
That can reduce repeating settings in each application.
* clear concept of user owned and system owned settings
* user versus system rights are much more naturaly handled
* administrators can provide useful machine specific defaults
* portable
* policy / grouping for easy switching, export, import of default settings
* country specific defaults
* company specific defaults or
* task specific defaults
Profile Handling
* profile lookup
* including support of platform specifics
* profile parsing
* minor corrections like profile ID assignment
* caching
* profile writing (but no own profiling like ArgyllCMS)
Processing
* colour conversion API
* optional
* apps can offload CM decission to Oyranos on demand
* still fine controled settings possible
* supports proofing, effect profiles
* arbitrary channel count and bit depths like CMM (lcms)
* profile and transform caching for fast access
* backend API for plugable CMMs (lcms, lcms2, GPU based are possible)
* stand alone modules, without external requirements
* these CMM's are selectable through the colour conversion API
* DAC based imaging for extension to HDR imaging and spectral imaging
* state of the art, like in Gegl, Blender or other node based engines
* 2D capable API
* useful for adding tonemapping
* CPU based multi monitor colour correction
* needs the above imaging DAC, the monitor module and a CMM
* works independent of window managers
* used in some widgets in ICC Examin
* traceable colour correction for easy debugging through users
* unexpected results happen allways, this is a way to track processing
* convenient for end users
* speeds up error search by using simle tools
* no gdb needed
* named colour support
* used in ICC Examin
* would be useful in KDE colour selectors
* high precission colorimetry with native channels easily possible
Device Profile Assignment
* automatic device profile based on parsed hardware and ICC meta data
* automatic profile selection according to a given device
* Taxi support for remote distributed ICC profiles
* online DB for ICC device profiles
* dispcalGUI can upload to Taxi DB
* selection and download of profiles from remote DB by Oyranos
* spec is shared through OpenICC for more users
* backend API for device property modules
* for device identification and
* most complete tracking of colour related settings in drivers
* abstracted from apps, which do not need to care about specifics
* multi monitor support includes
* XRandR like intel
* nvidia drivers
* ati drivers need more testing
* on-the-fly fallback from EDID profile generation
* supports cameraRAW/LibRaw combo
* allows to select a custom ICC profile for a given camera
* robust printer configuration concepts
* planned support of per queue profiles in KM
* libCmpx can be used to embedd a device profile inside a PDF
supports the PDF/X-3 specification
Toolkit Support
* first prototyp for window based colour correction inside a widget
* used in ICC Examin
* but needs more integration work and port to Qt
* support of libXcm (region and window based window communication)
I've been working on colour management for about eight years. It is hard
for me to explain all, what I've been working on for so long in that field
- so if there is anything not clear about this list of features of
Oyranos, please ask.
kind regards
Kai-Uwe
--
Kai-Uwe Behrmann
http://www.oyranos.org
Kai-Uwe Behrmann
> 2012/3/14 Kai-Uwe Behrmann <ku...@gmx.de>:
> It is indeed relevant because now we have a central place to configure it.
And users need to manage and error check everything themself. I would not
use that in a professional environment, where time counts.
>>>> But colord depends on CUPS to
>>>> support it's concept of placing colord's session centric configuration
>>>> into each job on server side.
>>>
>>> Which makes total technical sense. No color management system will work
>>> 100%
>>
>> I still do not see merit in the user session in CUPS server hook concept.
>> I would really like to understand why it is a good design, but no one gave
>> so far a satisfying answere on OpenICC. Maybe it can be found here?
>>
>> Look at the details. colord is called inside CUPS server. CUPS servers can
>> be remote without any DBus connection, which colord relies upon. The CUPS
>> server is, well, a server, not client software. It takes print jobs through
>> a well defined communication path after lots of security checks. Now colord
>> breaks these security check on a local host and says to CUPS to use a
> There is no security break, sorry, I know CUPS, CUPS is the one calling
> an extra thing not the other way.
That is wrong. CUPS is patched to call colord. CUPS itself does not use or
need a extra thing.
> I'm not sure if this is what happens currently so I'm going to say what I would do:
> First regular users don't touch /etc/cups/client.conf - The file that makes
> your cups calls go away. They don't need that to talk to remote printers
> CUPS is smart enough to talk to another CUPS over the network.
> So a process that uses less than 1MB can just be installed on each Linux
> machine (as is the case today).
> If CUPS is locally installed this means it can just send the job color corrected!
You checked that? The first respond from the colord author, which I have
read, was that the remote machine shall be configured through colord.
Hence my above discussion of such a situation.
Now you suggest that the local client does colour correct a spooling PDF?
Are you sure? That would be a great feature and much more work than a
small hook inside CUPS. Nothing indicated, that the colord author wants to
support that approach.
So far colour conversion happens on the end machine. That is the one,
which is connected to the device. That fits to what Michael Sweet says
about early versus late colour binding, suggesting that early colour
binding can cause gigabytes of traffic, while late colour bind will have
no such issue.
> Plain simple...
>
>> The colord printing configuration architecture fits maybe to a one person
>> system like Android, provided that it uses a direct connection to the actual
>> printing device. Ironically Android does not allow for DBus.
>
> I see no irony we do not target Android instead our users which lack CM.
Public news stated, that Qt apps are already on Android.
kind regards
Kai-Uwe
Kai-Uwe Behrmann
Personally I develop mainly on a nvidia machine with two very different
monitors in part over DP. Colour correction works to each with the Oyranos
setup.
Even though I would prefere nvidia added support for XRandR properly.
kind regards
Kai-Uwe
Kai-Uwe Behrmann
>> Like I also help with Wicd support in KDE, Kopete, and other areas of interests for KDE users. I do not use Wicd, but I help KDE users of Wicd even before I was the Network Management maintainer. By the way, I am not driven by FDO interests. We are using upower/udisks because there is no other choice in Linux, hal is unmaintained as you probably know. That is why I think we should have a community to maintain the software we depend upon.
>
> Right so which community you are talking about, because
> Kai likes KDE, it seems that you are putting FDO/Gnome as things we should
> get away, instead of actually looking at how maintainable these two things�are
> and yet share code which is really important.
>
>>> First you need to build the software or use the packaged version, see how
>>> things work, now I started a replacement for system-config-printer because
>>> it has authentication problems and is written in python. when I go to
>>> Oyranos I found a bunch of tech I don't like, not just I don't like but
>>> many developers don't, so who will maintain those technologies if few
>>> people like/use it?
Few developers like to code CMMs. On the other hand many people want ICC
support. Yeah colour management is non trivial in the basics. That is not
new. The more useful is a API like lcms provides and a maintainer, who
cares about the core stuff and it's necessary complexities.
And to get it right, device configuration is also non trivial. There needs
not only the device identification as requireed for profile selection but
as well the driver and the colour settings for that driver. Oyranos is one
of the few libraries, which supports that in a generic way, without the
need of special setups or closed loop systems.
>> That's too personal oppinion and you sound like nobody likes oyranos.
>
> It's a personal opinion indeed but this doesn't mean nobody likes Oyranos,
> it simply means that looking at the code there won't be much devs willing
> to maintain that. The deps speak for�themselves.�
You need to maintain the same dependencies of the Oyranos device modules
inside your KDE code. Oyranos just abstracts that out into run time
modules. Otherwise access to monitor or printer informations is not easy.
>> I have never used PackageKit and said nothing about it. Are you talking about PakcageKit or colord here? Users can help with patches from time to time, that is important, and I was only a Knetworkmanager user before I started to contribute. Your statement is completely wrong in an opensource world.
>
>
> You don't get it, I'm giving an example of how good projects dies because
> from a technical point of view they become unmaintainable.
Some special guys have a tradition in declaring other projects dieing.
kind regards
Kai-Uwe
Lamarque V. Souza
Em Thursday 15 March 2012, Daniel Nicoletti escreveu:
> >Like I also help with Wicd support in KDE, Kopete, and other areas of
> >interests for KDE users. I do not use Wicd, but I help KDE users of Wicd
> >even before I was the Network Management maintainer. By the way, I am not
> >driven by FDO interests. We are using upower/udisks because there is no
> >other choice in Linux, hal is unmaintained as you probably know. That is
> >why I think we should have a community to maintain the software we depend
> >upon.
>
> Right so which community you are talking about, because
> Kai likes KDE, it seems that you are putting FDO/Gnome as things we should
> get away, instead of actually looking at how maintainable these two
> things are and yet share code which is really important.
The community that develops and maintains the software in question. In the sentence above it was hal's community, in this thread are the oyranos and colord's communities.
> >> First you need to build the software or use the packaged version, see
> >> how things work, now I started a replacement for system-config-printer
> >> because it has authentication problems and is written in python. when I
> >> go to Oyranos I found a bunch of tech I don't like, not just I don't
> >> like but many developers don't, so who will maintain those technologies
> >> if few people like/use it?
> >
> >
> >That's too personal oppinion and you sound like nobody likes oyranos.
>
> It's a personal opinion indeed but this doesn't mean nobody likes Oyranos,
> it simply means that looking at the code there won't be much devs willing
> to maintain that. The deps speak for themselves.
Maybe, that is something that needs to be discussed with oyranos' community. By what I read in this thread elektra is still maintained and is optional, not sure about fltk.
> >> I don't want to kill Oyranos but I do think the choices based on wrong
> >> use cases might lead to an end, a good project done with a wrong design
> >> won't succeed. Take smart for example, PackageKit in a few years was
> >> able to do what they tried for many years, and stop saying that Gnome
> >> or Red Hat is pushing it, you can have Gnome without it, FDO also plays
> >> by it's own rules, let's focus on what really matters which is the
> >> code. No user will help you maintain a line of code, they will use what
> >> we best choose to them.
> >
> >
> >If it is about Gnome without colord I am not sure if that is possible,
> >anyway, why would they patch cups to add support to colord if it is not
> >going to be used in the desktops?
>
> Gnome works pretty much the same way as KDE we have modules, so the do,
> you can just remove/disable and Gnome will run without it, but why remove
> a cool feature? It's non sense, it's obvious that every distro would push
> because they want the missing feature, if Oyranos was there first maybe
> colord didn't had to exist.
Maybe, maybe not.
> >I have never used PackageKit and said nothing about it. Are you talking
> >about PakcageKit or colord here? Users can help with patches from time to
> >time, that is important, and I was only a Knetworkmanager user before I
> >started to contribute. Your statement is completely wrong in an
> >opensource world.
>
> You don't get it, I'm giving an example of how good projects dies because
> from a technical point of view they become unmaintainable.
> Sure, pretty much everyone is first an user then a developer but this
> doesn't mean you can expect from users of a software to maintain that,
> otherwise most of these projects wouldn't go into an end.
You mean the oppositte in the last sentense, right? I still disagree, users can do a lot to help maintaining a software, that's called community. For extremelly technical parts there will be less users able to help, but still if you are not a user of the software why would you bother to help maintaining it? Sure the most experient users take the technical decisions, that is what we are do here in k-c-d for KDE for example.
Daniel Nicoletti
> which is connected to the device. That fits to what Michael Sweet says about
> early versus late colour binding, suggesting that early colour binding can cause
> gigabytes of traffic, while late colour bind will have no such issue.
Kai you keep saying that Michael Sweet don't want colord upstream,
how do I find just the opposite?
http://lists.freedesktop.org/archives/openicc/2012q1/004489.html
He even mentions that to add Oyranos that means loads of code...
Kai-Uwe Behrmann
> On Wednesday, March 14, 2012 14:22:54 Sune Vuorela wrote:
>> I would really prefer to at least have one common gui. preferably just
>> one stack. But if we have to have two competing stacks until one of them
>> dies, then I guess we will just have to live with it. But do it with a
>> common gui. pretty please.
>
> I agree that whatever we do there should be only one main KDE GUI to an
> underlying color management system (CMS).
>
> Going off-topic to discuss the thread in general, I have some thoughts on the
> matter:
>
> First off, I'm quite sympathetic to the plight of the Oyranos devs. Much like
> KDE, they have tried to make a user-customizable, modular, extensible,
> feature-complete system with efforts made at cross-platform functionality,
> standards development and compliance, and feature implementation in a "as
> correct as possible" fashion.
>
> The problem is that the software is /like/ KDE but doesn't use any KDE
> technologies. To best utilize a given subsystem we would typically use at
> least a light abstraction layer, using Oyranos (at this stage) entails a KDE
> abstraction layer on top of a KDE-like abstraction layer (unless KDE apps code
> to Oyranos directly, which I don't see as likely in general). This API
> impedance mismatch is undesirable for much the same reasons that we don't
> typically code to glib or gobject APIs.
Do you suggest a KDE wrapper for Oyranos objects and functions?
> Additionally I don't see any good reason to /not/ support colord. Ignoring the
> other parallel about KDE-like software being reimplemented by a glib-based
> "simpler application", the fact is that colord is widely distributed on Linux
> and can (AFAICT) be driven over a fairly simple DBus API. If KDE is going to
> support CMS at all there's no reason not to support that if it's present and
> installed.
>
> However this by itself doesn't mean KDE necessarily shouldn't or can't support
> Oyranos. There's a few major points which I think if can be answered would
> help clarify what that would look like:
>
> * What feature(s) does Oyranos support over and above colord? I think we're
> all in agreement that Oyranos does /more/, but what specifically does that
> mean?
I hope to have adressed that already from my side.
http://lists.kde.org/?l=kde-core-devel&m=133180205024971&w=2
> * What of those extra features are "a big deal" for a desktop environment
> (i.e. would specifically would we *not* be providing our users by supporting
> colord and not supporting Oyranos).
>
> If these extra features are things that are ONLY "professional grade" then it
> may make more sense to have Oyranos configuration be an e.g.
> extragear/graphics type of thing that software like Digikam and Krita could
> use and/or depend on.
>
> On the other hand if there are things that a mere 'power user' might find
> useful (that colord will not be supporting due to scope) then it might make
> sense to have extra U/I if Oyranos is available. Perhaps multi-monitor CMS
> would fit the bill (assuming colord will not support).
>
> * Finally, assuming no direct support for Oyranos in a KCM, what would be
> needed to allow a user to use Oyranos in a KDE Desktop? E.g. let's assume that
> colord is always available on Ubuntu and so KDE can interact with it, but the
> user wants to use Oyranos... what does KDE have to do to allow the user to
> manually control their color profiles without a KDE daemon interfering?
Oyranos makes sense to user, who have no idea that colour management
exists. So they have no idea that it would be good for them.
> Regards,
> - Michael Pyne
kind regards
Kai-Uwe
--
Kai-Uwe Behrmann
www.oyranos.org
Kai-Uwe Behrmann
> Maybe, that is something that needs to be discussed with oyranos'
> community. By what I read in this thread elektra is still maintained and is
> optional, not sure about fltk.
FLTK is optional. The core library is toolkit independent and builds fine
without GUI code. However there is some example code using FLTK, Qt and
Cairo.
kind regards
Kai-Uwe
Kai-Uwe Behrmann
>> On Wednesday, March 14, 2012 14:22:54 Sune Vuorela wrote:
>> There's a few major points which I think if can be answered would
>> help clarify what that would look like:
> Indeed, this discussion is going places, but does not really come up with
> answers. As someone who has no understanding of colour managemant
> whatsoever
> and without any bias, I, indeed, see some questions to be answered, in the
> hope this will provide us with some structure.
>
> * First of all, how expensive would it be to provide a small abstraction
> allowing drop-in replacement of Oyranos by colord and the other way
> around, e.g. have one interface and two backends?
For device configuration a decission would have to be made to eiher
simplify and thus cripple Oyranos or to extent colord for a common API
wrapper.
Profile lookup would be pretty simple. Many settings could be shared, but
do not completely overlap. I do not know about caching in colord.
A colour conversion CMM wrapper API is only in Oyranos available. So you
would have to recode that completely of you want complete independence
from. All modern platforms, except Linux, support now multi monitor
colour correction in their basic image viewers. You might loose
partitially the ability to support that.
For cross platform support, KDE would need code rewritten for each
platform. This includes nearly all non pure ICC components, like profile
paths, settings, device backends and so on.
> * If the platforms supported by the backend are different from the
> platforms targetted by KDE, how do we cope on these other targets? Should
> we answer question one with: indeed one interface, however, four backends
> -- given whatever Windows, MacOSX, or whatever platform you like and KDE
> targets uses.
>
>> * What of those extra features are "a big deal" for a desktop environment
>> (i.e. would specifically would we *not* be providing our users by
>> supporting
>> colord and not supporting Oyranos).
>>
> * Maybe reformulated to: What are the target audiences of the
> applications? If one is more aimed at the default user and another at
> certain professionals this calls for a different view at the situation. As
It is not that a strong division. Oyranos at least supports both mentioned
user groups.
> some people tend to say: one size does not always fits all.
> Furthermore, I expect that there should be some communication between the
> goals of KDE and those of the solution we prefer.
I be here around.
>> * What feature(s) does Oyranos support over and above colord? I think
>> we're
>> all in agreement that Oyranos does /more/, but what specifically does that
>> mean?
>>
> * A feature-wise comparison, although that quite easily gives a false
> impression. For example, a product may have way more features, but because
> of some fundamental design decisions we do not like, or the other way
> around, something may be over simplified. Thus, such a comparison requires
> real expertise and no bias.
> It would probably be best if the developers explained what makes there
> software great and not so much what makes other software less worthy.
agreed. Again my link inside this thread to do so.
http://lists.kde.org/?l=kde-core-devel&m=133180205024971&w=2
>> * Finally, assuming no direct support for Oyranos in a KCM, what would be
>> needed to allow a user to use Oyranos in a KDE Desktop? E.g. let's assume
>> that
>> colord is always available on Ubuntu and so KDE can interact with it, but
>> the
>> user wants to use Oyranos... what does KDE have to do to allow the user to
>> manually control their color profiles without a KDE daemon interfering?
>>
> * Maybe this should be asked for all possible solutions? Also, given the
> fact that there are people working or willing to work on KDE integration
> of both, this hould not be too much of a problem, I would guess.
>
> As a final remark, please note that the diversity in the open source world
> in general and the Linux world specific is, most of the time, considered a
> good thing. Competing projects are generally responsible for more
> innovation than monopolies.
> If we can embrace this, it would be wonderful.
>
kind regards
Kai-Uwe Behrmann
>>> corrected!
Am 15.03.12, 04:11 -0700 schrieb Daniel Nicoletti:
>> So far colour conversion happens on the end machine. That is the one,
>
>> which is connected to the device. That fits to what Michael Sweet says about
>> early versus late colour binding, suggesting that early colour binding can cause
>> gigabytes of traffic, while late colour bind will have no such issue.
>
> Kai you keep saying that Michael Sweet don't want colord upstream,
Do you mean me? If so I did not write such a statement. I refered to your
abouve first sentence, which is now recovered.
> how do I find just the opposite?
No idea how you get these two different things together. Maybe you think
early colour binding is related to linking of code? Then no it is not
related. Early colour binding means simply to do colour conversion early
in the data flow, and that means on the local host, inside the application.
> http://lists.freedesktop.org/archives/openicc/2012q1/004489.html
>
>
> He even mentions that to add Oyranos that means loads of code...
Regardless of oversimplified or "non-trivial amounts of code", I still
do not think that this would be a good route to follow. I fear a big
maintainance effort for that scheme.
kind regards
Kai-Uwe
Thomas Zander
> I said I wanted the most versatile, which means one that satisfies
The requirement for 'most versatile' doesn't follow in that sentence.
You are making a logic error, or at least taking the biggest car and
hoping it will get you there fastest.
If you want to satisfy your needs, try it for a while and see if it works.
> You are completey ignoring the fact
> that there are people using oyranos too, it has been developed for years,
> do you think it's fair to drop all that work now?
Hmm, you pose lots of questions that are completely off-topic here.
And jumping to weird conclusions about dropping work is just unhelpful.
> I am in favor of adding
> support to both colord and oyranos in kdegraphics.
I strongly disagree with that.
KDE is not a support group where lonely software goes to get more
recognition. This community works based on choosing solutions that
work best. Your suggestion to not choose is therefore not helpful.
> And no, I have not tested either of them
Then I'm sorry to say, your opinion is just that, one uninformed opinion.
At minimum read this;
http://www.freedesktop.org/software/colord/intro.html
And tell us if there is any reason to say that this product does *not*
satisfy your needs (when the KDE stuff is finished)
> nobody is an expert in color
> managament to judge the merits of either project
There are not a lot of experts on the topic, no. I've been doing my
first physical monitor and scanner calibration back in 1999, on the
Mac. (with a Barco monitor). I've been reading many (beautifyl) books
and I'm nowhere near an expert at all.
From a software engineer point of view there is a good solution; as
I *do* have the basic information needed, and thats easy to get to for
everyone else as well. Read the above linked page, for instance.
Basic design of system color management is that each input (scanner
etc) and each output (monitor, printer) has to have assigned a
personal color profile.
Applications that are capable of doing color management have to have
access to those profiles so they can use them in combination with a
library like lcms to do the right thing.
Colord embraces that concept and provides all we need.
Oyranos makes things ... complicated. See;
http://www.oyranos.org/doc_alpha/index.html
--
Thomas Zander
Kai-Uwe Behrmann
> Basic design of system color management is that each input (scanner etc) and
> each output (monitor, printer) has to have assigned a personal color profile.
That is not as simple as that. You must include the driver, the colour
related driver settings and maybe more identification informations from
the device itself like the EDID. E.g. Modern monitors can emulate colour
spaces, that would be written in the EDID. A simple one device to one
profile is over simplified and ambiguous at best.
> Applications that are capable of doing color management have to have access
> to those profiles so they can use them in combination with a library like
> lcms to do the right thing.
... and do caching, lookup, perhaps wrapping of CMMs and so one. Would it
not be nice to share that?
> Colord embraces that concept and provides all we need.
>
> Oyranos makes things ... complicated. See;
> http://www.oyranos.org/doc_alpha/index.html
That is a apple against orange page comparision. But hey, here is a
better link:
http://www.oyranos.org/features/
> --
> Thomas Zander
glad to help,
Daniel Nicoletti
> ... and do caching, lookup, perhaps wrapping of CMMs and so one. Would it
> not be nice to share that?
overhead at best and a complex solution at worst.
> That is a apple against orange page comparision. But hey, here is a
> better link:
> http://www.oyranos.org/features/
You're just trying to create yet another CMS, we already have excelent ones
lcms, AngryCMS why a third?
Lamarque V. Souza
Em Thursday 15 March 2012, Thomas Zander escreveu:
> On Wednesday 14 March 2012 20.31.30 Lamarque V. Souza wrote:
> > I said I wanted the most versatile, which means one that
> > satisfies
> >
> > my needs and somebody else's needs.
>
> The requirement for 'most versatile' doesn't follow in that sentence.
> You are making a logic error, or at least taking the biggest car and
> hoping it will get you there fastest.
No, I choose a car that carries my and my family's luggage in a reasonable speed. Most of the time I can drive alone, but it is still usefull to have a reasonable sized trunk to carry something for me or someone of my family. Or do you think I should always buy a moto and never a car just because I prefer driving fast?
> If you want to satisfy your needs, try it for a while and see if it works.
>
> > You are completey ignoring the fact
> > that there are people using oyranos too, it has been developed for years,
> > do you think it's fair to drop all that work now?
>
> Hmm, you pose lots of questions that are completely off-topic here.
> And jumping to weird conclusions about dropping work is just unhelpful.
I think dropping work must be carefully decided, if nobody uses the code so drop it. I am ready to drop Kopete once telepathy-kde fullfills my needs and I have already dropped features from Plasma NM that nobody used. If there are people using oyranos I think that must be taking into account.
> > I am in favor of adding
> > support to both colord and oyranos in kdegraphics.
>
> I strongly disagree with that.
> KDE is not a support group where lonely software goes to get more
> recognition. This community works based on choosing solutions that
> work best. Your suggestion to not choose is therefore not helpful.
That was not my suggestion, somebody else suggested that in #kde-devel and I agree because I think that fullfills the needs of most KDE users.
> > And no, I have not tested either of them
>
> Then I'm sorry to say, your opinion is just that, one uninformed opinion.
Like everybody else's opinion in this thread.
> At minimum read this;
> http://www.freedesktop.org/software/colord/intro.html
> And tell us if there is any reason to say that this product does *not*
> satisfy your needs (when the KDE stuff is finished)
I do not have a need for color management nowadays, which does not mean I cannot help fullfill somebody else's needs. I do not always do things for myself only.
> Basic design of system color management is that each input (scanner
> etc) and each output (monitor, printer) has to have assigned a
> personal color profile.
> Applications that are capable of doing color management have to have
> access to those profiles so they can use them in combination with a
> library like lcms to do the right thing.
How that is different from oyranos?
> Colord embraces that concept and provides all we need.
>
> Oyranos makes things ... complicated. See;
> http://www.oyranos.org/doc_alpha/index.html
By reading the front page of both web pages I cannot judge which one is more complicated. I do not have time to read all pages in both projects now too.
Alex Fiestas
We don't need to choose right now, colord-kde just started and Oyranos is just
starting to make noise thanks to KColorManager, where is the hurry to choose a
side? it seems to me that some people are using this "fight" to win a battle
in the "Middleware war" which some people think that is going on. Please stop
that or open a new thread to discuss that.
In my humble opinion we should just wait and see what of them last longer and
healthier.
Also, I'm not an expert but if we could share interface I would love that, is
it possible?
Finally, is there any possibility of making an abstraction that allows our
applications to use color management in all platforms?
Thanks and sorry if I say soemthign already replied, long threads are long :p
Alexander Neundorf
...
> In my humble opinion we should just wait and see what of them last longer
> and healthier.
+1
Alex
Matthias Klumpp
new situation. (or rediscuss the old one if nothing has changed, but I
don't believe that nothing changes ^^)
Cheers,
Matthias
Kai-Uwe Behrmann
> 2012/3/15 Kai-Uwe Behrmann <ku...@gmx.de>:
>> ... and do caching, lookup, perhaps wrapping of CMMs and so one. Would it
>> not be nice to share that?
> Really caching of so small files? If you cache small files you have an unneeded
> overhead at best and a complex solution at worst.
Transforms are expensive, so caching makes sense. Parsing of ICC profiles
in larger numbers is expensive too.
>> That is a apple against orange page comparision. But hey, here is a
>> better link:
>> http://www.oyranos.org/features/
> You're just trying to create yet another CMS, we already have excelent ones
> lcms, AngryCMS why a third?
Oyranos is a wrapper for CMM's. That way it wrappes the lcms ICC colour
conversion engine. It could wrap ArgyllCMS's ICC colour conversion engine
as a CMM too.
Oyranos does not do colour colorimetric stuff. It links to a CMM to do
that.
kind regards
Kai-Uwe
Michael Pyne
> Am 14.03.12, 22:15 -0400 schrieb Michael Pyne:
> > technologies. To best utilize a given subsystem we would typically use at
> > least a light abstraction layer, using Oyranos (at this stage) entails a
> > KDE abstraction layer on top of a KDE-like abstraction layer (unless KDE
> > apps code to Oyranos directly, which I don't see as likely in general).
> > This API impedance mismatch is undesirable for much the same reasons that
> > we don't typically code to glib or gobject APIs.
>
> Do you suggest a KDE wrapper for Oyranos objects and functions?
Well, I suggest that if KDE is to support color management at essentially any
level deeper than just providing a UI to e.g. select a color profile for a
display and printer, that it would be done with a KDE-style API, that could
wrap Oyranos, or could wrap any other feasible implementation. Something like
Phonon or Solid.
> I hope to have adressed that already from my side.
> http://lists.kde.org/?l=kde-core-devel&m=133180205024971&w=2
Thanks for the link straight to the relevant email. :)
> Oyranos makes sense to user, who have no idea that colour management
> exists. So they have no idea that it would be good for them.
Well your link says that Oyranos "just works", and your statement here seems
to suggest that Oyranos does this without much (if any) user intervention.
Given all the other features supported by Oyranos I have to assume that this
requires at least some support from the application and/or toolkit level, no?
Keeping that in mind it would seem that to get the full benefit of Oyranos
that there would need to be deeper integration work than just adding
KolorManager (which I understand is separate from this thread's topic).
Returning to the topic at-hand, I will say (and this is just my opinion) that
I think this application would be best suited for extragear/graphics when it
moves out of playground, based on the low level of integration (both with
KDE's desktop and the other toolkit/infra work needed). If/when color
management becomes more supported in Qt and KDE then it would make more sense
to have CMS configuration in kdegraphics for the available CMS system(s). But
until then having this in kdegraphics without support from skanlite, Qt, our
printing layer, etc. really seems to promise more than a KDE desktop can
deliver right now. Even if it were to be in kdegraphics it should be an
optional build item (dependent on whether oyranos is available or not).
Like I said, that's just my opinion... I'm neither involved in kdegraphics
development nor the kdegraphics module maintainer.
Regards,
- Michael Pyne
Kai-Uwe Behrmann
Oyranos has a tool to do multi monitor ICC setup
with nvidia propriarity drivers. It works as well
without XRandR. Some projects do multi monitor
colour correction using Oyranos this way.
kind regards
Kai-Uwe
John Layt
> Hi!
> Colord - just to mention that - is also not a GNOME project, it's a
> FreeDesktop project. (Doesn't mean it's "standard", but does mean that
> it's not GNOME) So everyone is free to contribute to it, and the
> maintainer is interested in collaborating with KDE. (which he already
> does very nicely)
There is no such thing as a FreeDesktop project. FreeDesktop sets standards
like desktop files, it doesn't build or choose implementations. Just because
a project chooses to use fdo facilities does not mean it has been chosen or
blessed by fdo. There is no process for fdo to do such a thing. It is a
failing of fdo that it doesn't do so, and that it doesn't stop people form
claiming to be fdo projects when they are not. /rant
What colord is is a Red Hat project, or more exactly a Richard Hughes project
that Red Hat has allowed him to work on and Gnome has chosen to use.
John.
John Layt
> > Request:
> >
> > After working on KolorManager and Oyranos in the past months for the last
> > Oyranos-0.4.0 release, we feel the stack is ready to review for inclusion
> > into KDE.
> > KolorManager resides currently in Playground/Graphics:
> > http://quickgit.kde.org/?p=kolor-manager.git&a=summary
>
> Just a quick question, currently we have two CMS stacks, colord and
> oyranos, while
> I have nothing against having two of them in KDE, I wonder if this would
> become a problem for colord-kde [1] to enter in kdegraphics too? In that
> case would be better
> to both go to kdeextragear or is there some different policy in this case?
>
> I'm actually targeting KDE SC 4.9 as gnome-color-manager is very mature and
> I am pretty much just rewriting it with Qt/KDE libs.
Here's my pragmatic take on it, without judging the merits of either project
or their champions, and not knowing what the implications for application
developers are.
At the moment I believe we are only talking about KCM Modules to configure
sub-systems external to KDE. There is no code I'm aware of in kdelibs, kde-
runtime, or kde-workspace that actually implements anything colour management
related. As such any KCM module to configure such a system belongs in
extragear for now. When a distro chooses one or other of the competing
systems for their distro then they can package the appropriate KCM for that
system.
If the time comes when one or other system is integrated directly into one of
our core modules or applications and requires to be configured, then that is
the time for that KCM to move into the appropriate main module.
John.
Matthias Klumpp
From fd.o:
> freedesktop.org is not a formal standards organization, though some see a need for one that covers some of the areas we are working on.
> [...]
> Unlike a standards organization, freedesktop.org is a "collaboration zone" where ideas and code are tossed around, and de facto specifications are encouraged.
If you consider this, it's perfectly sane to call stuff which is
hosted on fd.o and uses fd.o namespaces (e.g. on DBus) is a
Freedesktop-project. You also need to apply for a new project first
and fd.o admins can reject it. Anyway, this doesn't mean
Freedeskop-Projects are standard, it just means that they're on a
public "collaboration-place" between desktops like KDE and GNOME. But
telling it a Richard Hughes project is describing it well too :)
Kind regards,
Matthias
Alex Fiestas
> Here's my pragmatic take on it, without judging the merits of either project
> or their champions, and not knowing what the implications for application
> developers are.
>
> At the moment I believe we are only talking about KCM Modules to configure
> sub-systems external to KDE. There is no code I'm aware of in kdelibs, kde-
> runtime, or kde-workspace that actually implements anything colour
> management related. As such any KCM module to configure such a system
> belongs in extragear for now. When a distro chooses one or other of the
> competing systems for their distro then they can package the appropriate
> KCM for that system.
> If the time comes when one or other system is integrated directly into one
> of our core modules or applications and requires to be configured, then
> that is the time for that KCM to move into the appropriate main module.
If they both stay alive and healthy then we may want to abstract the
abstracted alrady asbtracted so our applications only have to care about that
abstraction instead of caring about colord/oryanos/windows/mac
Abstraction++ (if possible :p)
Kevin Krammer
> And btw. colord is a XDG project, not a GNOME project. Yes, it was
> started by a GNOME developer, but this doesn't make it a GNOME
> project. It is developed independent from GNOME.
Being a freedesktop.org project in the sense of being hosted at
freedesktop.org does not add any value to this discussion. It is only hosted
there because it is lead by GNOME developers with enought connections to fdo
admins got a repository approved.
A project originating at KDE would not have been able to do that no matter how
independently developed it would have been.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
Kai-Uwe Behrmann
In Oyranos users need few care about cross platform support. If extra bits
are needed, these would certainly be welcome inside upstream Oyranos CMS.
kind regards
Kai-Uwe