SharpCap Forums

Hi Robin,

The new / improved functions work well (but not yet tested under real sky, as the clouds are permanent ... ).

Cheers

Christian

Hi,

first of all, I'd like to apologize for my English - maybe what I write sometimes sounds less appropriate/different than I mean it. I'm sorry.

I've tried the function, it works really well. I especially appreciate the variability, such as the possibility to choose the frame and the size in which the object is measured. By simply dragging the frame, I can choose exactly which and how many objects I'm going to measure. This is excellent. I realize, or rather believe, that it is impossible to write any program that does completely accurate photometry for data obtained in this way. I mean of short exposures, distorted shapes in star images by seeing, and low SNR, the conditions we have when observing occultations. Therefore, in my opinion, it would be advisable to try to measure the data with a much better SNR . I think it would then be easier to construct a light curve from data with better SNR. This might be partialy answer to the first post in this thread by TimH. I'll definitely try the function with higher SNR myself, but I'd like to ask you to join in if you can.
I would also like to ask how the SNR is calculated in the current version of this feature.

For me personally this feature is highly useful already. Thank You.

Cheers,

Peter

Hi Peter,

the very latest code 4.0.8439 uses this approach to calculate SNR

1) Find the star. Do ensure the star is not saturated otherwise the following calculations will be incorrect.
2) Take the area around the visible part of the star to make a box in which all other calculations are based. Not 100% happy with how this is done, but as long as the box clears the star by enough to make the majority of the area of the box dark rather than star, all will work
3) Estimate the local background ADU level based on the median value of pixels in the box (assuming >1/2 are black) [BACKGROUND ADU]
4) Calculate the maximum pixel value less the background ADU [PEAK LUM. ADU]
5) Subtract the background ADU level from all pixel values in the star box, smooth the resulting data and then sum to get the total ADU in the star above the background level [TOTAL ADU]
6) Calculate the FWHM (actually half flux diameter) of the star based on the background subtracted brightness values
7) Calculate the number of electrons equivalent to the TOTAL ADU in step 5 based on the camera's e/ADU [TOTAL e-]
8) Calculate the number of electrons equivalent to the BACKGROUND ADU from step 3 based on camera e/ADU [BACKGROUND e-]
9) Calculate the area of a circle with radius equal to the star FWHM (diameter therefore 2xFWHM). Multiply this by BACKGROUND e- to give an estimate of the total number of background electrons in the star area [TOTAL BACKGROUND e-]
10) Calculate the SNR as SIGNAL/NOISE where SIGNAL=TOTAL e- and NOISE=SQRT(TOTAL e- + TOTAL BACKGROUND e-)

Note that the calculations currently do *NOT* include read noise estimations, but that would not be hard to add.

cheers,

Robin

Hi Robin,

thank you for your reply. I'll study it better, try it out in practice and definitely share my findings.

Cheers,

Peter

Hi Robin,

I use the "Stellar Photometry Estimation" function all the time when observing asteroid occultations. When observing, I try to have the target star in the center of the displayed field, as most occultation observers probably do. For the best time resolution, I choose the shortest exposure time = highest fps (even a few tens of fps), but so that the star is sufficiently saturated.
Since no one has written anything on this topic for a long time and I know there are several occultation observers here, I would suggest this modification.

1)When running the function, show from the beginning an area in the center of the star field with dimensions of say 50 x 50 pixels.

2) Limiting the display of selected values (e.g. estimated SNR) to a frequency of say 1 to 2 times per second*.

*) Since we often use quite high fps, the displayed values are hard to read. Therefore, in my opinion, it would be advisable to limit the display frequency to a maximum of 2 times per second.

Higher fps camera readout could be used to average the measured values, which would probably increase the accuracy of the displayed measurements.
Of course, this is just my suggestion, so I'd like more SharpCap users to comment. (sorry for my english)


Thank You.

cheers,

Peter

Hi,

yes, the idea of averaging (if possible) or at least slowing down the update makes sense - I will note it down on the todo list.

I'm not so sure about the need to start with a selection area - that's just reducing one button click isn't it (I think the area of selection should be remembered from last time, so you just need to press the button to turn the ROI function on).

cheers,

Robin

Hi,

I tried this feature last night and it works exactly as you wrote (after save to the 'Capture Profile') :

I'm not so sure about the need to start with a selection area - that's just reducing one button click isn't it (I think the area of selection should be remembered from last time, so you just need to press the button to turn the ROI function on).

Thanks.
Peter