On 09/27/2011 09:01 AM, ext Niels Ole Salscheider wrote: > Hello, > >> Even just a way of preserving the color profile identifier would be >> probably enough to let the compositor/windowing system know what format >> the given rect/window is in, to let it do the right thing. Or we just >> recommend that people don't use Qt image loaders and use their own stuff >> that converts the format to whatever QImage wants. Either way it has to be >> decided before Qt5 because I think it's going to be very hard to shoehorn >> color managment in, in a completely BC way after Qt5. > > Passing one colorspace per window is not enough if it contains several > different images. > X Color Management > (http://oyranos.org/scm?p=xcolor.git;a=blob;f=docs/X_Color_Management.txt, > formerly net-color spec) does it per rect, but this might be a problem if you > use some effects (blur the border of the image, transparency, ...). > > Maybe it is worth to have a look how Gnome does it. In > http://libregraphicsworld.org/articles.php?article_id=42, Richard Hughes says: > > I've considered using some of the existing net-color spec by Kai-Uwe, but I > think a lot of the existing spec is just wrong and adding things like network > transparency means we introduce a huge number of issues that I don't think we > want to support. I also want to make it super easy to opt-in or opt-out > widgets (and windows) from this FSCM and the net-color spec doesn't exactly > make that easy without defining manual opt-out regions that doesn't work so > well with moving, resizing, reshaped widgets in modern toolkits. > > If the windowing system only has access to the completely rendered client > window (this is how it works with wayland, isn't it?), I think color > management has to be done by the client toolkit. Could this deal with multi- > head setups? > Otherwise, passing the color space information to the windowing system might > be better.
Agreed, it does sound like color management needs to be done by the client toolkit. From my understanding there are several aspects to correctly handling color spaces. The first aspect is storage / representation. Eventually we'll probably need image formats with more than 8-bits per color channel and potentially floating point as well to support Deep Color and extended gamut color spaces like xvYCC. QImage's Format enum kind breaks down once we want to support variable bit depths and floating point formats, so a new approach with generic storage and color space descriptors might be useful there. A question is whether we want these image formats to be paintable with QPainter. Another aspect is presentation of this content on a screen visible surface, which is abstracted in Qt 5 by the QWindow class. We now have two approaches for getting content onto a QWindow, QBackingStore and QOpenGLContext. QWindow has a QSurfaceFormat, which might already be able to support bit depths beyond 8 for the color channels, but which doesn't have a say about color space. Currently the assumption is typically that the final QWindow content should be in the sRGB color space. The third aspect is doing color space aware blending, antialiasing, sampling, conversions etc. OpenGL already has some relevant extensions for sRGB content, namely GL_ARB_framebuffer_sRGB and GL_EXT_texture_sRGB. Maybe scene graph / QML 2 should be using them behind the scenes on desktop when appropriate. It might be possible to handle other color spaces than sRGB with fragment shaders. For QPainter on a QImage this might be too computationally expensive however (we already ignore sRGB and treat everything as linear in our current rendering pipelines, both raster and OpenGL). The first aspect, storage, seems to me to be the trickiest one, as it would require API changes in QImage or a new image class (which would then not play as nicely with existing Qt APIs like QPainter). -- Samuel _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
