On Nov 12, 2011, at 3:29 PM, Quincey Morris wrote: > On Nov 12, 2011, at 14:01 , James Merkel wrote: > >> d' = a * s + (1 - a) * d >> All premultiplication does is precalculate a * s." >> >> First question -- what is d' in that equation? > > It's the result of compositing the source (your image) onto the destination > (the background). > >> I read images from files and create histograms from them using pixel data >> from the NSBitmapImageRep. >> Things seem to work ok except for images that have an alpha channel (that >> is, bitsPerPixel = 32 from the NSBitmapImageRep, and an alpha channel is >> present). >> The histograms in that case have gaps in them (certain levels seem to be >> under-represented). > > Histograms of what? Color component distributions? How do you determine that > levels are under-represented? If the pattern of gaps is regular, that > probably means that the original image data was up-sampled at some point in > the process of delivering the data to the bitmap image rep. > >> Some specific images with this problem were downloaded through Image >> Capture and rotated in Image Capture. >> When an image is rotated in Image Capture, apparently the pixel data is >> rotated and the Exif Orientation tag is changed to reflect the rotation. >> (This is different from what I thought Apple said in previous documentation. >> I thought just the Exif Orientation tag was changed, and it was up to the >> image display program to rotate the image). >> Anyway, after rotation, the order of the data is ARGB, whereas before the >> rotation the order was RGBA. > > In a sense, the pixel order is is irrelevant -- it only matters if you're > going to operate on the image pixel by pixel, so that you can decode the > pixel components. > >> Also, before the rotation, the alpha channel appears to be just an unused >> channel >> -- i.e. it's not really an alpha channel. > > What do you mean by unused? If the pixel format says there's an alpha > channel, there is one. Are all the alpha channel values 1.0? I'd imagine that > something captured via Image Capture would be fully opaque. > >> Two additional questions: are the pixel data premultiplied with the alpha >> channel? > > Yeah, presumably. > >> Also, for a histogram, should the data be premultiplied with alpha? That is, >> should the histogram reflect the alpha? > > Typically, you'd expect not. That's why premultiplied data sucks if you need > to analyze or manipulate the pixels. You can always recover a > non-premultiplied value, but there's a loss of precision involved (more > pronounced as the alpha heads towards 0), so it's better to get hold of the > un-premultiplied data. > > Of course, if all of the alpha values are 1.0, then a * s == s everywhere, > so the question of premultiplication is moot. > >
Yes, these are histograms of the color components. I think these histograms are wrong because I looked at the histograms generated by two other programs, and they don't show those gaps. Either they are wrong or I am wrong. Agree, pixel order doesn't matter. However, I only see the problem when the order is ARGB. By unused I mean the format is 32-bits per pixel, but the method hasAlpha on the image bitmap says there is no alpha. The color space is RGB, so I conclude there is an unused 4th channel. Also, using the mask NSAlphaFirstBitmapFormat says the alpha is not first. It (the unused channel) is last. Agree, for these images, the alpha value is always xFF which is 1. So it shouldn't matter. Jim Merkel _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
