Project

General

Profile

Actions

Bug #246

open

Many detections end up with bit 4 (16) set in FLAGS when MEMORY_BUFSIZE is less than the image height

Added by Emmanuel Bertin about 8 years ago. Updated about 8 years ago.

Status:
New
Priority:
Normal
Start date:
12/15/2013
Due date:
01/27/2014 (over 7 years late)
% Done:

10%

Estimated time:
2.00 h
Spent time:

Description

Ricardo Herbonnet <> reports:

Dear dr. Emmanuel Bertin,

I have been working with Source Extractor version 2.8.6 and I found that flag 16 preferentially selects objects that are (very) elliptical and horizontally aligned.
I made simulated telescope images with completely symmetric distribution of galaxy shapes. Then I ran Sextractor 2.8.6 and selected all objects that were not flagged. The distribution of shapes of the selection was not symmetric any more.
I've attached several plots to illustrate my findings.
sexflags-hist-e?.png are the histograms of all flagged objects in my simulation for two ellipticity components. Flags 1 and 2 seem to be symmetric with respect to the galaxy ellipticities. However, flag 16 has an asymmetric distribution for e1, but not for e2. These ellipticities are the values I have put into the simulation, so there is no other step, which could cause the asymmetry.
sexflags-xy.png shows the locations of all sources on the simulated image that had a flag 16. The plot axes are as large as the image. There are two distinct regions in the plot; one is 'empty' save for one point near the edge (which is what flag 16 warns for), and the other is filled with flagged objects, seemingly randomly distributed below the 'empty' region. It is this second region that we believe should not be there and gives rise to the asymmetry in the histograms.
The flag=16 objects don't show a relation to their magnitude. The width of 'empty' part does show a relation with the parameter MEMORY_BUFSIZE: increasing this parameter increases the width of the empty part.
I spoke with Henry McCracken about this and he recommended looking at the newest version of SExtractor 2.9.16. I have not done so yet, so I cannot say if what I found with 2.8.6 is still there.
I hope that you can look at this, since it might pose a problem for the weak lensing community. If anything is unclear to you, please let me know and I will clarify it.


Files

herbonnet1.png (71.6 KB) herbonnet1.png Emmanuel Bertin, 12/15/2013 10:05 PM
herbonnet2.png (150 KB) herbonnet2.png Emmanuel Bertin, 12/15/2013 10:05 PM
Actions #1

Updated by Emmanuel Bertin about 8 years ago

  • % Done changed from 0 to 10

It is not clear to me whether this issue would still happen with recent versions of SExtractor. It is not clear also what measurements ellipticities were derived from (awaiting some feedback from Ricardo and Henk). Anyway I should keep an eye on this problem. Here is my reply:

The fact that sources with FLAGS = 16 are elongated along the x direction is not surprising. Bit 4 (16) in FLAGS is set when pixels around the isophotal footprint of a detection is likely to be cropped. This happens around all frame borders obviously; this may also happen at the lower limit of the subframe that SExtractor moves along the y direction as it scans the image. In principle SExtractor provisions enough scanlines to contain the detection footprint plus a comfortable margin around each object; although I could imagine that this heuristic may not work perfectly in special cases (e.g., some type of noiseless simulations). If this is what happens here the problem should not affect measurements done on the isophotal footprint of the object itself, so for 2nd-order moment measurements it should only affect those done through a Gaussian window ("WIN" parameters) or through model fitting (for the more recent versions). Are the ellipticities you mention derived from such measurements?
And yes it should go away when the subframe height (MEMORY_BUFSIZE) exceeds the vertical size of the image. The details of this subframe business, which is necessary to process arbitrary large images on machines with modest amounts of memory, has been adjusted through time, so it is possible that recent versions do not exhibit the same issue.

Actions

Also available in: Atom PDF