(This question was already asked on Stack Overflow under the tags Matlab/Octave/Signal-processing/Image-processing, but I am reposting it here following the advice of one user that this site may be a more appropriate forum for such questions.)

Is it common/useful to generate an anti-aliased boolean mask for CCD image integration purposes ?

Let's imagine that I want to integrate the light that strikes a given area of a CCD sensor. The boundaries of this area correspond to physical coordinates that have no obligation to coincide exactly with the pixels of my CCD sensor.

In Matlab/Octave/(or even Scientific Python), the common algorithm used for integrating such an area is to define a boolean mask using a logical operation on an array, such as:

mask = R < radius;

(where 'R', and therefore 'mask', are 2D arrays and 'radius' is a float). Such a mask has values of 0 or 1.

I can then integrate the pixels that are comprised within the boundaries of my area by summing the masked image:

integrated_signal = sum(sum(mask.*image));

(where 'image' is the output of the CCD sensor, a 2D array with U16 values for instance).

However, mathematically speaking, nothing would prevent me from defining a continuous-valued mask, that is, a mask whose pixels could take any value between 0 and 1. Physically, this means that I could integrate portions of pixels. I could even compute such a mask using an anti-aliasing algorithm in order to create better approximations of non-square-friendly shapes such as circles (for integrating a signal with revolution symmetry, let's say).

My question to digital imaging geeks is the following: Is it standard practice to define such anti-aliased mask for integration purposes of imaging sensors ? Is it useful (as I suspect), or does it produce physically irrelevant results ?

  • $\begingroup$ Cross-posting on two or more Stack Exchange sites is discouraged. I can migrate the question from SO here instead. $\endgroup$ – Phonon Jan 27 '12 at 15:08
  • $\begingroup$ Thank you for your suggestion. Would it be possible to wait a few hours to see which of the two communities is more interested, and then migrate ? The question has already attracted one positive vote on the other site.. $\endgroup$ – calvin tiger Jan 27 '12 at 15:09

You're right: mathematically speaking, nothing would prevent you from defining a grayscale mask. Practically, it is not a good approximation of what is going on.

A mask value of 0.5 means that you'd count half the pixel value to your signal. First of all, this will require you to exactly estimate and subtract the camera offset, b/c adding half the offset is going to screw up your result. More importantly, this assumes that half of the signal value on your pixel must have come from somewhere else.

There are three sources for where your other 0.5 of the signal may have come from:

  1. If the source whose signal you're integrating is isolated, all the signal on that edge pixel will have come from your source of interest. So multiplying that by 0.5 is wrong.

  2. If there is a second source that also might contribute to the pixel, the proper ratio for dividing up the signal depends on the relative strengths of each signal, and on the relative positions of the center. While a grayscale mask makes sense here, you have to calculate it iteratively, since it depends on the signal integral.

  3. If there is noise on the sensor, you'd be claiming that the other 0.5 is noise. That's most likely wrong as well - you want to add the full noise to your signal so it averages out properly (that can be a bit of an issue with #2).

This is why I have never encountered grayscale masks except for case #2. In addition to being a bad approximation to reality, grayscale masks are less convenient to handle. With logical masks, you can, for example, conveniently write

integrated_signal = sum(image(mask));
  • $\begingroup$ Thank you for this very insightful answer :) You've answered most of my questions.. $\endgroup$ – calvin tiger Jan 30 '12 at 8:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.