On Sep 26, 2011, at 6:19 AM, ext Zack Rusin wrote: > 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.
Yeah, I would eventually like to us to have proper color space support. The problem with putting it into QImage is that QImage comes with a lot of baggage. Integration with QPainter, existing code that relies on bits()/bytesPerLine() access. It is not a simple fix to restructure QImage into a pluggable imagedata class, and it would not plug directly into existing code in a source-wise nice manner. 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. So because of this, I would prefer if we stared the such an camera-data image class in an addon. If it becomes a good and lean class, then maybe we deprecate QImage/QPixmap over time and replace it with this and migrate this class into QtGui. I wouldn't have a problem with that. >> 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 Yup, I was never happy with how the QPixmap / QImage split turned out. In QML 2 we at least stopped using the QPixmap class. - Gunnar _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
