How is FWHM calculated in the Quality Tab?

Discussion in 'Image Processing' started by Jesse, May 4, 2017.

  1. Jesse

    Jesse Cyanogen Customer

    Joined:
    Oct 11, 2014
    Messages:
    35
    The value(s) displayed are typically much greater than what other programs calculate and I can't even correlate it with the FWHM displayed in the Information window (attached).
    M101_FWHM.png
    Jesse
     
  2. Doug

    Doug Staff Member

    Joined:
    Sep 25, 2014
    Messages:
    2,989
    Well for a starter, doing a FWHM on a galaxy nucleus is unlikely to produce a meaningful answer, since it is not a point source. Also the background is not uniform (spiral arms) so that will also degrade the accuracy of the result. I'd strongly recommend using an isolated (and not saturated) star.

    I'll also note that the measurement ring (inner ring) does not encompass the entire object.

    There isn't an "official" way to measure FWHM; it's inherently an approximation. We basically use the same method as IRAF so it's a well-accepted procedure.

    FYI the View menu Graph Window command has a Star Profile feature, which you can also use to estimate FWHM by looking at the half-way point of the graph.
     
  3. Jesse

    Jesse Cyanogen Customer

    Joined:
    Oct 11, 2014
    Messages:
    35
    I purposely picked the galaxy nucleus to demonstrate that even its fat core measured at FWHM of 8.6 was still less than the 9.5 reported for that image in the quality output. A typical star measured between 4-5 in the information window.

    So let me rephrase the issue: The FWHM measurement that Quality outputs is on the order of double the FWHM I see in the Information window (or the Star Profile see attached) when measuring typical stars.
    StarProfile.png
    Thanks,
    Jesse
     
  4. Doug

    Doug Staff Member

    Joined:
    Sep 25, 2014
    Messages:
    2,989
    Please upload your FITS image so I can see that for myself.
     
  5. Jesse

    Jesse Cyanogen Customer

    Joined:
    Oct 11, 2014
    Messages:
    35
    Your wish is my command :)

    Jesse
     

    Attached Files:

  6. Doug

    Doug Staff Member

    Joined:
    Sep 25, 2014
    Messages:
    2,989
    Your collimation is way off; I'm seeing FWHM of 3.5 pixels at upper right, and 6.2 at lower left.

    The reason that the reported value is different is that the Stack command always reports in unbinned pixels. Your image was binned 2x2, so it multiplied the result by 2. This allows for merging images taken at different binning levels (e.g. if you bin RGB but not L).
     
  7. Jesse

    Jesse Cyanogen Customer

    Joined:
    Oct 11, 2014
    Messages:
    35
    Thanks. You might want to add a sentence in the Quality Tab help section for FWHM along the lines of: If binning is enabled, the FWHM is reported in unbinned pixels.

    Collimation is on the to-do list (it's a pain with our 40 year old custom built OTA :) While I did measure an issue with collimation last year during a focus test (I typically don't collect the image data), I'm thinking there may also be an issue with sensor tilt.

    Jesse
     
  8. Doug

    Doug Staff Member

    Joined:
    Sep 25, 2014
    Messages:
    2,989
    Yes sometimes you have to shim the camera. The focuser might not be square. That can be really confusing because some collimating techniques are sensitive to the tilt and others aren't.

    If you use a laser collimator and things aren't square you'll end up waaaay out of collimation. In that case if you can a method that isn't sensitive to tilt (cheshire eyepiece), you can subsequently use the laser to help you shim the focuser. Once the focuser is shimmed the laser is a nice quick way to align your mirrors.
     

Share This Page