[GSoC] KWin colour management
Kai-Uwe Behrmann
ku.b at gmx.de
Thu Mar 22 07:19:09 GMT 2012
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
More information about the kde-core-devel
mailing list