• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSBitmapImageRep and alpha channel
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSBitmapImageRep and alpha channel


  • Subject: Re: NSBitmapImageRep and alpha channel
  • From: Quincey Morris <email@hidden>
  • Date: Sat, 12 Nov 2011 15:29:19 -0800

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.


_______________________________________________

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

  • Follow-Ups:
    • Re: NSBitmapImageRep and alpha channel
      • From: James Merkel <email@hidden>
References: 
 >NSBitmapImageRep and alpha channel (From: James Merkel <email@hidden>)

  • Prev by Date: Re: Calling a Cocoa library from C
  • Next by Date: Re: NSBitmapImageRep and alpha channel
  • Previous by thread: NSBitmapImageRep and alpha channel
  • Next by thread: Re: NSBitmapImageRep and alpha channel
  • Index(es):
    • Date
    • Thread