Alpha Channels ???

[Niall Saunders]

Alpha Channels - what are they all about ?

I understand R, G and B as three channels of a colour image, and Lu as the 'only' channel of a monochrome (or greyscale) image.

I 'think' I understand the Alpha channel - of 'any' image, colour or mono - as the 'repository' of a 'mask' associated with that image. Am I right?

In other words when you make an image to be used as a 'mask' for another image, and then associate the mask 'to' an image, the 'mask' image gets stored in the Alpha channel of the 'masked' image. Correct ?

If not, then what does the Alpha channel contain?

What ELSE can the Alpha channel contain?

How else can the Alpha channel be used?

Which image formats can be used to 'save' the Alpha channel?

So many questions . . . . .

[Juan Conejero]

Hi Niall,

In PixInsight/PCL an alpha channel is, by definition, any channel in excess of the nominal channels. Nominal channels are R, G and B for RGB color images, K (blacK) for grayscale images.

As seen by the PCL, an image is just a vector of matrices, or a data cube if you prefer a more geometrical interpretation instead of a purely structural view. Each channel is a matrix whose dimensions are the height (=matrix rows) and width (=matrix columns) of the image. Each channel (a.k.a. plane) is a different matrix, so we actually have a stack of matrices, or a sliced cube.

A completely different thing is how these data structures are interpreted, and how are they related to specific properties of the image as a whole (separate data and functions, the object-oriented thing again ). For example, nominal channels are directly related to the color interpretation of pixel data, and as such they play an essential role in all functional blocks related to color spaces: from luminance/chrominance separations, to color management transformations, to screen renditions.

The first alpha channel, if it exists, defines the opacity of each pixel. When alpha is 1, the pixel is opaque, and when alpha is zero, the pixel is completely transparent. Intermediate alpha values define partial transparency. Contrarily to what is customary in most imaging applications, opacity has nothing to do with masks in PixInsight. Again, I decided to keep both functional subsystems -masking and pixel opacity- separate and unrelated, for the sake of versatility and efficiency. As you know, a mask is any image selected as such in PixInsight. This means that masks are always external components of masked images, which is much better in terms of modularity (you can replace/modify an image's mask without changing the image) and reusability (a mask image doesn't know that it's being used as a mask).

The fact that the first alpha channel (which we call active alpha channel) defines opacity is just a convention, observed to keep compatibility with other imaging applications. Pixel opacity is essential to embed images in other high-level objects, such as documents. For example, you can define an alpha channel to make the background of an image transparent when it is placed within a page in a page layout application (Scribus for example) or in a graphics editor (Inkscape for example).

The most important image formats fully supporting pixel opacity via alpha channels are TIFF and PNG. Notably, the JPEG format does not support alpha channels.

[Niall Saunders]

Thanks for taking the time to clarify the inner workings of PI once again Juan.

So, are the number of 'extra' image planes 'restricted' to just a single alpha channel, or can an image have an arbitrary number of such channels?

Apart from 'opacity' which, as you described, is already associated with the 'first' alpha channel, are there any other conventional uses for subsequent channels?

Given that the FITS standard can actually support an (almost) infinite number of such image planes (constrained only by common sense and, I believe, a 16-bit integer format), can the alpha channel(s) be stored in the FITS format? (Do we need, in fact, to be able to do this anyway - given that I have yet to see an astronomical use for these 'supplementary' channels?)

Cheers,

[Juan Conejero]

In PixInsight, additional alpha channels (in excess of the active alpha channel) have no specific purpose, so they are treated just as "pixel data". Other applications may behave diferently, of course.

As for FITS, it indeed can store an arbitrary number of channels for any image. The problem with FITS is that is lacks a standardized way to store multichannel image data. Actually, FITS doesn't define any standardized way to store anything beyond image dimensions and some basic data types (others call that "flexible"). PixInsight's FITS implementation stores channels as additional "planes" of an image, indexed through its third dimension. Other softwares store multichannel pixel data in different ways. For example, there are applications that store each channel as an independent image (so each channel has a separate HDU), which I personally think is illogical, or even as FITS extensions associated to the image...  there is no standard, so everyone has good reasons to do it in a particular way.

Storing alpha channels in a FITS image is OK, but since no graphics editors or page layout applications can handle FITS (as far as I know), it makes little sense to store alpha data if it is intended to define pixel opacity, except for private storage.

Alpha channels can also be used as generic pixel containers. For example, future versions of PixInsight will allow you to specify if alpha channels are to be interpreted as opacity masks or as pure pixel data. In this way you'll be able to store multichannel images beyond RGB, as images acquired through an arbitrary set of filters (for example, RGBHaOIII as a five-channel image), and processes will be able to manage the data as a single unit. This is just a project, and I have no exact definition of how this will be implemented and its repercussions, but I think this is a logical development path in PixInsight.