View Issue Details

IDProjectCategoryView StatusLast Update
0002018CCdcielGeneralpublic19-03-20 18:20
ReporterCedric Raguenaud Assigned ToPatrick Chevalley  
Status resolvedResolutionno change required 
Product Version0.9 
Target Version1.0 
Summary0002018: In place autofocus doesn't find stars. Move to star autofocus does
DescriptionAutofocus behaves differently depending on whether "stay in place" is selected or not. With "stay in place" autoficus fails to find suitable stars every time.
Steps To ReproduceI haven't found in the code a reason for the following behaviour:
When I try to autofocus, if stay in place is selected, ccdciel never finds a suitable star. Even though there are stars in the image that were used without problem for calibration.
In exactly the same location (no mount move), if I select move to 4mag star before focus (a 3mag star is in the view but that's probably irrelevant), it finds suitable stars and autofocuses fine.
Additional InformationI'm using latest code from master.
TagsNo tags attached.


Patrick Chevalley

18-11-13 22:16

administrator   ~0005068

Just to be sure, you start autofocus by a click on the button? not from a sequence?

In this case when you check "slew to focus star" in the configuration it actually not slew but expect you already have centered a bright star, what you do with this mag 3 star. This is because this mode is mainly for testing the focus and it can be irritating if it slew at every test.

But the star detection strategy is still very different in the two case to reflect what it will do in a sequence.

When "stay in place" is checked:
- the program try to detect many stars of good quality
- it search only near the field center, a square the same size as the external circle of the bull eye
- it avoid stars with low SNR
- it also avoid the brightest stars that risk the saturation

When "slew to focus star" is checked:
- it search the brightest star in the image
- it frame the camera around this star to reduce acquisition time
- all the measurement are done on this single star
- it not check for saturation because you can select the star magnitude and exposure time that are safe. Also this mode is generally used with the Vcurve method that make the measurement on very defocused images and require a very good SNR when defocused, so maybe saturated when focused.

So what you observe is perfectly normal if the exposure time was good for the mag 3 star but too short to detect more faint stars around.
Generally "stay in place" require much longer exposure time.
Also with "stay in place" you must select the "dynamic" focusing method that require less defocusing than the Vcurve.

Do this make sens with your observations?

Cedric Raguenaud

18-11-13 22:23

reporter   ~0005069

What's strange is the slew to star autofocus (not from sequence) didn't focus on the brightest star. It focused on a small one fine.

At the moment I use slew to star with dynamic and it works OK (I'll check tomorrow morning if the focus was suitable) . As I can chose mag and exposure time I know what I get and I can make sure the star isn't saturated.

Patrick Chevalley

18-11-13 22:45

administrator   ~0005071

It can help me if you can save the image of a preview with the same exposure time you use for the focus and upload the fits file here.

Cedric Raguenaud

18-11-14 10:18

reporter   ~0005076

I've put a zip file with logs and failed focusing images from last night's activities here: (72MB)

I've also added screencaps of the focusing options below.
focus options.png (23,090 bytes)   
focus options.png (23,090 bytes)   
autofocus options.png (28,136 bytes)   
autofocus options.png (28,136 bytes)   

Patrick Chevalley

18-11-14 14:44

administrator   ~0005078

Thank you for all this files.
I make some testing by modifying the program to load your files instead of taking a control exposure.
For me, with your parameter, the program find enough stars to start the autofocus so we must search elsewhere.

I remark in your log that you are affected by a QHY Ascom driver bug we have tracked in 0001962
This bug make the full frame size returned by the driver to not take account for the overscan rows and columns. When the frame is set with this value the driver refuse to send the image after the exposure.

The problem here is the "stay in place" procedure use the "reset frame" function to be sure the focus image is taken full frame, so even you set the right frame size manually it is reset to the wrong value when the autofocus is started.
This is probably the reason for many exposure aborted we see in the log during autofocus.

When you select "slew to star" it work because in this case it not reset the frame size but set a ROI of 400x400 that work.

To fix this issue you need to get the new QHY driver/sdk that as an option to remove the overscan as show in this post:
I don't know why they make this optional as the driver crash otherwise ...

Can you look if this version is now available in the QHY web site? or ask them for this version.

If you want to activate more message in the ascom camera interface to look for this problem you need to edit the file cu_ascomcamera.pas, at line 5 remove the // before {$define debug_ascom} and recompile the program.

Cedric Raguenaud

18-11-14 14:59

reporter   ~0005079

I have that version of the drivers, but with the option ticked off (because all my masters had it and removing the pedestal is a pain). I'll activate it and test again tonight (I should have clear skies).

Patrick Chevalley

18-12-07 15:54

administrator   ~0005182

We can now return to this subject.
Do you have an occasion to try the focus ?

Cedric Raguenaud

18-12-07 17:10

reporter   ~0005183

The last time I checked the in place autofocus it couldn't find stars, even after your changes. So I use move autofocus and it works well. It's just a bit slower with the additional plate solving.

Patrick Chevalley

18-12-07 22:28

administrator   ~0005184

I continue to look at your failed focus images.
The stars are detected, but there is also many false detection because of hot pixel or group of hot pixels.
There is so many of this hot pixel that a BPM is probably not possible to use.

A solution can be to subtract a dark.
Can you upload a dark file that correspond to this short exposure (5 to 15 sec., gain=11, -10°) so I can make some test.

Cedric Raguenaud

18-12-07 23:33

reporter   ~0005185

OK I'll send you one. It will have to wait until Monday, I'm away from home at the moment.

Cedric Raguenaud

18-12-11 19:16

reporter   ~0005187

The files are 40MB so not convenient to share here. I've put one for you here:
(bin 1x1, 5s, gain 11, -10 degrees)
It's not a perfect one because I didn't cover the back of the telescope but it should be good enough for your tests.

Cedric Raguenaud

18-12-11 19:35

reporter   ~0005188

Here a bin 2x2 version:

Patrick Chevalley

18-12-11 20:10

administrator   ~0005189

Thank you.
I try with the 2x2 dark and your focus_fail images and I think this help.

You can also try it, I added the code Sunday after some test with my camera.
This is the menu File/Dark Frame, select "Load dark file" to load your dark.
You can test with "Apply to current image"
Then if the file format correspond it is used for the auto-focus images.
You can control if it is used by looking for a comment at the bottom of the fits header.

Cedric Raguenaud

18-12-11 20:20

reporter   ~0005190

Il try it as soon as I can open the observatory. It may be a while given the weather forecast.

Cedric Raguenaud

18-12-11 20:58

reporter   ~0005191

The dark frame substract works quite well. Though I get memory errors fairly often. I also get it when substract dark from preview is activated (hence I don't use it).

#0 fpc_raiseexception at :0
#7 ?? at :0
#8 fpc_dispinvoke_variant at :0
#9 T_ASCOMCAMERA__EXPOSURETIMERTIMER(0x4aa7fb0, <error reading variable>) at cu_ascomcamera.pas:432
#10 TCUSTOMTIMER__DOONTIMER(<error reading variable>) at customtimer.pas:175
#11 TCUSTOMTIMER__TIMER(<error reading variable>) at customtimer.pas:150
#12 TIMERCALLBACKPROC(0, 275, 19299, 15235484) at .\win32\
#13 USER32!AddClipboardFormatListener at :0
#14 USER32!GetScrollInfo at :0
#15 OVERLAYWINDOWPROC(5834624, 0, 275, 19299) at .\win32\
#16 USER32!DispatchMessageW at :0
#17 USER32!DispatchMessageW at :0
#18 TWIN32WIDGETSET__APPPROCESSMESSAGES(<error reading variable>) at .\win32\
#19 TAPPLICATION__HANDLEMESSAGE(<error reading variable>) at .\include\
#20 TAPPLICATION__RUNLOOP(<error reading variable>) at .\include\
#21 TWIDGETSET__APPRUN(0x425fe0 <TAPPLICATION__RUNLOOP>, <error reading variable>) at .\include\
#22 TAPPLICATION__RUN(<error reading variable>) at .\include\
#23 main at ccdciel.lpr:69

Cedric Raguenaud

18-12-11 21:06

reporter   ~0005192

It happens for example when I substract a dark from the current frame twice (refreshed through preview each time).

Patrick Chevalley

18-12-11 22:03

administrator   ~0005193

This is the out of memory error you already get when asking the camera driver for the ImageArray (line 432 of cu_ascomcamera.pas).

Sure the dark frame take some more memory but this is more related to 0002038 , maybe we keep this issue for the focus star detection problem.

Patrick Chevalley

19-03-20 18:20

administrator   ~0005478

I think this old issue is fixed now the camera interface is fixed.

Please reopen if there is still problem with that.

Issue History

Date Modified Username Field Change
18-11-13 19:50 Cedric Raguenaud New Issue
18-11-13 22:16 Patrick Chevalley Assigned To => Patrick Chevalley
18-11-13 22:16 Patrick Chevalley Status new => assigned
18-11-13 22:16 Patrick Chevalley Target Version => 1.0
18-11-13 22:16 Patrick Chevalley Note Added: 0005068
18-11-13 22:23 Cedric Raguenaud Note Added: 0005069
18-11-13 22:45 Patrick Chevalley Note Added: 0005071
18-11-14 10:18 Cedric Raguenaud File Added: focus options.png
18-11-14 10:18 Cedric Raguenaud File Added: autofocus options.png
18-11-14 10:18 Cedric Raguenaud Note Added: 0005076
18-11-14 14:44 Patrick Chevalley Note Added: 0005078
18-11-14 14:59 Cedric Raguenaud Note Added: 0005079
18-12-07 15:54 Patrick Chevalley Status assigned => feedback
18-12-07 15:54 Patrick Chevalley Note Added: 0005182
18-12-07 17:10 Cedric Raguenaud Note Added: 0005183
18-12-07 17:10 Cedric Raguenaud Status feedback => assigned
18-12-07 22:28 Patrick Chevalley Note Added: 0005184
18-12-07 23:33 Cedric Raguenaud Note Added: 0005185
18-12-11 19:16 Cedric Raguenaud Note Added: 0005187
18-12-11 19:35 Cedric Raguenaud Note Added: 0005188
18-12-11 20:10 Patrick Chevalley Note Added: 0005189
18-12-11 20:20 Cedric Raguenaud Note Added: 0005190
18-12-11 20:58 Cedric Raguenaud Note Added: 0005191
18-12-11 21:06 Cedric Raguenaud Note Added: 0005192
18-12-11 22:03 Patrick Chevalley Note Added: 0005193
19-03-20 18:20 Patrick Chevalley Status assigned => resolved
19-03-20 18:20 Patrick Chevalley Resolution open => no change required
19-03-20 18:20 Patrick Chevalley Note Added: 0005478