CTU + CCD Inspector
Stacking program, astrometric (plate) solver, fits file viewer
Brought to you by:
han59
Menu
▾
▴
working at fine tuning my AP rig and have a Gerd Neumann CTU to
correct tilt and shot subs of M44 to measure in ASTAP. I am finding it
tricky to apply the ASTAP CCD Inspector results back to the CTU because
ASTAP shows a quadrilateral but the CTU has 3 collimation screws at 120 degree
positions around its circumference. There is also the issue of figuring out which edge of
the image in ASTAP corresponds to the top edge of the actual camera sensor.
1) plate solving I get -89.86 deg and the red arrow indicating North is pointing to the left,
east line segment is down ... so which edge of the image represents the true top edge of the sensor ?
2) results for my test image are: median HFD=2.9, tilt[HFD]=0.25 Stars=311, Off-axis aberration[HFD]=0.25
... what would be an acceptable set of values for tilt and off-axis aberration ?
I am using WO GT71 reduced to f4.7 with ASI533MC-pro.
I think you achieved an excellent result for both tilt and off-axis abberation. You can't get it much better.
For my APO astrograph I get ta typical HFD of 2.5, tilt 0.13, off-axis abberation 0.12 but it is very dependent on the connection of my camera. It easily introduces a tillt since it is clamped, not screwed. The rest is screwed which is much better then clamped.
The north-east indicator is for the center of the image.
Was there a reason to use a position near the celestial pole like having no drive?
Cheers, Han
Hello Dean,
funny. I just corrected the tilt from my setup yesterday evening with the CTU and ASTAP. Coincidence... I think not.
First of all I would like to thank Han for this excellent program. Both plate solving and this CCD inspection feature are incredably useful for me.
I was also struggling with orientation, as you write. The scope flips the image in both axis which comes on top of the 4 vs three issue.
Doing trial and error with 30s frames I was left with 0.25 unresolved as you have.
The last 16th of a turn was up in the air. (Seeing / Guiding)
This converts to about 0.01mm on the CTU, which I considered good enough.
I'd like to have the possibility to access the HDF tilt data through the command line.
This could open up the possibility to use a script.
Turn screw 90°. Determine effect, calculate correction rotation anges for screws :)
I was using a 123mm reduced to f4.5 with ASI183MM.
Kind regards, Norman
bee hive cluster was the only suitable and unobscured (trees) target that was also far enough
away from the full moon, just happened to be overhead at the time (tracked with HEQ5).
Also, I am thinking that if there is any non-gravity induced tilt,
like sensor tilt or connection tolerances (not flexure), then a near vertical scope position
is probably a good choice?
An older version of ASTAP I used showed tilt as a percentage. How was that percentage
computed ? tilt[HFD]/median[HFD] ?
Hi Norman,
I was using 5 sec subs, gain 105, which seemed good enough to get HFD values. I was also thinking
that if HFD values as triplets (x,y,HFD) where x and y are pixel or actual mm values for the
detected stars could be dumped to .CSV, I could write a script or Matlab plugin etc.
to visualize the CTU, and interpolate the HFD values at the 3 collimation points .
I don't have the old code on my system but the % calculation was something like the ratio 100% - 100*("HFD of the outer regions"/"HFD center".
Now it is:
Off-axis:= HFD_center - HFD outer_ring.
Tilt:=HFD_worst - HFD _best (for the four corners)
All values are median
You can export all star info to a .csv file using the command-line, option -extract
http://www.hnsky.org/astap.htm#astap_command_line
Han
Hello Han,
I did not think about it fully. You're right, the -extract option is actually all you need.
Thank you, Norman
a few more questions / observations if you will indulge me.
With reference to the image in the first post, I wrote a script that does the following:
astap -f <myfile.fits> -extract <snr_minimum>
to get the hfd and x,y coordinates in decimal pixel values. Then I partition the domain
into 4 equal rectangular/square quadrants from the fits header NAXIS1 NAXIS2 values, and accumulate in 4 separate arrays the hfd values found in those quadrants. I sort and extract the median from each of those arrays to represent the four hfd corner values centered at each quadrant.
If I open the fits file in ASTAP and run ccd inspector,
I get ~ 340 stars reported as seen in the attached jpg previously. If I run the command line,
even with a very low snr minimum, I get ~ 120 sets of points and hfd values. My median
values are all different and lower than what the ccd inspector tool provides:
2.60 (ccd inspector) vs 2.14
2.74 vs 2.24
2.91 vs 2.29
2.95 vs 2.23
tilt ccd inspector: 0.35
tilt command line data: 0.15
I want to ensure what I am getting from the command line is "correct" so that I can then
interpolate data to my CTU collimation points. Is my approach flawed ?</snr_minimum></myfile.fits>
For an accurate measurement it is better to keep the SNR above 30. I did a check here and the reported HFD values are very equal. Only the amount of stars reported is different. The command-line version and ccd-inspector use different routines but of equal design. The CCD-inspector tries at three background levels while the command-line version use only one background value. The reason was that the export function is intended for focusing and I didn't wanted to introduce the possibity of a very small jump by using a different background value.
Back to your problem. These difference you indicate are huge and should not happen. Can you try the export function with no SNR specified or snr=30
Changing the SNR from 30 to 10 should have only a very small effect. Only the noise in measurements becomes larger. The mean value is more or less stable. So only the variation in the individual measured values increases.
For further testing if you share your image I can have look to results.
Han
Han,
thanks for your explanation as to cause of the differences. It also seems that the cli algorithm
operates on raw un-debayered data while the gui ccd inspector can provide hfd values
for either, depending on if you choose to debayer. I am getting closer values when compared
to un-debayered results from the ASTAP ccd inspector. I am not too concerned about the magnitude of the computed tilt from the quadrant median values, but more the trend in their variation: ie., the resulting shape of the tilt quadrilateral.
SNR of 0 is the same as SNR of 30. I get similar tilt value with SNR of 10 as un-debayared ccd inspector.
Attached is refined php code and a link to my test image: https://tinyurl.com/uj4vnbyu
Yes measuring HFD using a unbayered is akward. That's why the 2x2 filter was introduced for the CCD inspector.
If the SNR is blank, the string to float conversion will produce a zero. A zero is triggering the default value of 30.
The raw image is typical where the R, G, G and B channel are out of balance. I assume they build in a kind of colour balance.
For the inspector if Bayer matrix image is selected a box blur is applied. You can do the same manually in tab "Stack method", select for master flat filter "box blur 2x2" and press "test flat filter"then save the result as a new image. Using this box blur filter you should get very equal result for command-line and inspector. If this works well, I could consider to add this to the command-line options.
I do not program in PHP.
Cheers, Han
results are better with saved box blur 2x2 fits images. I think it would be a good addition
for anyone wanting to get x, y, hfd values for external ccd inspection work (like me!) if
there was:
- a cli option to provide the extraction in the same way that ccd inspector does
in the gui
- a menu option in astap gui to dump the ccd inspector results to csv
(ie., all star x.y,hfd triplets and quadrilateral center and corners with medians)
Dean
This is the new diagram of the documentation:
thank-you for the update Han.