Re: Color Management in KDE
Am 02.02.2013 22:33, schrieb Daniel Nicoletti: 2013/2/2 Kai-Uwe Behrmann : I am not so sure that will help. colord follows a minimalistic approach as is typical to GNOME. At the moment Oyranos supports quite more features. In regards to colord we gave up our requests to see certain features added and maintained. We wanted some policies considerd for ICC shared profiles, which is a essential part for Oyranos. But these whishes where completely ignored. We try to work around things and hope to cooperate better based on specs. Who wrote the specs? You did right? So what about providing good use cases and not complex features that will just make the code more likely to have bugs and less likely to get used by real people. We are always open to new features when they do provide a good use case. Oyranos is based in many aspects on community driven spec from OpenICC. I have the impression you did not read the OpenICC wiki pages, the specs or email list. That's probably a problem for a person, who wants to maintain a CM stack inside KDE. You completely depend on one API and the word of one person without good own reasoning. That's all you offer KDE. colord -- * Linux only, CMF only * Not a CMM, leaves that to toolkit, app or window manager * libcolord gobject C library, LGPL 2.1 * Config stored in DConf * DBus service & api for all options * Command line tool for all options * Intergrated into GTK, CUPS, SANE, etc. SANE-backends-1.0 (e.g. libsane.so) has no dependency to DBus or colord. Each colord client, which likes to support SANE has to implement that by its own. colord has no device specific code inside. ldd shows that easily on Linux. colord doesn't need to have device specific code, since it only provides a mean to match device <-> ICC, Coding device specifics in each client makes detection of driver settings more error proune, as is it is a not simple and is a repeating and to be continued task. Oyranos --- * CMF and CMM abstraction API * Linux and BSD support using own CMF implementation * OS X native ColorSync CMF support * Plans for Windows CMF support * CMM api only supports lcms/lcms2, plans to re-write to support more CMM's * C library, BSD license * No DBus service * Command line tools for certain options * No integration into CUPS, GTK, SANE, etc. * Not fully stable api yet * Must be hard build time dependency Every CLI tool can be called at runtime especially easy on Posix systems. That is not much different than DBus. So it would in theory be possible to use Argyll/Oyranos or colord in exchange without hard linking. I guess the amount of code might be similar like supporting all those different DBus APIs + support code. Using command line tools is actually extremely hard/boring if you need to keep parsing it's output, QtDBus brings you all the convenience of SIGNALS and SLOTS and is async as well. In KolorManager we do it *with* SIGNAL + SLOT for asynchronous tasks. No problem. Let me add an advantage. Argyll and Oyranos have the needed device dependent code already inside. No need to fiddle with EDID, X11, CUPS and other API's. Since the work is so small I don't really see such advantage... The concept in colord is to use a device ID, which is a actificial name. That one might have nothing to do with actual colour behaviour and thus is eigther only particial useable for profile association or inflexible. What appears small work to you results from the omitting of real world use cases. In some ways Oyranos could be seen as an alternative to Qt in providing a common abstraction api across the major platforms, except it is in C, not yet on Windows, and requires explicit CMM code rather than having it implicit in the Qt graphics classes. The last half sentence makes no sense to me. First of all. lcms is the most highly valued CMM on the planet right after the AdobeCMM. It's portability is simply amazing. CMM code is dlopen'd in Oyranos on demand. E.g. KolorManager will never link against or call lcms. On the opposite, a ldd to libcolord.so shows a hard dependency to liblcms2.so . Qt graphics classes are dependent to any CMM in what way? Are Qt apps free to choose a CMM if Qt graphics classes have already choosen one? There is no color correction in Qt yet, dlopening a library is actually a much worse practice than linking against it, if lcms change their API you won't notice at compile time and might give nice crashes with odd backtraces. I did not write what you imply. Your blindly jump to hostile assumptions about a project you appearently did not care to look much into. The Oyranos CMM wrapper modules in question link against lcms, but the modules themself are dlopend like any normal plugin system does. I did not even hear about that service. Even though I am one of two persons, who had worked on specs for a shared CMS DB on Linux. The other person is Graeme G
Re: Color Management in KDE
nos and optionally Windows and OS X, so apps are independent of whichever is available and protected from API instability. A default sRGB plugin could be used when neither are installed. This would make the eventual Qt5 migration easier, and maybe influence the Qt5 api. Let me outline point 4) and what I expect that to become: colord is mostly a small API for DB queries. The DB itself is otherwise hidden. The outlined project will need many own code to implement the basic device and driver configuration detection. Or it can choose to ignore aspects leading to a poor implementation. As soon as one has written all the needed code for KDE or Qt it needs to be continued for each other supported platform. Thats the logic. In the end it means parts of Oyranos or GCM get rewritten in a Qt specific style. All remaining Linux DE's have to rewrite everything by themself too. The actual Gnome CM (colord) way makes a massive repeat of code necessary. IMO that is a waste of programmers energy. Because KDE/Qt will for sure not provide a shared API suitable for any Gtk/EFL or other DE project out there. In my expectation the benefit for KDE will likely be relative small, because it can not much cooperate with other projects this way. Let me add: 5) KDE implements a own CMS based on available standards and specs. That way it is completely independent, while remaining compatible with existing CMS on many levels. It takes away ambiguity and a clean Qt style is straight forward possible. It takes many disadvantages from 4) but on the positives is a kind of clean room implementation. Certainly it demands lots of work, but maybe not much more or even less than 4). Obviously my recommendation is for option 4 to be implemented for KDE 4.11. This could be based on the existing Calligra API. I'm not sure how much time I'll have to work on this myself, but it seems to me less work for apps to work on this together instead of each one re-implementing the same code. Let me be clear though, if an app wishes to use Oyranos directly as a hard requirement because of some better functionality or less code then they are free to do so, but it does come at a cost that they need to be aware of, a cost which I don't think belongs in kdelibs or Workspace. Hmm, reads like a plan to abstract from the Oyranos abstraction API. Maybe a graphics scheme could help in making that idea better understandable? Thoughts? John. kind regards Kai-Uwe Behrmann -- www.oyranos.org
Re: Color Management in KDE
On 22.01.2013 17:50, Cristian Tibirna wrote: > On Monday 21 January 2013 21:22:42 John Layt wrote: >> My big concern is that KDE is sleep-walking into a hodge-podge >> solution with little co-ordination on implementations and dependencies, and >> little knowledge of the implications of the decisions being made. I've >> tried to come up with a logical pragmatic solution within the usual KDE >> standards and architecture, but I am not a CM expert so if you feel that >> I've got anything wrong or misunderstood the situation please don't >> hesitate to call me on it. > I guess I understand that a very color-conscient application (like, say, > krita), will need to correctly support CM internally, particularly if the app > is used outside an integrated KDE session. But then, is there conflict when > both the application and the wm try to manage color? > > - you mention a few hypothetical developments (especially in relation with > Qt5). Do you have direct information on the plans? Or, in other words, what > is > the perceived probability that your future-projections could be defeated by > predictible developer-opinion/development-direction changes? > > Thanks a lot. A infection hit me. So, I am not able to check things and answer much for some days. kind regards Kai-Uwe -- www.oyranos.org
ANNOUNCE OpenICC @ GSoC 2012 results
We gladly announce, that OpenICC's participation was this year a great success. All projects finished. Links to them can be found on the OpenICC Google Summer of Code 2012 web page [1]. Colour Management for Krita Printing Joseph Simon worked on adaption and integration of his last years implementation for colour managed printing into Krita. The workflow is based on ICC profile injection through the PDF OutputIntent. KWin Colour Correction Casian Andrei's KWin changes for ICC style colour correction in the GPU are discussed upstream and his code to KolorManager code base wait just for approval. The concept follows the X Color Management and CompICC implementation. But the result is highly modular and thus very flexible. Simple Toolkit Abstraction Nitin Chadas SimpleUI project for XML forms rendering was written from ground up and provides now backends for FLTK, Gtk and Qt. It needs a bit of polishing to become useable. Thanks to Google for providing the colour management and graphics community again a great chance to code and learn the open source way. kind regards Kai-Uwe Behrmann -- GSoC admin @ OpenICC.info [1] http://www.freedesktop.org/wiki/OpenIcc/GoogleSoC2012 PS: interessted in a similar project outside GSoC, then just get in contact with me
[Announce] Linux Color Management Hackfest 2012
During the recent LGM[1] we started to organise a hackfest[2]. The event aims at bringing developers of the Linux applications and desktops and experts interested in color management (CM) together and support the integration of CM inside their open source projects and distributions. The hackfest will happen from 16th until 19th November 2012 in Brno, Czech Republic. The Red Hat offices[3] are kindly offered during the event and be well equipped for our purpose. We spotted three main focuses: * desktop applications, including window managers, * web browsers and * printing. These topics are already worked on, but in a scattered way. By meeting in person in one place, we want to get something done and build a good understanding of the role of each participating group for a working end to end color management. If you are interested in joining the hackfest, please fill your name and information on the OpenICC wiki page [4] to help us estimate resources. In case you need a visa, please write us preferedly soon as mail can take a while. Submission deadline for obtaining sponsoring will be 30th of September. regards, Kai-Uwe Behrmann -- organisation for openicc.info [1] http://www.oyranos.org/2012/05/linux-color-management-hackfest-idea/ [2] http://en.wikipedia.org/wiki/Hackfest [3] http://g.co/maps/taqng [4] http://www.freedesktop.org/wiki/OpenIcc/Events/Hackfest/2012
Re: Review Request: include KolorManager in kdegraphics
The KolorManager project has been moved to extragear/graphics . Thanks to all who helped with that. kind regards Kai-Uwe Behrmann -- www.oyranos.org
Re: Review Request: include KolorManager in kdegraphics
Am 14.03.12, 11:26 +0100 schrieb Kai-Uwe Behrmann: Request ID: 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. Given the recent discussions in this thread, there is not something fundamentally technical to change inside KolorManager. Many have expressed the opinion to move it not into kdegraphics ATM and use kdeextragear instead. As most applications on Linux use the Xorg atoms to do ICC monitor compensation, a KolorManager to setup device profiles might help them already. Can we proceed with the move into extragear? thanks in advance Kai-Uwe Behrmann -- www.oyranos.org
Re: Re: Re: [GSoC] KWin colour management
Am 23.03.12, 17:10 +0100 schrieb Thomas Lübking: Am 23.03.2012, 06:27 Uhr, schrieb Kai-Uwe Behrmann : Where would be a competing system on Linux? Well, I certainly did not read all of that "colord ./. oyranos" flamewar on k-c-d where supporters of either basically tagged the other like incapable and/or irrelevant s..tufff, but I as certain did not dream about it. So while this might just have been kindergarten s...tuff about "xyz uses mono and we hate mono", I was under the impression that those were conflicting approaches to CM. That was likely related to Linux CM DB APIs, but not particular to compositor CM. If it indeed only is about implementation details on the very same protocol, Yes, we have seen no other descriptions for a compositor CM protocol. thus whether colord or oyranos is in use does absolutely not make any difference regarding the compositor, I wish apologize and withdraw that particular concern. screen actually could do WG ... but the delete icon in dolphin looks correct? That is correctly described and expected behaviour as developers said. Ok, so let me please complete my former question by its implications: "Does that actually mean that if I have a WG screen and an application which does not support the opt-out protocol [...], it will be reduced to sRGB while the application and the screen actually could do WG ..." ... unless I suspend compositing or switch to another window manager what, because I'm just a user and don't know what a window manager is, likely means to switch to another DE, because "it just works" on - let's say - "Trinity"? sRGB displaying is for many people the "it just works". They likely will find sRGB be more relaxing, if they have a wide gamut display. Look at the email threads, where people search for the sRGB emulation mode for these kind of monitors. We discussed that with Wayland people and the last spec revision was adapted to meet their concerns. So the transition from X Color Management to W(ayland) Color Management should be relativele smooth. http://lists.freedesktop.org/archives/openicc/2012q1/004595.html http://www.oyranos.org/2012/02/x-color-management-0-4-draft1 Many thanks. But that seams clearly away from per-region opt-out but into per-window correct opt-out, doesn't cover different screens anyway and require toolkits "to For different screens can be colour corrected through X Color Management, because the output device spaces are known. "toolkit" means client side. A client can as well be a application. colour correct the whole window" what -if did not terribly misunderstood- It is about specifying a per window opt-out or per window source colour space. A compositor can still apply different per monitor colour conversions. also means that if Qt & Gtk+ support such, but TCL/TK does not (just examples here), the result would be that w/ or w/o a color correcting compositor, my Qt & Gtk apps just work fine whereas my very important professional offset print preview "POPP" (tm) tool written in TCL/TK only works WITHOUT such compositor (because the canvas is corrected internally and the buttons are all gray anyway) and fails with one. Your "POPP" (tm) tool written in TCL/TK will hopefull adhere to the ICC Profiles in X spec[1]. Otherwise it's behaviour is undefined. Such bug is present in Gimp, when the "Use system profile" check box is initially not selected. Gimp behaves correctly after enabling this option. kind regards -- Kai-Uwe Behrmann www.oyranos.org [1] http://www.freedesktop.org/wiki/Specifications/icc_profiles_in_x_spec
Re: Re: Re: [GSoC] KWin colour management
Am 22.03.12, 22:49 +0100 schrieb Thomas Lübking: Am 22.03.2012, 19:20 Uhr, schrieb Kai-Uwe Behrmann : I was tould by the graphics community to keep the X Color Management spec backward compatible with the ICC Profile in X spec, so we did. Thus old style applications see a sRGB profile through the ICC Profile in X spec, and they continue to work by converting to sRGB. Sorry again, but does that actually mean that if I have a WG screen and an application which does not support the opt-out protocol or bought into a competing* system, it will be reduced to sRGB while the application and the Where would be a competing system on Linux? screen actually could do WG ... but the delete icon in dolphin looks correct? That is correctly described and expected behaviour as developers said. Next question: do you have approached the Wayland project on this? In case, what do they say? We discussed that with Wayland people and the last spec revision was adapted to meet their concerns. So the transition from X Color Management to W(ayland) Color Management should be relativele smooth. http://lists.freedesktop.org/archives/openicc/2012q1/004595.html http://www.oyranos.org/2012/02/x-color-management-0-4-draft1 *semi OT sidenote: This is btw. sth. I do not like at all. Xorg and fdo do not have the market share -esp. in that market- to afford two competing color management systems. I have no idea about the technical, conceptual and maybe religious differences, but would suggest to iron that out by all means if you ever want usable CM on this Architecture. What other substantial proposals or discussions do you have in mind? As far as I can see there was no publically discussed *competing* concept of substance ever brought to the attention of the graphics community. We only have read some nebulous and non technical statements on the typical level of marketing. OpenICC [1] is the fd.o place to discuss such CM stuff or at least the Xorg email list. In both I am active. I will surely continue to present and discuss the idea with users and developers in various events. kind regards Kai-Uwe Behrmann -- www.oyranos.org [1] http://www.freedesktop.org/wiki/OpenIcc/Events/Fosdem/2012
Re: [GSoC] KWin colour management
Sorry I missed to answere you somehow. Am 21.03.12, 10:25 +0100 schrieb todd rme: On Wed, Mar 21, 2012 at 8:39 AM, Kai-Uwe Behrmann wrote: Am 20.03.12, 21:17 +0100 schrieb Thomas Lübking: Am 20.03.2012, 20:12 Uhr, schrieb Martin Graesslin : A fully color corrected compositor seems feasible to me I'm atm. not even sure about that. I might be utterly wrong, but my impression is that the xvidmode extension can correct screens (eg. xcalib loads icc profiles), so a screen wide color xvidmode gamma ramps are per channel curves. These are very limited compared to ICC based colour correction. Those gamma curves provide better gray balance and potentialy white point adjustment. But they do not describe colour primaries shifts or other more complex distortions. Gamma curves must be taken into account for ICC profiles. But detailed characterisation of device colorimetry happens usualy in ICC profiles. This may be an ignorant question, but can xvidmode be extended to offer more complex correction? That would end in a all desktop content is sRGB dituation. That would be fine as long as we know that wide gamut monitors are excluded, like on fixed hardware. Tablets could do that for their internal displays. But I am afraid a desktop, which cribbles all wide gamut monitors by default to sRGB, is suboptimal marketing. kind regards Kai-Uwe Behrmann -- www.oyranos.org
Re: Re: Re: [GSoC] KWin colour management
Am 22.03.12, 18:41 +0100 schrieb Thomas Lübking: Am 22.03.2012, 08:55 Uhr, schrieb Kai-Uwe Behrmann : Lets hypothetical assume some effort is initiated to bring CM to Qt and that happens during Qt 5 life time. The new design says by default all content is considered sRGB, which is by itself reasonable. However existing applications will initially not know about that changed convention. Errrmmm... how is that please different from opting out of the compositor? Except that latter does not only hit Qt applications but also *every* "legacy" stuff around? I was tould by the graphics community to keep the X Color Management spec backward compatible with the ICC Profile in X spec, so we did. Thus old style applications see a sRGB profile through the ICC Profile in X spec, and they continue to work by converting to sRGB. The conflict is solveable by making the new drawing API incompatible with the old one, e.g. requiring a colour space argument. Or by making user code color correction calls (QApplication::setColorSpec(int spec)?) invalidate/override library settings? Something like that is technical possible. But let me repeat, you get then a mixture of colour managed and non colour managed apps with the same toolkit, which is completely non understandable for users. kind regards Kai-Uwe Behrmann -- www.oyranos.org
Re: Re: Re: [GSoC] KWin colour management
Am 22.03.12, 07:34 +0100 schrieb Martin Gräßlin: On Thursday 22 March 2012 07:02:27 Kai-Uwe Behrmann wrote: Am 21.03.12, 20:34 +0100 schrieb Martin Gräßlin: Do you have any references showing that it is impossible to add color correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't base technical decisions on "my feeling says". That would mean colour management appears earliest inside Qt 6. But it is at the moment not clear if that happens at all. Any proof for these bold statements? Anything from Qt where I can see that this is the case (also for Wayland)? Remember nobody wants to develop for X anymore ;-) As we discuss a equivalent of colour management in KWin, we talk about default colour management of all displayed Qt widgets. That is a high goal and likely coming with some API changes. Such changes need quite some preparation. What signs are visible that with the first release of Qt 5 will have full CM? Even if people would put CM now high on the Qt develpers or similar agendas, CM will likely not get included soon to be ready for the first Qt 5 release. Then logically the next feature window is Qt 6. Sorry but I don't follow that logic. Just because it won't make it into 5.0 (which is impossible) does not mean that it won't enter any 5.x release. And that's what I asked for: is there any reference stating that it won't be possible to add CM to Qt in the lifetime of Qt 5? Here my thoughts, why I think CM in Qt is not easily introduced during a minor Qt 5 release. [Preparation of CM for Qt 6 is a different story.] Lets hypothetical assume some effort is initiated to bring CM to Qt and that happens during Qt 5 life time. The new design says by default all content is considered sRGB, which is by itself reasonable. However existing applications will initially not know about that changed convention. There is currently no API to know that. They will play freestyle as before and colour correct to monitor space without knowing how to tell anything to Qt. These old style apps will colour correct to monitor and Qt will colour correct from sRGB to monitor as Qt does not better know. That is called double colour correction and would be a real design bug. The conflict is solveable by making the new drawing API incompatible with the old one, e.g. requiring a colour space argument. An other way is verbally declaring sRGB as the default colour space in Qt, which would be a major API change as well and only reasonable possible during major version change. Both is not easy before Qt 5. After the fist Qt 5 release a new drawing API could theoretically be introduced in parallel to the old one. But old Qt apps would then look inconsistent compared to ones using the new API. Not sure if that transition path would be a good option regarding code complexity. IMO best would be to wait for Qt 6 and then switch completely. kind regards Kai-Uwe Behrmann -- www.oyranos.org
Re: [GSoC] KWin colour management
Am 21.03.12, 22:25 +0100 schrieb Thomas Zander: Color management in Qt is a bit of a weird statement; first of all, support is already possible as Krita proves. Second, I doubt that 94% of the widgets Krita does colour management inside Krita. IMO that does not belong to a discussion about Qt itself. actually need color correction of the type that kwin could provide. Who cares that their text edits and their buttons are color correct? Many people care about that and even more are positively affected. Its only for canvas-like widgets that this is relevant, and apps have that option already by linking to LCMS. It is relevant to the whole desktop experience. What people like to see are consistent colours on displays and then on prints. And they want to show the same colours to their friends remotely. At the moment KDE looks on each monitor different. No one can predict on what colours come over the internet, being it web sites, email clients or application toolbars. That's not so good. So, KWin support would just be a shortcut. A one-stop solution to make all apps suddenly get sunglasses on. It certainly is not a 'proper' solution, its a shortcut. So please keep treating it as such. Yes. There needs work on many layers. All have to play their role. And I see default colour management in KWin as a big step in a good direction. When people talk about the toolkit adding support its more about convenience APIs. Think a QPainter method to set a color transform to do correction on following draws. Such a API is specialy tailored to a certain audience. Photographers come to mind. And I am all for it, but they are only part of the KDE user base. When people want support in the toolkit, they want the color selector widget, the print preview widget etc, that come with Qt to natively use the monitor profile. Last, they want the printing to take color management into account. Good example. The print of a screenshot should look like on screen. So the first thing is to make screens look consistent. Then printing has a chance to match that. All of those are possible and likely even welcomed in Qt. The only thing is that someone has to actually do it. So saying that it won't happen in Qt6 is a self-fulfilling wish, and I feel its not very fair to plant that doubt in peoples minds. Agreed with you. And luckily no one says it can not happen for Qt 6. What would KWin people suggest how and where to place this feature near KWin? Well the question is whether such a feature is needed at all. I would say: * either correct the whole screen * or let the windows handle it Now it becomes quite simple: there's an app doing color correction itself. In that case we can safely assume that the user wants the app to take care - compositor does no longer color correct the screen. There is no application taking care of it: compositor renders the whole screen. That could be a start. kind regards Kai-Uwe Behrmann -- www.oyranos.org
Re: Re: [GSoC] KWin colour management
Am 21.03.12, 20:34 +0100 schrieb Martin Gräßlin: I think you do not know how KWin's rendering works. In a simplistic way: a window is rendered to the screen through a shader. At runtime KWin decides which shader to be used. As by that there is always only one active shader, so to have color correction it has to be added to all shaders which render windows/textures/colors. Thanks for the description. This is different to any experience you might have from Compiz 0.8. There the screen was not rendered with shaders but plugins could use shaders. Do you have any references showing that it is impossible to add color correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't base technical decisions on "my feeling says". That would mean colour management appears earliest inside Qt 6. But it is at the moment not clear if that happens at all. Any proof for these bold statements? Anything from Qt where I can see that this is the case (also for Wayland)? Remember nobody wants to develop for X anymore ;-) As we discuss a equivalent of colour management in KWin, we talk about default colour management of all displayed Qt widgets. That is a high goal and likely coming with some API changes. Such changes need quite some preparation. What signs are visible that with the first release of Qt 5 will have full CM? Even if people would put CM now high on the Qt develpers or similar agendas, CM will likely not get included soon to be ready for the first Qt 5 release. Then logically the next feature window is Qt 6. On the other hand, Xorg architect Jim Getty told me, that compositors are the right places for colour correction. that might be quite true, but not if apps want to opt-out. The X Color Management spec allows for opt-out inside compositors. I think to demonstrated you that on osC. and I think I explained to you why I don't think that's a good idea for KWin :-) kind regards Kai-Uwe
Re: [GSoC] KWin colour management
Am 21.03.12, 18:20 +0100 schrieb Martin Gräßlin: On Wednesday 21 March 2012 08:23:39 Kai-Uwe Behrmann wrote: There is more into it: first of all KWin currently does not distinguish between screens during rendering. To properly have screen aware color correction the complete compositor has to be made screen aware. The repaint loop has to be As a side note, during the last CLT fair there was the idea brought up, to place ICC colour correction inside a KWin plugin. Is that recommendable? I'm kind of confused by this question: I just wrote that the compositor is not screen aware. How should a plugin be able to handle screen aware rendering if the core does not? I can only speak from the existing colour server plugin. It does handle per screen colour correction regardless of support in the actual used compositor. Of course it needs a n-screen loop for drawing all screen overlapping windows. split into multiple rendering passes - one for each screen. This is quite a change in the way how KWin renders, but might be a useful change. As a second step all fragment shaders need to be adjusted to do the color Which shaders and adjusted for what specifically? May you point us to them, in order to get an idea? http://quickgit.kde.org/index.php?p=kde-workspace.git&a=tree&f=kwin As KWin renders through shaders and I expect that the screen should always be color corrected the answer is simple: all of them. A 3D texture lookup is done usually only once inside the pipeline. The plugins inside the kwin/effects path might be used simultaneously. So placing a additional 3D texture lookup into each of those plugins would lead to unwanted multiple colour corrections. GSoC completes or not will be judged only by Oyranos. A successfully completed project at Oyranos to write code to KWin does not mean that the code will be merged into KWin. The more we are interested to see the KWin project being involved. Whether a project succeeds or not does not depend on KWin being involved in this project. It's the mentor and student who have to ensure to develop code acceptable to the requirements of KWin development. Personally I would not make inclusion of code a pre condition for the success of such a project. Upstream inclusion of code is a high goal for contributors anywhere. Not many GSoC projects reach that immediately. Given recent discussions on this mailinglist about Oyranos and colord I am very unsure whether I want any color management relevant code in KWin at the moment. I will definitely not accept any code supporting only one of the two systems and any additional build or run-time dependency to KWin will not be accepted. Has KDE facities to load and apply ICC profiles? ICC support needs at least a colour management module (CMM) like lcms. In general there seems to be agreement that color management has to be done inside the toolkit/application and not inside the compositor. A fully color You are pointing towards osX? Sorry, but what does it have to do with OS X? osX is to my current knowledge the only desktop environment with colour correction to the whole screen. That could be seen as a hint towards "colour management has to be done inside the toolkit". I think that Qt and any other toolkit will need a not small amount of time to implement a similar engineered colour managed scene graph. Such stuff is certainly deployed inside PDF workflows. But my feeling says, it is a lot of work to get such a beast inside a cross platform Qt layer. Very likely not Qt5. How long would we have to wait for that? 5 years or more realistically 10 years or will that happen at all? Do you have any references showing that it is impossible to add color correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't base technical decisions on "my feeling says". That would mean colour management appears earliest inside Qt 6. But it is at the moment not clear if that happens at all. On the other hand, Xorg architect Jim Getty told me, that compositors are the right places for colour correction. that might be quite true, but not if apps want to opt-out. The X Color Management spec allows for opt-out inside compositors. I think to demonstrated you that on osC. corrected compositor seems feasible to me, but one where some applications need to start opting-out of being color corrected is nothing I want to see in KWin as it adds significant complexity and overhead to the rendering process. Opting out of colour management is a pre condition to do * raw measurements, such as for ICC profile generation * application side specialised colour correction It needs to internally store the colour transform per window. If there is none, then there is no conversion needed. in other words: it affects all windows and adds significant rendering overhead to it as it has to be decided whether there has to be a conversion or not. That's exactly what I
Re: [GSoC] KWin colour management
Am 20.03.12, 21:17 +0100 schrieb Thomas Lübking: Am 20.03.2012, 20:12 Uhr, schrieb Martin Graesslin : A fully color corrected compositor seems feasible to me I'm atm. not even sure about that. I might be utterly wrong, but my impression is that the xvidmode extension can correct screens (eg. xcalib loads icc profiles), so a screen wide color xvidmode gamma ramps are per channel curves. These are very limited compared to ICC based colour correction. Those gamma curves provide better gray balance and potentialy white point adjustment. But they do not describe colour primaries shifts or other more complex distortions. Gamma curves must be taken into account for ICC profiles. But detailed characterisation of device colorimetry happens usualy in ICC profiles. correcting compositor would be only required to fix multiscreen (not multihead) setups which i frankly consider no case either, because a full correction would just mean to restrict the WG screen to the SRGB one The X Color Management spec requires per window colour correction for base line implementations. Thus it is possible to specify an source space other than sRGB. (yesno?!), what doesn't much sound like a great achievement to me (and is simply no case in at least the professional context. You don't purchase _one_ WG screen to use it -restricted- alongside your SRGB screen, but just purchase two WG screens and give away the SRGB one to one of your employees at home or whatever) exactly. Thats why opting out of colour management and being able to specify a intermediate colour profile is a good thing. Cheers, Thomas kind regards Kai-Uwe
Re: [GSoC] KWin colour management
Am 20.03.12, 20:12 +0100 schrieb Martin Graesslin: On Sunday 18 March 2012 20:01:01 Casian Andrei wrote: Hello, taking it to the KWin mailinglist as that's the relevant list in case this proposal would be accepted. First of all thanks for considering doing a GSoC project around KWin. I need your guidance in order to create a decent proposal. I understand the project will involve implementing the colour management features in KWin. As the idea suggests, this would imply making KWin handle the _ICC_COLOR_OUTPUTS and _ICC_COLOR_PROFILES atoms. This would probably only be part of it. Today I documented myself about colour management in general, and how it's done in Linux. I also read about ICC, Oyranos, X color management and related things. Now I'm not completely in the dark as before. I looked around in the KWin code and I found the area of interest - the compositor part, more specifically KWin::SceneOpenGL. Since shaders will be needed, it looks like some custom shaders of type KWin::ShaderManager::ColorShader would be able to do the job. Please correct me if this is wrong. There is more into it: first of all KWin currently does not distinguish between screens during rendering. To properly have screen aware color correction the complete compositor has to be made screen aware. The repaint loop has to be As a side note, during the last CLT fair there was the idea brought up, to place ICC colour correction inside a KWin plugin. Is that recommendable? split into multiple rendering passes - one for each screen. This is quite a change in the way how KWin renders, but might be a useful change. As a second step all fragment shaders need to be adjusted to do the color Which shaders and adjusted for what specifically? May you point us to them, in order to get an idea? http://quickgit.kde.org/index.php?p=kde-workspace.git&a=tree&f=kwin correction. This has to be done extremely efficient. This is a rather critical code path especially for low-end hardware (think of old Intel GPUs). Given the constraints of the GPUs a dynamic feature activation is not possible. What is in general important to know is that we have not had the best experience with GSoC students doing work on the core of KWin. Given that I proposed guidelines for future feature additions to KWin by non-core developers [1]. Furthermore I want to mention that the project would at max be co-mentored from the KWin team. The slot is provided by the Oyranos community and not by KDE. This means that the main mentor will be at Oyranos and also whether the The actual choosen slot comes from openSUSE, as they like to see a colour managed KDE too. GSoC completes or not will be judged only by Oyranos. A successfully completed project at Oyranos to write code to KWin does not mean that the code will be merged into KWin. The more we are interested to see the KWin project being involved. Given recent discussions on this mailinglist about Oyranos and colord I am very unsure whether I want any color management relevant code in KWin at the moment. I will definitely not accept any code supporting only one of the two systems and any additional build or run-time dependency to KWin will not be accepted. Has KDE facities to load and apply ICC profiles? ICC support needs at least a colour management module (CMM) like lcms. In general there seems to be agreement that color management has to be done inside the toolkit/application and not inside the compositor. A fully color You are pointing towards osX? I think that Qt and any other toolkit will need a not small amount of time to implement a similar engineered colour managed scene graph. Such stuff is certainly deployed inside PDF workflows. But my feeling says, it is a lot of work to get such a beast inside a cross platform Qt layer. Very likely not Qt5. How long would we have to wait for that? 5 years or more realistically 10 years or will that happen at all? On the other hand, Xorg architect Jim Getty told me, that compositors are the right places for colour correction. corrected compositor seems feasible to me, but one where some applications need to start opting-out of being color corrected is nothing I want to see in KWin as it adds significant complexity and overhead to the rendering process. Opting out of colour management is a pre condition to do * raw measurements, such as for ICC profile generation * application side specialised colour correction It needs to internally store the colour transform per window. If there is none, then there is no conversion needed. This is something the Oyranos community has to decide on how they want to have that handled. Oyranos is only one colour management project inside the OpenICC community. It is true that I am much behind the concept of implicite display ICC colour correction. But surely more people have a interest in that concept being deployed inside KDE. Kind Regards Martin Gräßlin KWin Maintainer kind regards
Re: Re: Review Request: include KolorManager in kdegraphics
Am 16.03.12, 17:05 +0100 schrieb Alex Fiestas: On Friday, March 16, 2012 03:09:39 PM John Layt wrote: 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. Agreed 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) 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 -- www.oyranos.org
Re: [GSoC] KWin colour management
Thanks for posting here. Am 18.03.12, 20:01 +0200 schrieb Casian Andrei: Hello, I am a final year undergraduate student at the Polytechnic University of Bucharest, Automation and Computers Faculty. I am interested in the "Compositor Colour Management" idea from OpenSUSE. It looks like something I would enjoy doing. Given that colour management inside open source toolkits is a very very long outstanding issue, and we are still at the beginning with that, it is unlikely that Qt5 will allow to colour manage _all_ it's widgets by default. That means, we will see only few graphics applications to do ICC colour correction themself. Consequently most other desktop applications and areas will look different on each monitor. In my opinion, the most easy path towards working end to end colour management inside KDE is to assume sRGB for all non colour aware applications and do colour correction unquestioned. That concept is worked out on OpenICC and used and checked on a daily base with CompICC. So it is no longer a experimental feature. In comparision, the concept to colour manage unaware colour content is as well common practise inside Linux and other OS printing paths. Ghostscript and likely Poppler will or do already colour convert the mass of todays /DeviceRGB colour unquestioned. They will implicitely assume that these colours to be meant as sRGB. I suggest we should follow that route for displaying inside KWin and improve colour useability on the KDE desktop. I have acceptable C / C ++ skills and lots of experience with OpenGL. I am also familiar with Qt. Regarding shaders, I wrote a couple about 2 years ago for an old project, and I still know how they work, so it would be easy for me to remember. Last GSoC I worked on an OpenGL interface for VLC, and 2 years ago I worked on capture support in Phonon. I need your guidance in order to create a decent proposal. I understand the project will involve implementing the colour management features in KWin. As the idea suggests, this would imply making KWin handle the _ICC_COLOR_OUTPUTS and _ICC_COLOR_PROFILES atoms. The idea behind these two atoms is to enable per window colour correction, which is relatively easy implemented. In a first step a window manager can be enabled with that feature. It is completely backward compatible. Graphic applications can be updated step by step to take advantage of the new ICC support by implementing the X Color Management protocol. They will profit by getting multi monitor aware very fast and power efficient colour correction with the smallest effort. Some few applications exist already, which deploy this scheme. Qt or KDE widgets can be created to share common code among such apps. Today I documented myself about colour management in general, and how it's done in Linux. I also read about ICC, Oyranos, X color management and related things. Now I'm not completely in the dark as before. I looked around in the KWin code and I found the area of interest - the compositor part, more specifically KWin::SceneOpenGL. Since shaders will be needed, it looks like some custom shaders of type KWin::ShaderManager::ColorShader would be able to do the job. Please correct me if this is wrong. But I am still unsure and I don't have an exact image in mind about what needs to be done. Clearly, more exploration is needed. I don't know what to concentrate on - looking around in KWin / Compiz code, concentrating on libXcm and the X Color Management spec, reading more about Oyranos and colour management in general? I tried the Oyranos colour management LiveCD and I saw it doing the correction magic, but unfortunately I was unable to get compiz working - with the open source drivers it didn't start because of missing glx_ext_texture_from_pixmap extension, and there were problems with the ati drivers - after installing them, the root visual was not a GL visual (or something like that), and if I tried to do some configuration with Catalyst, then X froze together with the system (nothing new for me, that's why I am sticking to the open source drivers). At least I know ICC profiles for both my monitors were found, by monitoring with QcmsEvents. Best regards, Casian kind regards Kai-Uwe -- www.oyranos.org
Re: Review Request: include KolorManager in kdegraphics
Michael Pyne schrieb: >On Wednesday, March 14, 2012 20:43:59 Daniel Nicoletti wrote: >> > 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). >> >> 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. > >OK, thanks for the clarification. I didn't mean to further spread a >possible >misconception (although I can't go back and edit it now anyways). 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
Re: Review Request: include KolorManager in kdegraphics
Am 15.03.12, 09:39 -0300 schrieb Daniel Nicoletti: 2012/3/15 Kai-Uwe Behrmann : ... 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
Re: Review Request: include KolorManager in kdegraphics
Am 15.03.12, 13:09 +0100 schrieb Thomas Zander: 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, Kai-Uwe -- Kai-Uwe Behrmann www.oyranos.org
Re: Review Request: include KolorManager in kdegraphics
Am 14.03.12, 14:29 -0700 schrieb Daniel Nicoletti: If CUPS is locally installed this means it can just send the job color 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
Re: Review Request: include KolorManager in kdegraphics
Am 15.03.12, 07:34 +0100 schrieb Stas Verberkt: 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 -- Kai-Uwe Behrmann www.oyranos.org
Re: Review Request: include KolorManager in kdegraphics
Am 15.03.12, 08:06 -0300 schrieb Lamarque V. Souza: 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
Re: Review Request: include KolorManager in kdegraphics
Am 14.03.12, 22:15 -0400 schrieb Michael Pyne: 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
Re: Review Request: include KolorManager in kdegraphics
Am 14.03.12, 20:39 -0700 schrieb Daniel Nicoletti: 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
Re: Review Request: include KolorManager in kdegraphics
Am 14.03.12, 20:43 -0700 schrieb Daniel Nicoletti: 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). 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. 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
Re: Review Request: include KolorManager in kdegraphics
Am 14.03.12, 14:29 -0700 schrieb Daniel Nicoletti: 2012/3/14 Kai-Uwe Behrmann : 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
Re: Review Request: include KolorManager in kdegraphics
Am 14.03.12, 17:04 +0100 schrieb Matthias Klumpp: 2012/3/14 Kai-Uwe Behrmann : 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 *
Re: Review Request: include KolorManager in kdegraphics
Am 14.03.12, 22:03 +0100 schrieb Alexander Neundorf: 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
Re: Review Request: include KolorManager in kdegraphics
Am 14.03.12, 21:29 +0100 schrieb Alexander Neundorf: On Wednesday 14 March 2012, Thomas Zander wrote: On Wednesday 14 March 2012 18.12.13 Kai-Uwe Behrmann wrote: 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. 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 ? 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 kind regards Kai-Uwe -- http://www.oyranos.org
Re: Review Request: include KolorManager in kdegraphics
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. 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
Re: Review Request: include KolorManager in kdegraphics
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. 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
Re: Review Request: include KolorManager in kdegraphics
Am 14.03.12, 15:54 +0100 schrieb Matthias Klumpp: 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 -- developing for colour management www.behrmann.name + www.oyranos.org
Re: Review Request: include KolorManager in kdegraphics
Am 14.03.12, 15:14 +0100 schrieb Thomas Zander: 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
Re: Review Request: include KolorManager in kdegraphics
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-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 [1] http://lists.freedesktop.org/mailman/listinfo/openicc
Re: Review Request: include KolorManager in kdegraphics
Am 14.03.12, 04:36 -0700 schrieb Daniel Nicoletti: 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? 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
Review Request: include KolorManager in kdegraphics
Request ID: 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
Re: Color Managing KDE
"Martin Gräßlin" schrieb: >Am 22.02.2012 20:01, schrieb Kai-Uwe Behrmann: >> Am 22.02.12, 09:38 -0800 schrieb Daniel Nicoletti: >>> As Richard said Oyranos is doing all this by it self on the CPU so >>> it >>> would act like a proxy between your application, >>> and the window manager which sounds like killing performance. >>> ( I might have misunderstood but I can't see any other way of doing >>> this) >> >> Proxy are configurable by applications as usual. >> Oyranos is used inside a Compiz plugin as the actual only desktop >> colour server. >> That does very power efficient and fast colour correction on the GPU >> through GL shaders. Users can watch colour corrected animations, >> movies and 3D scenes full screen with that. >Just a short reminder that Compiz is no solution for the KDE Plasma >Workspaces, as > >a) our solution for window and compositing is KWin >b) using Compiz means loss in core functionality provided by the KDE >Plasma Workspaces >c) to my knowledge the plugin does not work with recent versions of >Compiz (aka Compiz++, Compiz 0.9) >d) distributions are starting to drop Compiz >e) Compiz development has been adjusted to only suit the Unity desktop >and has been proclaimed as dead on the Internet > >adding support to that in KWin should be fairly easy though I have no >clue about it and also no time for it. We had recently a discussion on the wayland channel. The result does in effect simplify colour management for compositors. A KWin GSoC project was added to the OpenICC ideas page. Advice from KWin developers during such a project would be highly appreciated. I blogged with some more details about the X Color Management protocol, which can be implemented inside KWin: http://www.oyranos.org/2012/02/x-color-management-0-4-draft1/ kind regards Kai-Uwe
Re: Color Managing KDE
Am 22.02.12, 09:38 -0800 schrieb Daniel Nicoletti: As Richard said Oyranos is doing all this by it self on the CPU so it would act like a proxy between your application, and the window manager which sounds like killing performance. ( I might have misunderstood but I can't see any other way of doing this) Proxy are configurable by applications as usual. Oyranos is used inside a Compiz plugin as the actual only desktop colour server. That does very power efficient and fast colour correction on the GPU through GL shaders. Users can watch colour corrected animations, movies and 3D scenes full screen with that. kind regards Kai-Uwe
Re: Color Managing KDE
Am 22.02.12, 16:42 - schrieb John Layt: On 22 Feb 2012 11:29, "Boudewijn Rempt" wrote: On Wednesday 22 February 2012 Feb, Nuno Pinheiro wrote: A Quarta, 22 de Fevereiro de 2012 10:46:53 Richard Hughes você escreveu: First, I apologise about the cross posting. Please drop any list which isn't relevant in your replies, and please also cc me as I'm not subscribed to either list. GNOME has been a color managed desktop by default for two releases now, and I deliberately designed colord to have an open Freedesktop DBus API that could be used by both desktops. Really, KDE just has to include a KCM module to do the 6 things on this list and also perhaps include a simple control center panel to configure it. Basically, I need a KDE dude. Of course, I can help quite a lot and mentor the project, but I’ve never really coded Qt or C++ in anger, so to speak. If you’re interested, I could maybe even set up a Google summer of code place as well, although I’d prefer it to be an existing person familiar with the KDE community so there is some ongoing maintainer. If anybody is interested, let me know and I’ll set up a meeting and we can talk and discuss details. Thanks. Richard Hughes Use case here I want this :D, please guys help Richard. Yill make you free icons :D and mybe pay you a beer or 2. While I agree that KDE needs colormanagement built-in, especially with artists moving to KDE (I get almost no bug reports for Krita from gnome users anymore, while that used to be the majority...) it's not like nothing has been done before for KDE: Especially: http://www.oyranos.org/2011/11/kde-and-colour-management/ http://www.oyranos.org/kolormanager/ which are now, afaik, being used in OpenSUSE. There's quite a bit of contentiousness between around this topic, and I have to say, while I don't get the technical differences all the time, I do understand the friction I see happening on, e.g., the openicc mailing list. With all the respect I feel for Richard, I do think that this is yet another of those technologies that get developed in splendid isolation for Gnome, forced upon the Linux world by Redhat, claimed to be a standard and which is then used to complain about KDE's lack of involvement yet again. It makes me feel a bit unhappy. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl It's not a situation I understand or want, but the reality is we now have two competing colour management systems which are shipping in distro's. It's a situation I'll have to learn more about later from a Qt printing context, but for now rather than debate the rights and wrongs we need to think about supporting KDE users on Fedora, Red Hat, and any other distros that choose colord over oyranos. Fedora packages Oyranos since years. All that is needed here right now, and all I believe Richard is asking help for, is for a KCM to configure colord. KDE is a community know for it's pragmatism and I think we need to be pragmatic here as it is not diverting significant resources or making deep changes, or expressing support for one or other solution. An other approach is to put effort in bringing all Linux CMS'es to use one common configuration DB. The format is agreed upon. I implemented some code to access it and want now to use that inside Oyranos. We have a OpenICC GSoC project to provide patches for all substancial CMS'es on Linux namely ArgyllCMS, Oyranos and colord: http://www.freedesktop.org/wiki/OpenIcc/GoogleSoC2012#OpenICC_Colour_Configuration_Data_Base I believe Alex Fiestas has expressed an interest in the past in developing a KCM so he might be a good starting point. kind regards Kai-Uwe
Re: Color Managing KDE
Gilles Caulier schrieb: >If KDE include a color management based on Oyranos, what's about >applications which have already a Color Management system, based on >another library ? > >For ex, in digiKam we have used LCMS ver1 and we currently port to >LCMS ver 2 (http://www.littlecms.com) > >We will need to break all LCMS based implementation in digiKam and >port all again to another library as Oyranos ??? Oyranos is optional. The configurations are planed to be parseable JSON. It is up to de elopers to find value in it, e.g. it's multi monitor colour correction. But that might become more interesting once Qt/KDE widgets are colour managed. Btw. Oyranos is in parts a wrapper around lcms. It does not implement ICC colour calulations like lcms, qcms, ArgyllCMS or SampleICC. >Which CM sub-system is used by Gnome Desktop ? They uses Oyranos too ? They use colord. But that itself does no colour correction at all, just configuration. Gnome apps use lcms, like in Inkscape or Gimp. >Gilles Caulier kind regards Kai-Uwe >2012/2/22 Christoph Feck : >> On Wednesday 22 February 2012 11:46:53 Richard Hughes wrote: >>> GNOME has been a color managed desktop by default for two releases >>> [...] >>> Basically, I need a KDE dude. >> >> Our "color management KDE dude" is Kai-Uwe Behrmann from Oyranos >> team. See "git/playground/graphics/kolor-manager" for what is already >> available. >> >> Christoph Feck (kdepepo) >> KDE Quality Team kind regards Kai-Uwe
Re: Color Managing KDE
Am 22.02.12, 11:52 - schrieb Richard Hughes: On 22 February 2012 11:30, Christoph Feck wrote: Our "color management KDE dude" is Kai-Uwe Behrmann from Oyranos team. See "git/playground/graphics/kolor-manager" for what is already available. I gave up on working with Kai-Uwe a long time ago. Oyranos and colord are competing frameworks that have *very* different design ideologies. I was always inviting for collaboration and will continue so. My proposals and standards are a living example for that. The Taxi ICC online DB is open for everyone, including colord users. Last year I wrote code to share users settings on the desktop. The code, including a formal proposal which was discussed on last years LGM in Montreal, is online and planed to be use in Oyranos. This is a invitation to use it as well in colord and other CMS'es for the freedom of users and application developers. Think, DBus is not available everywhere. The idea of competion came not from me and I do not like to follow that, as it endangers collaborative work in OpenICC. I've written a lot in the past on why I think Oyranos is the wrong approach, which I'll not write again here. From my biased point of view, in just over one year, colord has gone from concept to being included on nearly all distros by default. It's pulled in as multiple things like GTK and CUPS as a dependency. It's my firm belief that color management should be usable by real people without having to install or configure anything. Hmm, the Oyranos project targets at non specialist and supports specialist needs at the same time. Many things are automated for easy handling and better control. I do not know, what is suggested with the last sentence. I'm offering to help hackers in the KDE community build simple GUI code on top of colord. You guys get a color management system that works, and I get more users using my stuff. It's a win-win situation. regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
Re: Color Managing KDE
Oyranos CMS is about preparing a release and then the existing KDE Color Management panel will be ready to continue inclusion into KDE. I appologies for the delay. The KDE Color Management panel or kolor-manager in kde git provides a front end to the Oyranos API, including configuration of settings and devices. Peer reviewed ICC profile packages from well known sources are packaged and prepared for use with Oyranos. Honestly, the colord profiles are uncontroled altered from uncertain sources, falsely labled and unfortunately buggy. While the colord author can nothing for bad colourimetric quality, there was even after many warnings no attemt to check their quality and fix the package. So many users are now exposed to these profile sets. colord as well as Oyranos are no guarantee for a colour managed desktop. There is far more work involved, like creating cross desktop standards and in parts cross OS recommendations, which I have put much work into. And these conventions have to be transformed into code, which are target at KDE and I helped with. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org Am 22.02.12, 10:46 - schrieb Richard Hughes: First, I apologise about the cross posting. Please drop any list which isn't relevant in your replies, and please also cc me as I'm not subscribed to either list. GNOME has been a color managed desktop by default for two releases now, and I deliberately designed colord to have an open Freedesktop DBus API that could be used by both desktops. Really, KDE just has to include a KCM module to do the 6 things on this list and also perhaps include a simple control center panel to configure it. Basically, I need a KDE dude. Of course, I can help quite a lot and mentor the project, but I’ve never really coded Qt or C++ in anger, so to speak. If you’re interested, I could maybe even set up a Google summer of code place as well, although I’d prefer it to be an existing person familiar with the KDE community so there is some ongoing maintainer. If anybody is interested, let me know and I’ll set up a meeting and we can talk and discuss details. Thanks. Richard Hughes
Re: OpenPrinting Summit - Print Dialog and Colour Management
Am 17.03.11, 16:28 - schrieb John Layt: On Thursday 17 Mar 2011 15:42:23 Kai-Uwe Behrmann wrote: well, I'd hate to see/implement/support integration code for every different CMS :-) At least Oyranos targets verbaly at cross platform, if thats of relevance for osX and Windows. The Oyranos library API is basic C. ArgyllCMS comes with pure CLI and colord with only DBus. Not sure what you exactly expect out of this mixed concepts for code integration. At least there are two C APIs. Well, I see rhughes on the OpenPrinting list talking about integrating colord directly into the CPD, and then we'll integrate Oyranos, and then I'm sure At this point, I am not even sure, if there is interesst from the Gnome side to do any colour management work inside CPD. To add some background, rhughes belives in putting his CMS in parallel to the CUPS own CMS into CUPS server, as far as I have understood his posts. The Oyranos project belives the CPD is the best place to do its work. It follows the idea to integrate user colour management on the client side and leave the CUPS vendor side CMS buisness to CUPS server. someone will want ArgyllCMS support as well... IMO ArgyllCMS targets at profiling and a clean and simple path to install the generated profiles. The other interesst is to preserve a explicitely non colour managed print path for ink limiting, calibration and profiling. That remaining functional is very important to create useful ICC profiles. But I'm talking from a postition of ignorance here, I need to make time to read all the doco and mailing lists and understand what it actually means. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
Re: OpenPrinting Summit - Print Dialog and Colour Management
Am 17.03.11, 12:17 - schrieb John Layt: On Thursday 17 Mar 2011 11:36:08 Kai-Uwe Behrmann wrote: I hope Hal V. Engel from OpenICC, who comes with many experience in printing, will join the OpenPrinting meetings. He lives only some miles away from the location. Yes, I believe Hal will be there, in fact I've been talking to him about the Qt version of the dialog. We think already since quite some time how to converge for CMS settings. Graeme Gill, the author of a pre dominant cross platform CMS, has signaled high interesst for ArgyllCMS in such a standard, and we both agreed to give that some meaning during this year. We feel settings in one UI should not get irrational lost after switching to an other standard supporting CMS. That's good to hear, hopefully you work something out that colord uses as The author is as well on OpenICC and can simply comment on he data base fundamentials and structure, as he did in the past. well, I'd hate to see/implement/support integration code for every different CMS :-) At least Oyranos targets verbaly at cross platform, if thats of relevance for osX and Windows. The Oyranos library API is basic C. ArgyllCMS comes with pure CLI and colord with only DBus. Not sure what you exactly expect out of this mixed concepts for code integration. At least there are two C APIs. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
Re: OpenPrinting Summit - Print Dialog and Colour Management
Am 17.03.2011 12:11, schrieb John Layt: > On Thursday 17 Mar 2011 06:30:50 Kai-Uwe Behrmann wrote: >> Am 17.03.11, 00:27 +0100 schrieb Christoph Feck: >>> Kai-Uwe Behrmann (maintainer of KDE color management applications) can >>> help you here. Grab him on http://www.oyranos.org/ and make sure he >>> attends the meeting ;) >> It would be really cool to have joined you to talk about colour >> management with KDE. However I am very likely to be swamped with work >> during this time. >> >> With the help of OpenICC[1] some work has been done inside the Oyranos >> project about printing. The Kolor Manager configuration panel[2] shows >> some of these. It would be cool for CPD to deploy Oyranos device ICC >> profile configuration to create a good user experience. I am about >> preparing some schematic diagrams, which can give some condensed input >> from the latest OpenICC discussions around linux colour managed printing. > It's great to know we have someone working on this, it's a shame I didn't > know > > > > >> Thanks for your work! >> >> John. >> > earlier when first discussing attending the summit with the OpenPrinting > guys, > it would have been great to have someone there who knows what they are > talking > about :-) I hope Hal V. Engel from OpenICC, who comes with many experience in printing, will join the OpenPrinting meetings. He lives only some miles away from the location. > I guess I have a lot of reading to catch up on to understand how this all > works and hangs together, then hopefully I can make some meaningful comments > at the summit on what KDE would like to see happen. > > Something I think I'll need to understand is why the CPD (or any print > dialog) > would need to have direct support for different colour management systems > (Oyranos, colord), is there a way to abstract it via a common standard? We think already since quite some time how to converge for CMS settings. Graeme Gill, the author of a pre dominant cross platform CMS, has signaled high interesst for ArgyllCMS in such a standard, and we both agreed to give that some meaning during this year. We feel settings in one UI should not get irrational lost after switching to an other standard supporting CMS. kind regards Kai-Uwe
Re: OpenPrinting Summit - Print Dialog and Colour Management
Am 17.03.11, 07:29 +0100 schrieb Boudewijn Rempt: On Thursday 17 March 2011 Mar, Christoph Feck wrote: Also on the agenda is integrated end-to-end Colour Management possibly using colord [4], something I know absolutly nothing about, so any feedback or suggestions people have on that will be very welcome. For starters the dependencies for colord are glib and policykit. Kai-Uwe Behrmann (maintainer of KDE color management applications) can help you here. Grab him on http://www.oyranos.org/ and make sure he attends the meeting ;) Well... Kai-Uwe and Richard Hughes have had huge discussions on colord on the openicc mailing list (http://lists.freedesktop.org/mailman/listinfo/openicc) -- too huge for me to follow them. This list might be a good starting place for more info. For what I got out of it, colord seems to be, like so many "generic" libraries be focussed on gnome/gtk-first, while oyranos (Kai-Uwe's system) is burdened by using a config system that nobody packages. But that impression might be outdated and is certainly over-simplified. Agreed, the discussion threads are very long. But we are about to extract important ideas[1][2] and turn them into proposals[3]. Oyranos ships with the needed configuration code inside its source tree since the last release at begin of this year. The library comes with a CUPS module for printing, and further SANE (which needs patches), Xorg, Quarz monitor and CameraRAW modules. What would be cool to have are a Quarz module for printing and make the library fit for Windows' WCS. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org [1] http://www.freedesktop.org/wiki/OpenIcc#LINUXcolormanagementaproposalforimplementation [2] http://www.oyranos.org:443/wiki/index.php?title=Device_Settings#Printing [3] http://www.freedesktop.org/wiki/OpenIcc#PPDcolouring
Re: OpenPrinting Summit - Print Dialog and Colour Management
Am 17.03.11, 00:27 +0100 schrieb Christoph Feck: On Wednesday 16 March 2011 18:44:31 John Layt wrote: Hi, I'll be attending the OpenPrinting Summit [1] to discuss how to complete the Common Printing Dialog [2] and integrate it into KDE and Qt. I'm looking for any feedback people may have about the CPD, and any questions you want me to ask while I'm there. Many thanks, John, for never giving up with improved printing in KDE! There a two main issues I see with the current approach of the CPD, and if possible, you could bring them up in the discussion. First, regarding the "common" part of the printing dialog, I hope that using a common denominator of features offered in all operating systems does not reduce the feature set again; we already went through it. (I guess you know the existing bug reports. It boils down to the major feature loss that we got when killing KDE 3.x printing system.) The new printing dialog should not be shy on options, such as pamphlet printing, customizable filters, and (most importantly) application specific options with the ability to allow saving settings in global or application specific profiles. The second concern is about the D-Bus API. I hope that it will still be possible to get a fast in-application preview with it when using the native API. For example, I love how the current Qt printing preview dialog just copies image pointers in the QtPrinter painting engine, so that the preview renders literally the same images as the application has in memory, without copying the actual data. The Qt printing preview is also very fast in scrolling and zooming, I doubt it would be possible with a program that effectively "just" tries to parse PostScript or PDF printer files just to generate the preview. Also on the agenda is integrated end-to-end Colour Management possibly using colord [4], something I know absolutly nothing about, so any feedback or suggestions people have on that will be very welcome. For starters the dependencies for colord are glib and policykit. Kai-Uwe Behrmann (maintainer of KDE color management applications) can help you here. Grab him on http://www.oyranos.org/ and make sure he attends the meeting ;) It would be really cool to have joined you to talk about colour management with KDE. However I am very likely to be swamped with work during this time. With the help of OpenICC[1] some work has been done inside the Oyranos project about printing. The Kolor Manager configuration panel[2] shows some of these. It would be cool for CPD to deploy Oyranos device ICC profile configuration to create a good user experience. I am about preparing some schematic diagrams, which can give some condensed input from the latest OpenICC discussions around linux colour managed printing. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org [1] http://www.freedesktop.org/wiki/OpenIcc [2] http://www.oyranos.org:443/wiki/index.php?title=Kolor-manager
colour managed KWin
Hello, the kde-usability people on IRC suggested me to write here about a project idea around kwin. in short: KWin would be great to support ICC colour profiles in order to colour correct the complete desktop in hardware. detailed: Through KWin's shader plugins it is possible let the GPU colour correct all windows on the fly. Thats extremly efficient. Background images, icons, all windows of all toolkits (including native Xorg), inclusive movie playing, games and so on would be colour managed for each monitor. The desktop would we assumed to be in sRGB, the standard internet colour space. That is what nearly all theme and application designers choose their colours from. To do it properly, the net-color spec[1] should be supported along side. It covers a communication protocol to talk to the desktop colour server and tell it, which regions in a window shall not be colour corrected. Thats important for applications like Scribus, Krita and Inkscape. They can then do their own colour management in one go and bypass sRGB. sRGB can become a bottleneck for wide gamut monitors or for calibration during ICC profile creation. The whole thing can be made completely automatic. This is demonstrated with a recently published LiveCD[2]. It starts without knowing anything about the attached monitor into a full colour managed desktop with Compiz. Techically it asks for the EDID data from the monitor to get the proper colorimetry and creates a ICC profile on the fly. This is often not perfect, but it is a great improvement over no colour correction. Btw. it is on an other OS daily practice for hot plugged monitors. Most image content is sRGB. So most users will benefit very much. It would be great to get feedback here and figure out if and how this project could come in live. about me: I am a opensource colour management consultant, developer and freelancer. On different projects I worked on the colour management side. My actual focus are proposals and data sets on the OpenICC project[3] and a according implementation in the open source Oyranos colour management system [4] and other smaller components. about Oyranos The goal with Oyranos is to obtain automatic colour management for many device classes. In Oyranos the most mature state is reached for displays on Xorg and Quarz. It would be cool to extent this to WCS, Android and get the other device classes to a similiar level. Automatic means in this context, no interaction of end users shall be needed. Manual preferences keep priorised for experts. Oyranos is packaged for some RPM based distributions [5]. The Oyranos project captures most of my free time ;-) kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org oy is in #openicc and #kde-devel @ freenode [1] http://www.oyranos.org/scm?p=xcolor.git;a=blob;f=docs/net-color-spec [2] http://oyranos-cms.blogspot.com/2011/02/oyranos-colour-management-livecd-ii.html [3] http://www.freedesktop.org/wiki/OpenIcc [4] http://www.oyranos.org/#about [5] http://software.opensuse.org/
