On Monday, September 26, 2011 03:06:38 AM [email protected] wrote: > The primary usecase for non sRGB color data is camera data and if you are > looking at camera data, then you probably also want to add other things > like timestamps, geo-tags and other metadata, which would make QImage an > even uglier mixture of concepts.
That metadata isn't terribly interesting and there are other ways of embedding it, so I'm not interested or worried about it. The issue is that Qt is flat out wrong when it comes to displaying the images. E.g. http://www.gballard.net/psd/srgbforwww.html The snafu is that pretty much all of the flicker images will be coming with a color profile, which we're going to consistently ignore, meaning that more and more images on all Qt constructed browsers will look at best wrong (and often just shitty). So it's not a question of extra features, it's a question of correctness. 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. z _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
