Help with Flat Field analysis

[nightster]

Can someone with CCDInspector check an image for me? I just added an OAG and had to move the spacers around a bit to get the Lodestar to focus. According to my calc Im off by 2mm. This is an Ha stack of 24 images. If the raw subs are needed let me know I'll put them up somewhere. 

[Oddsocks]

Hi Jeff

Unfortunately the image posted is not suitable for CCD inspector analysis, the pixel sizes and shapes once cropped and converted for PNG no longer matches the 460EX CCD source.

Plate solving the image gives an image scale of 3.3 arc sec per pixel at 4.45um x 4.54um pixel size for the 460EX which can be used for a CCD inspector run in future, The other problem is the nebula in the middle of the image which will also skew the result from CCD inspector.

For best accuracy with CCD inspector you need star field images that contain no large areas of nebulosity or galaxies etc and the format should be calibrated but otherwise unprocessed FITS.

CCD inspector will average together as many individual FITS as you throw at it, the more the better, and CCD inspector reads the FITS header of each file to ensure the correct sensor dimensions are used.

For fine tuning spacing adjustments CCD inspector works most accurately when averaging at least ten files of calibrated luminance FITS frames, uncombined.

If you use PNG, TIF or JPG etc you end up chasing ghosts caused by compression artefacts and pixel aspect ratio resizing.

If you post a link to at least ten rich star field, luminance FIT files that show no tracking defects then these would be ideal for CCD inspector analysis and you can be reasonably confident the results are accurate.

 

[nightster]

Well now I feel dumb. Of course you need a FITS image of a star field.  I'll grab one now. Thanks for the reply.

[nightster]

Here is a link to 10x30sec Lum subs.

 Lums for Curvature test

[Oddsocks]

Jeff.

Below are the results for your linked google drive images, turned out to be a bit of a struggle, the format you posted (out of Pixinsight I guess?) is .xisf which CCD Inspector does not recognise so tried opening the .xisf in my Mac copy of PI and saving as .fits but this crashes PI, must be a bug with the Mac PI version. Transferred all your files to PI in my Observatory Windows PC and converted them in my Windows PI version to .fits, no problem. Will have to do a bug report for the Mac version of PI later.

Following images are:

Curvature map and 3D plot for the aggregated images and charts for a sample image (frame 4) of Curvature, Aspect and Vignetting. Also included for ref is the original posted Pac Neb as Curvature and 3D plots to show how the results from CCD inspector can be skewed when a compressed image format and large scale structures are included.

From the aggregate curve and 3D plot the problem areas are the 8% tilt and 15% curvature. Never 100% sure how to interpret the plots re spacing but suspect overcompensation for the curvature is sensor-to-flattener spacing too close, I don't know how that fits in with your calculated spacing. The tilt should be fairly easy to resolve, probably some sag in the new imaging chain, you would need to compare to previous CCD inspector results without the SX OAG and FW to get a handle on what could have changed.

If you make any adjustments to your spacing and collimation (tilt/sag) and post further images for evaluation it would be best to post the camera raw .fits rather than the .xisf from PI at the present time, the .xisf is not compatible with CCD inspector.

Regards.

William.

Aggregate Curve:

 

Aggregate 3D:

 

Frame 4 Curvature:

 

Frame 4 Aspect Ratio:

 

Frame 4 Vignetting:

 

 

 

Reference images, not for diagnosis:

Bad Curvature Map and 3D plot for the Pac Nebula, skewed result because of wrong image format and large structures in the frame:

 

 

[Oddsocks]

Hi Jeff.

I had a reply back from Juan Conejero at PixInsight who found the reason your .xisf files cause the Mac version of PI to crash when trying to save as .fits (only with OS Sierra 10.12) is there are non standard terms used in your FITS header for Temperat' Dewpoint' and Humidity'. Your camera / observatory file writing program is entering the term "NaN" as a value under each of these FITS headings which is an illegal term, only a numeric value can be used here.

On all operating systems this should just result in an error being generated but with Mac OS 10.12 Sierra it crashes PI.

I tried a couple of your .xisf files and edited the FITS header to change the "NaN" term to "0", applied the change and then saved as .fits and no crash!

Juan recommends checking the fits header defaults you have set up at your observatory to avoid future complications when distributing your image files.

Below is a copy of the reply from Juan:

The problem with this image is in three numeric FITS header keywords with NaN (Not a Number) values, namely:

 

DEWPOINT NaN                                Dew Point in degrees C

HUMIDITY NaN                                Humidity in %

TEMPERAT NaN                                Ambient Temperature in degrees C

 

Trying to save this image in FITS format generates the following error on all supported platforms, including OS X 10.11.6:

 

CFITSIO error message stack: 

01 : Error in ffd2e: double value is a NaN or INDEF

 

without any crash, which is the correct behavior. I have no macOS 10.12 machine, so I can't test this issue on that OS version. Please note that macOS Sierra is still not supported officially. However, I see no reason for a crash to happen in this case, unless CFITSIO is doing something weird.

 

The FITS standard does not allow header keywords with non-numeric entities such as NaN and +/-Inf, so these keywords are illegal in a FITS file. You may want to contact the authors of the application that generated the original file to fix this issue.

 

H.T.H.

William.

[nightster]

I tracked down the NaN FITS error. There was a fault with my TemperHum device and SGPro. I read up on it and it doesn't seem to play well with SGP so I've removed it from the rig. I'll look for a better supported Humidity sensor for the system. 

[nightster]

Hi William,  I recieved the proper spacers (as per the specifications). I'was probably 2mm over optimum in the previous sample. Attached is another link to a few subs, this time in FITS format and without any non-standard Humidity sensors adding erroneous data to the files.  If your able to give me an idea if I am close I would appreciate it. Then I can dig down into the data and compare the before and after and see what will be the next step.

 

https://drive.google.com/drive/folders/0B-OFUoejgi-ARy15RGwyREVJdXc?usp=sharing 

[Oddsocks]

Here are the latest results Jeff:

Curvature is reduced from 15.9% to 10.7% and the frame edges are just beginning to tilt upwards in the 3D plot so you are closer to the optimum spacing, if you adjust the spacing a little more in the same direction then the frame edges will rise a little more and the centre will drop a little. Will check again for you if you decide to tweak it a bit (I expect you knew to add one third the filter thickness to the quoted spacer distance, catches a lot of folk out).

Main problem is still the total tilt, was 8% originally but has now increased to 11%. Although mechanical tilt has reduced from -0.2"x -0.5"y to -0.3"x -0.2"y, the two values, mechanical tilt and total tilt are displaying tilt data in differing quantities so they often move counterintuitively, as tilt in x and tilt in y reduce in numerical value the percentage difference between them can remain the same or even increase! (CCD inspector explanation in italics below). Looking at the two curve images, before and after spacing change, the defocus in the y direction is clearly better in the later image and worse in the x direction as the quoted tilt x and tilt y values show.

IMin FWHM: lowest FWHM value in the curvature map 

Max FWHM: maximum FWHM value 

Curvature: percent defocus between lowest and highest defocus points on the map 

Tilt in X, Y: defocus from left to right, and from top to bottom of the image, expressed in arcseconds or pixels 

Total Tilt: is the absolute amount of measured tilt in the image, expressed in %, and its direction shown in degrees, as well as with a pointing arrow 

Collimation: the distance between physical and optical centers in the image, shown in arcseconds or pixels. Assuming a small optical tilt, this is how far the optics are from perfect collimation. 

Plots and charts below, vignetting chart shows residual flats calibration error or more likely sky gradient, fits header shows the processing steps in PI included flats reduction and the vignetting chart should be a straight flat line in a perfect world but the angled line is most likely caused by sky gradient.

William.

 

 

 

 

 

[nightster]

Good to learn I am moving in the right direction. I've got 2 thin spacers I can remove to refine spacing. For others trying to space a similar setup I'll describe the whole system. Stellarvue SV80ST, MoonLite CFL 2.5" focuser with 68mm drawtube. Threaded into the the end of the drawtube is the ML M68 to M48 adapter (this comes with an adjustable threaded collar but in order to repeat the spacing I've removed this and just bottomed out the next extension tube.) Fore of that adapter is the SV SFF6 flattener (that corrector is inside the drawtube attached to the M48 filter threads.) Aft of the ML adapter is a 1mm M48 spacer. This 1mm is really only adding less then .3mm as the next spacer doesn't fully seat against the ML adapter. I added it to help square the seating of those parts. Next is a 30mm M48 extension to the M48 SX OAG adapter. Then the SX OAG which is screwed onto the SX USB FW. I use 1.25" Astronomik filters (1mm thick glass adds .3mm to the calc.) Exiting the SX FW using the SX T2 (42mm) adapter, next is a 1mm 42mm ring (will be removed) then a 10mm m42 extension into the 460. I had to add the m42 spacer behind the FW in order to get the lodestar to come to focus, there wasn't enough inward movement on the stem of the OAG to allow the guider to be spaced behind the flattener at the correct distance.

Now in order to solve the tilt the MoonLite does have collimation adjustments.  3 hex grub screws near the rotating collar. I suppose to get it perfect I'll have to get CCDinspector and do it live while I'm getting images. Can it be used that way?

[Oddsocks]

27 minutes ago, nightster said:

I suppose to get it perfect I'll have to get CCDinspector and do it live while I'm getting images. Can it be used that way?

Yes, although CCD inspector does not interface directly with ASCOM or the camera. 

You would take a single image, no need to apply calibration for quick tilt adjustment, use the file menu in CCD Inspector to load the new image, select the image in the CCD inspector loaded files list and press the "View" button to check for good tracking and no obvious aberrations, highlight the new image in the image list and press the "Measure" button to check average FWHM for the image and reject if momentary seeing variation put the FWHM out of your acceptable criteria then press the "extrapolate" button to calculate the curves and charts, finally click on the "curve", "3D" or "charts" buttons in CCD inspector to display the maps and charts.

Make a small adjustment to the collimation screws and take a new image, return to the file menu and open the new image, run the measure and evaluate commands again then view the curvature map to see if the change was in the correct direction. Repeat until tilt and collimation is acceptable.

This is what I use CCD inspector for, I use an Orion Optics AG8 f3.8 Astrograph set up with a QSI camera and FLI Atlas focuser, the only way to adjust the primary mirror collimation and optical axis tilt accurately is with CCD inspector since removing the camera and going visual for the collimation adjustment results in a misalignment once the camera is put back on the telescope and it proved virtually impossible to adjust the system any other way. CCD inspector makes adjusting a fast Newtonian like the AG8 a doddle, literally just twenty minutes from mounting the scope to having the primary collimated, usually bin 2x2 is sufficient for this as well to speed up image download times but you have to remember to change the pixel size and image scale in the setup page if you want to have accurate measurements displayed. Even though the curve and 3d maps remain a correct representation of the system if the pixel size and image scale are not correct the numerical values quoted in the graphs will be wrong.

When evaluating a system and wanting the highest accuracy for reporting then you would load as many images as possible (from the same target coordinates, not from different regions of the sky) and select all the images in the CCD Inspector loaded files window, or those files displaying the smallest FWHM, then extrapolate the aggregated results, this reduces the chances of a single dodgy image from skewing the results. I find a minimum of ten frames gives a result not much different from twenty frames but considerably better than five frames. Using raw unprocessed files gives you a full set of of data including vignetting, using a set of calibrated images gives you the same data set but the vignetting report will show sky gradient or uncorrected gradients from a bad flat, this is a useful tool when trying to pin down problems with over or under correcting flats in a measurable numerical way rather than visual interpretation of the calibrated image in post processing.

There is a thirty day fully functional evaluation period for CCD Inspector and it starts from first launch of the program so wait for a good spell of clear weather before downloading and installing and then give it a go, setup is simple and the quick setup only requires pixel size and pixel scale to correctly calibrate the displayed graphs and curves, in your case the latest images you posted had a pixel scale of 1.92 arc-sec/pixel (confirmed via astrometry.net) and the camera unbinned has 4.5um x 4.5um pixels, enter these into the setup page, load the image and go. Once the thirty days are up then you have to enter the licence otherwise the program will not launch.

There is a .pdf manual for CCD Inspector here: http://www.ccdware.com/Files/CCDInspector221.pdf 

H.T.H.

William.

[nightster]

I did try the trial back when I was suspecting focuser sag. I ended up getting the Moonlite and my images have been much improved. Except that I couldn't figure out using my flattener with the supplied adapters (I was trying to attach it behind the ML adapter and thus unable to reach focus at the CCD.) This software seems like a required piece of the perfection puzzle, but it has a somewhat high price tag for what on the surface seemed like a one time use. But it seems I may be completely wrong and it might be quite handy for more frequent confirmation that the system is in tune. And with your in depth description on how you use it make me think that it might breath life into my fast and  cheap imaging newt.  

If I were to use it to collimate the focuser would that only be suitable for one camera angle? When I rotate the focuser would that change the angle for the sensor also?

[Oddsocks]

5 hours ago, nightster said:

If I were to use it to collimate the focuser would that only be suitable for one camera angle? When I rotate the focuser would that change the angle for the sensor also?

That is not so easy to answer without having the setup on an optical bench. It depends where in the image chain the misalignment is occurring and which side of the plane of focuser rotation that the collimation screws act upon (tube side fixed or camera side rotating). 

A quick test would be to take a star field image somewhere close to the meridian at around 45deg altitude take an image then meridian flip the mount but change nothing else and take a second image, process both images in CCD inspector. If the direction and amount of total tilt remains the same in both images then it is likely that adjusting the focuser-rotator collimation screws will produce a tilt correction that does not change with focuser rotation, assuming the source of tilt is a tube - focuser - camera misalignment and not a lens cell misalignment, i.e. the optical path is perfectly axially aligned with the tube.

With such a long overhang in the image chain from the back of the tube my guess would be that if you took the images as described above then the resulting CCD inspector images, before and after flip, would show the direction and amount of tilt had changed significantly which would indicate the problem was after the focuser and a change to the collimation screws would only be relevant for one position of the focuser at one tube elevation angle.

The small circumference flanges used between flattener, focuser and camera are usually the problem areas, the contact areas are just too small to ensure a rigid flex-free connection unless you tighten them up to some insane torque and then you always worry you will never get the things apart again.

The only thing I can suggest from experience is try to get out of the idea of rotating the camera for framing, not easy with a small sensor but it makes collimation alignment a whole lot simpler. If you don't need to rotate you can usually find a mechanical collimation adjustment that results in an equal but opposite small residual tilt for either side of the meridian flip. I never rotate my cameras now, spent too many wasted hours faffing about with collimation for that and I just keep the camera x axis aligned with RA motion all the time, if I have to take mosaics and crop and rotate in post processing then so be it, it is still a quicker way to gather targets.

Don't suppose the above has really helped but it is all I can think of right now!

William.

[nightster]

You have been incredibly helpful. And you've given me much more to think about, for which I thank you. What I'm think about doing is setting up in SGPro a before and after meridian of a starfield, I'll do it at about 2 hours before and after the flip that way it gives some gravity to the tube and I can see if that is what is pulling.