On Wednesday 11 January 2006 01:01 pm, Gerhard Fuernkranz wrote: > > --- Ursprüngliche Nachricht --- > > Von: Bob Friesenhahn <[EMAIL PROTECTED]> > > An: "Hal V. Engel" <[EMAIL PROTECTED]> > > Kopie: lcms-user@lists.sourceforge.net > > Betreff: Re: [Lcms-user] LPROF 1.11.1 developement snapshot released > > Datum: Tue, 10 Jan 2006 16:21:47 -0600 (CST) > > > > Using a gamma of around 2.2 (or 2.6 for X'Y'Z') tends to linearize the > > luminance significance of each bit (particularly for dark regions) so > > fewer storage bits are necessary, and computational errors are > > reduced. > > Is my understanding correct that the lprof color picker > still can handle only 8bit per channel? (-> i.e. load the > image into a QImage, and then pick the measurements from the > QImage, where QImage only supports 8bit) If so, then I would > not recommend to use gamma=1 until this is fixed. A precision > of 8bit per channel is IMO insufficient for gamma=1 images. > > Regards, > Gerhard
I just had a look at the code and also added some debugging code to confirm exactly what is going on. QImage can handle bit depths greater than 8 bit/channel and defaults to a pixel bit depth of 32 (which is really 10 bit/channel). This is also the max bit depth it supports. The constructor for QImage is: QImage::QImage ( int w, int h, int depth, int numColors = 0, Endian bitOrder = IgnoreEndian ) Where depth can be 1, 8, 16 or 32. When I print out image.depth() for the QImage being used by the picker it is 32 bits. But in the loop that is picking the values if I filter out all rgb values < 255 I don't get anything. So QImage is effectively remapping the 16 bit/channel image as an 8 bit/channel image. In another note to the list Bob Friesenhahn wrote: "A potential solution to this problem is to gamma correct/translate values associated with the color picker. That way the color picker always operates with gamma = 2.2." This might work but the correct solution is to set this up so the picker operates on the raw image data at whatever color depth that data has. In fact this is an absolute requirement as far as I am concerned as at this point QImage is changing the data of 16 bit/channel images in the process of loading the image and this in effect introduces what could be (likely are) significant errors into the process. This change to how LPROF works could be fairly involved but it needs to be done and I will add this to my enhancement list and give it a very high priority. This was a good catch by Gerard as I had totally missed what was going on with this part of the code. These development snapshots are being released in the hope that problems/limitations and the like will be found so that these can be corrected. I hope you will keep providing valuable feedback like this so that LPROF will continue to improve. Hal ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
