Post by Niels Ole SalscheiderHello,
Post by Zack RusinEven 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
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