On Nov 12, 2011, at 4:34 PM, James Merkel wrote:

> 
> 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
> 
> 

This is kind of interesting -- if I rotate the image in Preview (rather than 
Image Capture), then the histogram looks normal.
Looking at the NSBitmapImageRep from Preview image, the order is RGBA and there 
is no reported alpha channel.
Furthermore for the Preview rotated image, the Exif Orientation tag says normal 
(horizontal), and the width and height are reported correctly.
For the Image Capture rotated image, the Exif Orientation tag says rotated 90 
degrees and the width and height are reversed (i.e. not reported correctly).
I think Preview is doing the right thing and Image Capture is doing the wrong 
thing.
Why I get a bad histogram from the IMage Capture rotated image I'm not sure.

Jim Merkel

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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 arch...@mail-archive.com

Reply via email to