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. Regards, Ole
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
