Am 10.11.2013 11:05, schrieb John Layt: > On 9 November 2013 12:50, Olivier Goffart <oliv...@woboq.com> wrote: >> On Saturday 09 November 2013 03:02:18 Alessandro Portale wrote: >>> I like the idea of re-starting small, and quite a bit of what was done >>> in Nokia times can certainly be re-used. >>> What if Qt started by simply *enabling* color management. I.e. giving >>> access to the information that an application needs to perform color >>> management tasks itself. In a much later iteration Qt could perhaps >>> perform color management operations. Qt should IMHO avoid automatic >>> color management under the hood, especially without providing API to >>> control it. >>> >>> Milestones could be: >>> 1) QImage[Reader] gives access to image color profile. Either whole >>> profile or just an identifier in case of standard spaces such as sRgb. >>> 2) QScreen gives access to the current display color profile for that >>> specific screen. >>> 3) There are notifications (signals?) when the a window changes to >>> another screen, or when a screen profile is changed in the system. >>> 4) Same as "2" but for installed Printers on the system. >>> ... >>> 99) QColorEngine can do color conversions using an input profile, a >>> source Image an output profile plus different parameters. >>> >>> Ideas? Kai-Uwe, what color management feature (or enabler) are you >>> missing most in Qt? >> Allow me to disagree :-) >> How usefull are 1-4 without 99? What exactly can you do with that >> information. > Well, I'm no expert at the graphics side of things, but I think before > you can start applying a color profile you need to know what color > profile to apply :-) If we at least expose that config for apps to > use then they only need to apply the transforms themselves, rather > than also having to abstract the system config. Then afterwards we > can start using the config ourselves in our own code. OTOH we don't > want to ship api that we may have to change later when we start using > it ourselves in anger. > > I think step 1 is very definitely a cross-platform api to access the > host system config and profiles, regardless of whether we make it > public or not. That's easy enough for Windows and Mac where each has > a single color management framework built-in, but on Linux we still > have two competing systems (perhaps Kai-Uwe can update us on that > situation, is there a single combined config yet?).
Most applications use for Xorg the ICC Profile in X spec [1]. The spec is served by Oyranos CMS as well as the colord CMS and others. > Now, to really expose my lack of knowledge, AFAIK Mac especially and > Windows graphics contexts can apply the required transforms themselves > internally, so wherever we use the native context it's surely just a > case of configuring them to do the work for us? It's really only on > Linux or XP that we would have to have code for doing the transforms > ourselves using LCMS? But like I said, I know nothing of our graphics > internals :-) Lcms is for realtime conversions too slow. OpenGL provides in some profiles a 3D texture lookup on the GPU, which is fast. kind regards Kai-Uwe Behrmann [1] http://www.openicc.info/index.php?title=ICC_Profiles_in_X_Specification_0.4 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development