On Monday 16 July 2012 18:25:20 Christoph Feck wrote: > On Monday 16 July 2012 17:42:45 alessandro.port...@nokia.com wrote: > > (Sorry for top-posting, as-well) > > > > Great to see Qt soon supporting color profiles! I agree with Johan > > that color profile handling and conversion should be an opt-in > > feature. > > I agree with the previous posters that any color correction should be > in control of the application author. A single "convert to appropriate > colors for screen/printer" call is nothing compared to the trouble of > automatic conversions that cannot be undone, or only undone with loss > of quality.
All QPainter operations (at least in the raster engine) assume a linear color space. That means that the color conversion need to hapen last, right before being shown to the screen. After all kind of blending operations or anything done with QPainter. (That means it could even been done in the platform plugin) Color conversion should probably also happen when loading images, to convert them to a linear color space. Right now, Qt do no handle color profiles at all, so it interpret png for example as plain linear RGB instead of sRGB. I think QImage should always contains linear color space. > > Just a few questions: > > 1) Would Qt use (and ship) a color conversion library, or would the > > system library be used where available (e.g. on OSX and Windows)? > > Regarding native platform support, we should work together with > Oyranos developers. While their API is horrible (maybe because it is > so non-Qt'ish), they have in-depth knowledge about the theory and the > praxis of color management. Maybe with their expertise, we can create > a nice API for application developers to interface the platforms. I'd say Qt should use an external library for that. This problem has already been solved, and there is no reason to reinvent the wheel. That said, I'm saying that without knowing what are the available libraries. > > > 2) Would the screen color profiles that are specified in the > > system screen settings automatically be used? 3) Sometimes, there > > are different profiles defined -one per screen (and printer)-. > > Would we have an additional parameter to specify the screen id? > > Color correction opens another can of worms: Qt only supports 8 bit > per component images, which was state of the art twenty years ago. > > Having QImage support at least 16 bit per component would not only > increase precision when doing conversions, but also allow it to load > "modern" image formats, such as PNG, PBM, TIFF, EXR, JPEG-LS, > JPEG-2000, etc. (I am not talking about pixmaps or rendering here, the > final result may be displayed at 8 bit precision, but internally Qt > needs more depth when it comes to correctly colored images). > > Also, the new printing framework in Qt should use the new > QtColorManagement module, so some coordination with experts would be > needed. Are 32 bit ARGB is not enough for what Qt is doing? That is: show an UI on the screen. If you want to do professional image processing you would probably not use QImage, but one of those specialized image processing library that have 16bit per chanel or more capabilities. I mean: Qt has always messed up sRGB and RGB and the difference is very visible, and still very few people complained. Why would one care about more bit accurancy where there is no visible difference? -- Olivier Woboq - Qt services and support - http://woboq.com _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
