search

ejeschke / ginga

The Ginga astronomical FITS file viewer
BSD 3-Clause "New" or "Revised" License
121 stars 77 forks source link

Pick function showing different FWHM values between the FWHM figure and the Readout tab #969

Closed obi-wan76 closed 3 years ago

obi-wan76 commented 3 years ago

Sometimes when using Pick, the FWHM value at the top of the FWHM figure doesn't match the value in the Readout tab. In the attached example, the FWHM Y at the top of the figure is 7.70 px but in the Readout tab is 5.625 px. What is the difference between these two values?

Note that that I am trying to fit a double peaked feature and it is the direction of the double peak that shows the FWHM discrepancy.

Thanks! Screen Shot 2021-08-17 at 8 10 48 PM Screen Shot 2021-08-17 at 8 08 10 PM

pllim commented 3 years ago

It does seem like they are the result of two different calculations...

The one display in the plot title is from:

https://github.com/ejeschke/ginga/blob/4df2a890d85f5d11a4b19105c6c6288a669b0350/ginga/util/plots.py#L447

The one displayed in the table is from:

https://github.com/ejeschke/ginga/blob/4df2a890d85f5d11a4b19105c6c6288a669b0350/ginga/rv/plugins/Pick.py#L1719

I vaguely remember they always had shown me the same values on well-behaved objects. But in this case, it diverged. Perhaps @ejeschke can advise.

ejeschke commented 3 years ago

@obi-wan76, I'd have to review the code (haven't yet), but I believe this is because there are two phases to the plugin. In the first phase, all the possible candidates are selected by running a FWHM on each local approximate peak to determine eligibility according to the Settings. Then, the top candidate is run through a second FWHM based on the center as determined by the first one.

The info in the lower widgets is populated by the first FHWM and the graph by the second. I think the reason that a second is done is because we do not keep around all the info including cut out 1D arrays done during the first pass. So I guess the second FWHM, getting a slightly more accurate center from the first pass, may produce a different result, especially if the center rounds to a different pixel. In most cases, as @pllim says "for well-behaved objects" it won't matter much, but for cases as you show there can be a difference.

In any case, it should be possible to run the second pass using the same initial approximate peak rather than the center found by the first pass. Not sure if that is a good idea or not. Suggestions welcome!

pllim commented 3 years ago

It is confusing that FWHM values on plot title and report panel do not exactly mean the same thing. I can see two different solutions here:

  1. Modify the plugin to sync them to the one and only correct value.
  2. Clarify in tooltips and user doc that they do not mean the same thing.
ejeschke commented 3 years ago

@pllim, see #970. I think this may allow us to solve this issue (with some additional commits to Pick).

Basically, it changes evaluate_peaks to calculate the FWHM from the center-of-mass centroid calculated off of the local peak, rather than the local peak itself. Then, in Pick, for the graph FWHM, we simply use the int(round()) of oid_x,oid_y (if not None), otherwise use x, y (the local peak). This should result in the exact same FWHM in the graph.

ejeschke commented 3 years ago

Hmm, after reviewing the code in ginga.util.plots more thoroughly, and testing with a few binary objects, I'm now convinced that the problem is that the second (plotted) FWHM difference is because it is doing a new cross-cut on the full data and not just the original cutout shape. Thus, if one is attempting to limit the range of the analysis (for example, cutting off half of a binary object with the box), the first FHWM will be correctly limited to the data only inside the box, while the second one will contain some of the area outside the box.