On Friday, September 23, 2011 04:25:26 PM [email protected] wrote:
> Hi Niels,
> 
> while I very much would like to see some code to do advanced color space
> management in Qt, I am unsure whether this should go into QtGui or into an
> add-on module.
> 
> The reason is that adding this and other image formats can easily blow up
> the size of the Gui library a lot.

It would have to be both if we wanted proper support, with QtGui, depending on 
the addon module. We could get away with a very limited support in QtGui and 
it could probably be enough for most use cases. The most prevelant use case 
for Qt will be displaying images, most of them coming from the web. Cameras 
now embedded pretty accurate color profiles with pictures. Granted that WebKit 
would need to be fixed first but Qt would just need support for telling some 
external entity to interpret the given screen estate as the following color 
profile.
It's probably one of the two things I'd like to fix. In general we don't do a 
very good job or respecting color spaces, we mix linear rgb with srgb pretty 
freely right now.

> In addition, I'd also prefer to see how color management on a desktop
> environment would be done. Simply adding this to QImage is not enough,
> esp. since many things (QML, QPixmap, QWidget) don't even go through
> images.

Yea, btw, it would be nice  to eliminate the QPixmap/QImage split for Qt5. 
Just do a QImage/QImageData split with the latter letting people access the 
actual data and synchronous functions used to fetch the QImageData from  
QImage. Maybe with wrapper classes to imitate the old behavior (so maybe call 
it QSurface/QSurfaceData or something to not take over the QImage name) we 
could stay source compatitible and eliminate that pretty arbitrary, for most 
people, split. 

z
_______________________________________________
Qt5-feedback mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

Reply via email to