On 08/29/2016 03:16:16 PM, Morten Sorvig wrote: > > > On 29 Aug 2016, at 10:20, Anders Torger <tor...@ludd.ltu.se> wrote: > > > > > > Hello, > > > > The color management capabilities of QT for displaying images is > quite > > hard to figure out. I've searched the internet and you get very few > > > hits often pointing to discussions several years old. So I think > it's > > appropriate to start a new thread to get the latest. > > > > I'm new to QT, but I'm not new to color management and ICC > profiles. > > > I've worked a bit with GTK and RawTherapee project so I know how > color > > management is handled there in Windows / Linux and OS X. > > > > What you typically do in a cross-platform scenario is that you > figure > > out which ICC profile the display has in a platform-specific way > (if > > > you have multi-head you just have to choose one, haven't seen > anyone > > > handle a window which is displayed on two screens simultaneously), > and > > then you use LittleCMS or other third-party library to convert your > > > RGB data yourself to an output that matches the display, and then > you > > just put that raw data to the screen using the GUI toolkit. In > other > > > words, the GUI toolkit doesn't do any color conversions, but just > > delivers the raw pixel values to the display. > > > > This is how you do it in GTK. With GTK there is as far as I know a > > problem on Mac OS X, where GTK is not low-level enough; Mac OS X > APIs > > (Quartz?) will do the display conversion always so you can only > output > > sRGB(?). I've not worked too much with OS X so I'm not 100% sure > how > it > > works there or if there is a work-around to get larger color space > than > > sRGB. If anyone happens to know that too, I'm all ears. > > We’ve researched a bit into the OS X side of this, see QTBUG-47660. > Input > from application developers is very welcome here - I’d like to make > sure > what we implement is actually usable in practice. > > If you don’t want to use OpenGL then we’re looking at supporting two > modes: > > * The application outputs sRGB/linear sRGB to Qt. Qt will configure > the > native view accordingly, color conversion to the display color > space > > is done by the OS. > > * The application gets the ICC profile for the display and outputs > per- > display correct colors to Qt. Qt configures the native view to use > the > display profile. There is no color space conversion outside > application code. > > There is currently no API available to support this; the first > iteration > would probably be a a mac-spesifc API. > > Recently Apple introduced the "extended linear sRGB” color space > (with > support for component values below 0.0 and above 1.0), specifically > for > wide-gamut displays. I think we need floating-point support in QImage > to make use of this format. > > Morten > >
Thanks. Looking at QTBUG-47660, if I understand it correctly it says that since QT 5.5 a QImage will output "native" pixels to the display. That is if I send 255,0,0 the display it will show the reddest red it can output. If that is correct, it will work for us, as we then can do "the usual way", that is find and load the display ICC profile using a native method, and use LittleCMS to convert from our internal format to the display's color space. That would be great, as it would work the same in Linux, Windows and OS X then. In the longer term I'm sure the typical application developer would love the mode when color space is locked to sRGB (or better if you can pick among a number of presets) and then QT makes sure proper conversion to the display takes place under the surface. That is the typical application developer never needs to care about color management, "it just works". However the typical application developer probably doesn't care at all if colors vary a bit as few applications require accurate colors. If color management is required it's a special case, and I think application developers can then accept the extra complexity by having to use LittleCMS or similar to do the conversion on their own. The most important thing is that you actually *can* do it in some way or another. As said with GTK it was not possible on OSX due to output colorspace being locked to sRGB rather than native display like on the other platforms. When writing cross-platform applications I see an advantage in "dumbing down" color management so it becomes equal between Linux/ Windows/OSX. In Linux and Windows we've used to having to do it manually in the application as the colors we send to the toolkit will be displayed with native display values. OSX has more advanced/ automatic color management, but if QT makes use of that it would mean that either it would work differently in Linux/Windows or one would have to make QT's color management a lot more advanced on those platforms to make it as automatic as on OSX. The largest drawback with the application-doing-it-on-its-own approach is that multi-head configurations can't really be made to work. The classic example if you have half of your application window on one screen and the other half on another, which have different ICC profiles. App-controlled color management usually means that you convert for the primary display, and only that. If QT itself would handle color management on a lower level I assume multi-head could work too. However I find this problem to be a minor one, as when you do work with a color managed application, it's about graphics, photos etc, and then you generally have one expensive calibrated monitor which is your primary display where you place the GUI. /Anders _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
