Re: NSBitmapImageRep and alpha channel
Re: NSBitmapImageRep and alpha channel
- Subject: Re: NSBitmapImageRep and alpha channel
- From: James Merkel <email@hidden>
- Date: Sat, 12 Nov 2011 16:34:40 -0800
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@hidden)
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:
This email sent to email@hidden