Tiny Centroid script

[Nocturnal]

Hi,

for some time I've suspected that my CCD isn't properly centered in my camera. The only way I know to really measure this is to determine the centroid of a flat frame. So this was a good opportunity to write a simple PJSR script that calculates the centroid (center of gravity) of the currently selected image. It works on both RGB and mono images but the result isn't the same so I'm probably not doing the right thing when using color. Something like an on the fly L extraction for RGB images would probably be useful. Anyway, I don't think this is a script that will be run a lot so you can extract L from your flat before running the script.

I think this script is a useful demonstration of a trivial script that cycles through all pixel values. Nothing complicated but it shows how you get access to all pixels and do something with the values you find.

Code: [Select]

/*
   Written by Sander Pool, Aug. 2010
*/

#feature-id    Utilities > Centroid

// reference: Handbook Astronomical Image Processing by Berry and Burnell
// page 218
//

function CalcCentroid(img) {
var sum_x, sum_y, sum_pix;

sum_x = 0;
sum_y = 0;
sum_pix = 0;

var height = img.height;
var width = img.width;
for (y=0; y < height; y++) {
for (x=0; x < width; x++) {
A =  img.sample(x, y);
sum_pix += A;
sum_x += (x * A);
sum_y += (y * A);
}
}
console.writeln("Center X:" + img.width/2 + " Centroid X:" + sum_x / sum_pix);
console.writeln("Center Y:" + img.height/2 + " Centroid Y:" + sum_y / sum_pix);
}

function main()
{
// Get access to the current active image window.
var window = ImageWindow.activeWindow;
if ( window.isNull )
throw new Error( "No active image" );

console.show();
console.writeln( "<end><cbr><br><b>" + window.currentView.fullId + "</b>" );
console.writeln( "Running Centroid code. May take a few seconds for large images." );
console.flush();

console.abortEnabled = true;
var img = window.currentView.image;
var E = new CalcCentroid( img );
}

main();

// ****************************************************************************
//


[Nocturnal]

I should add that my CCD isn't as off-center as I feared:

Processing script file: C:/astro_disk/sander/src/PJSR/Centroid.js

MasterFlat_ISO0_RGB_L
Running Centroid code. May take a few seconds for large images.
Center X:1520 Centroid X:1507.0738241984864
Center Y:1008 Centroid Y:1009.191848662481

[NKV]

I should add that my CCD isn't as off-center as I feared:

Also, check Flat with different filters.
Because I think your CCD at-centre. But, CCD have non-uniform of sensitivity through geometry of wafer.
Look at my Flat and result from Centroid Script:

Flat_Ha_calib_35c_10s_halogen_2010_07_13
Center X:2048 Centroid X:2039.8185989632648
Center Y:2048 Centroid Y:2054.4309281563305

Flat_O3_calib_35c_10s_papir_2010_07_13
Center X:2048 Centroid X:2042.9223611389955
Center Y:2048 Centroid Y:2049.8840917972484

Flat_S_calib_35c_10s_halogen_2010_08_12
Center X:2049 Centroid X:2056.0368247163065
Center Y:2049 Centroid Y:2057.5239569608093

Flat_B_calib_35c_10s_papir_2010_08_12
Center X:2049 Centroid X:2052.9203623274875
Center Y:2049 Centroid Y:2039.1039695512025

[Enzo De Bernardini]

Interesting, and good code example. Thanks Sander. I did some tests with synthetic radial gradients (see attach), moving off center in x-axis the focal point, and can be seen clearly in the script output.

IMG1
Center X:125 Centroid X:124.50000324359335
Center Y:125 Centroid Y:124.50000326127018

IMG2
Center X:125 Centroid X:118.18814896205807
Center Y:125 Centroid Y:124.50001765223229

IMG3
Center X:125 Centroid X:111.87607174819941
Center Y:125 Centroid Y:124.50005628273026

Regards,

Enzo.

[Nocturnal]

Thanks guys for giving the script a try. Good test Enzo

NKV: I have an OSC camera so I don't use filters but you are right, it's a good idea to check each flat if centering is a concern. Indeed response to light (QE) isn't necessarily uniform all over the CCD. Applying a flat takes that into consideration though. At the same time it may cause you to draw incorrect conclusions based on this script. I suppose you could create a flat without an OTA and do wavelet extractions to look for patterns in the supposedly uniform image. Of course you have to be very certain that your light source is flat.

[NKV]

Offtop

I suppose you could create a flat without an OTA

A pixels near edge will collect less photons without OTA, because there are vignetting at camera body.

So with previous camera (it was PL9000, now PL16803) I done simple test(cover glass inspection and dust catching) via simplest OTA (Pin Hole Camera 900mm/1mm  8) ) How to build the OTA see in AIP4WIN Book.

Look at result 
1) FLI ProLine shutter open.
2) Flat 90sec via 900??/f900 (nice non uniform QE over the CCD)
3) Crop 100% (nice dust dust from manufacture? Yes, camera was new! I immediately send it back for upgrade on PL16803 )

Late, I found that QE uniformity over CCD depend on wave length. So, to take good flats for all my filters I use different light sources. And twilight is not best one.

[Carlos Milovic]

Hi Sander

The problem with the centroid, is that given that you don't have enough data around every side of the maximum, it will give you a sesgated result. So, one workaround is:
- Calculate the centroid with the whole image. "Store" the point in a variable.
- Create a region around the previous center (try to not go out of boundaries), and calculate the new centroid, and the difference with the previous one.
- If the difference is grater than a certain amount (for example, 0.05px), repeat the procedure (and you may shrink the region)

This should get you closer to the peak (of course, all of this is assuming that the global "peak" is a good estimation of the off-axis deviaion)

[Carlos Milovic]

BTW, I was thinking that maybe, for a more useful script (instead of the iterative appoach), you may just include parameters for a user defined region of interest, and calculate the "mass center" there.

[Nocturnal]

Hi Carlos,

that's interesting. Why would image scale affect centroid calculation? It's after all the same as a center of gravity problem which doesn't have different calculations for boulders and pebbles. I'll make the change you're suggesting but if the difference is less than half a pixel I don't think the extra work is worth it for this exercise. I'd be happy with a 1 pixel resolution answer for this purpose

Parameters are nice but they involve GUI elements and that's not so nice

[Nocturnal]

Nikolai,

I've taken images with my camera resting on my EL sheet with diffusers. I'm pretty sure the lighting was uniform or certainly very close to it. Every point of the EL sheet that can shine into my camera can be seen by every pixel of my camera so I don't think there's vignetting in my case. Still I'll go have a look at the book for the camera obscura.

[Carlos Milovic]

Why would image scale affect centroid calculation?

It is not the scale, it is the inclusion of pixels with non zero values. For that reason, if you want to use the centroid as a estimator of the peak response it does matter the region of interest. For example, if you use the centroid to determine the center of a star, you'd better  place the region of interest close enough to the real center, or apply a threshold to eliminate low values pixels, or the result will be outside the star

[Niall Saunders]

Hi Sander,

First, I'll need to re-read that particular section of HAIP (tonight, maybe).

In the meantime, if you take several EL flats, and simply Average combine without any clipping, and if you also include a 'rotation' of the EL source/diffuser during the acquisition of the Flats, would this not eliminate any of the 'noise' (i.e. 'uncertainties') in the final MasterFlat (as would MasterBias calibration as well). Then, surely, the resultant 'calibrated' MasterFlat has to be as close a representation to the illumination field as is possible.

Which 'must' then allow the suggested script to provide meaningful results - wouldn't it?

OK - so if you leave 'glass' in the imaging train, then the effects of this will have an effect on the calculation of the centroid - and comparing the results between 'with glass' (i.e. your OTA/Camera Lens of choice) and 'no glass' (i.e. a pin-hole) should show if the centroid does shift.

What about a diffused EL shining through a pin-hole onto the CCD? Would that provide the best 'reference' centroid to work with?

What is the purpose of 'knowing the centroid coordinates' anyway? It would be doubtful that they could be adjusted post manufacture (probably not even DURING manufacture). Let's say that manufacturing tolerance is of the order of ⁵/₁₀₀₀ths of an inch (say 120µm) - with a CCD pixel size of, say, 6um this would suggest that the 'centroid' should be somewhere inside a 20-pixel diameter circle. Which would be within 1% tolerance on a 2000 x 2000 pixel CCD array.

I certainly wouldn't be too concerned about that amount of 'loss'. Heck, I loose more than that just due to long-term differential flexure during an evening.

But, I suppose 'knowing' what the problem or error actually 'is' is actually useful enough in its own right. It helps 'tie-down' yet one more variable in the never-ending struggle to get a decent image - certainly from the mud I usually dredge up from outer space, anyway

Which is why I would still like to be able to "Inspect the CCD" on my imagers - but using the power of PI rather than some other software.

Cheers,

[Nocturnal]

Hi Niall,

like I said I've been suspecting my CCD is off-center and I wanted to measure how much it really was. The reason this is important is that I use my CCD for aligning my telescope and if I center the star on the image but that's not really the center of the optical axis then my alignment accuracy suffers. So that's the back story

Besides that It's simply something I've been wanting to try. As Carlos pointed out it's not quite as trivial as I made it out to be. In fact I'm pretty sure now that the centroid of an image doesn't coincide with the 'top of the mountain' for an off-center CCD. I did a simple experiment to prove this. I twice subtracted the mean from the image with PM: $T-mean($T) . This resulted in a black image with a light patch in the center, the top of the hill. This looks a lot more like a star than the original image. Now the centroid is:

MasterFlat_ISO0_RGB_L
Running Centroid code. May take a few seconds for large images.
Center X:1520 Centroid X:1464.452386664131
Center Y:1008 Centroid Y:997.0116281384858

This is much more like what I expected to see. I subtracted the mean twice to make sure the 'hill' was surrounded by black pixels. So this makes the script a bit more complex unless I leave the image preparation to the user. That's fine for me as this is simply an experiment but not so good for a 'production' script.

The other thing I want to do is add an 'x' on the physical center and the centroid. That seems a bit involved so I'll probably stick with printing coordinates.

[Nocturnal]

Don't you just love how such a trivial exercise can snowball into a better understanding of how things -really- work

The first script has the correct name and correct implementation to calculate the centroid (center of mass) for the image. That doesn't mean that this is what I really wanted I wanted the optical center of the image which, as Carlos pointed out, is not calculated this way. In fairness to HAIP it did not suggest it this way either. I subtracted the area mean from the pixel values if I recall correctly. In other words it assumed you already knew approximately where the star center was and make sure it's surrounded with dark pixels.

So.

As an experiment I subtracted the mean from the image without rescaling and ran the script again. I actually had to subtract the mean twice (not the same as subtracting 2*mean) to make sure the central bulge was surrounded by black pixels. So I figured I might as well try subtracting mean three times. Oops! Not the same centroid.

# 3x mean
MasterFlat_ISO0_RGB_L_clone1
Running Centroid code. May take a few seconds for large images.
Center X:1520 Centroid X:1464.452386664131
Center Y:1008 Centroid Y:997.0116281384858

# 2x mean
MasterFlat_ISO0_RGB_L_clone
Running Centroid code. May take a few seconds for large images.
Center X:1520 Centroid X:1464.5874965695948
Center Y:1008 Centroid Y:991.0612373909435


To me this means that the central bulge is not symmetrical. Subtracting the mean zeros out more pixels on one side than the other. This is unexpected and I can't quite explain it yet. Could be an optical artifact (C11/Hyperstar 3) or camera sensitivity isn't uniform.

As long as my flat source is truly flat this all doesn't matter, my flats will correct whatever optical and CCD artifacts there are. Still it would be nice to understand this better.

I'll try to integrate pixelmath into the script to get the script more like what it's supposed to do.

[Carlos Milovic]

Hi Sander

Now that you are calculating pixel values distributions... you may consider to calculate "higher momentums":

E[(x-x0)^2] This is the variance of the image. The root square is the standard deviation, and will give you an idea of how spread are the pixel intensities (not that much usefull here... but the higher momentums may work better)

E[(x-x0)^3] This is the skewness. Will tell you the assymetry of the distribution. The sign of this value will tell you if the maximum is at the left or right of the centroid.
See here for more details: http://en.wikipedia.org/wiki/Skewness


E[(x-x0)^4] This is the kurtosis. Will tell you rougly hoy flat or peaked is the distribution. This may be a good indicator of how important is the flat for large scale illumination correction.


Bottom line, I think that the skewness will be a good indicator (if you want to measure the whole image) of the assymetry of the flat.

Other, more crude options, but faster (for a live tool, for example, to center the ccd to the optical axis) could be a simple difference between the right/left top/bottom halfs of the image (the mean values). Or, if you feel lucky, apply a median filter or a soft low pass filter (gauss with small stddev) and then do a search for the maximum.