bwgref
commented
1 day ago Turns out this is in utils.validate_det1_region() method.
This script does the following:
- Checks to make sure that the region file is in pixel coordinates (and not image coordinates)
- Checks to make sure that the order of operations is correct (source regions before exclusion regions)
However, there's no really good reason that we can't write our own sanity check code to check to ensure that the region file is properly formtted.
This uses astropy.regions as a convenience wrapper to parse the ds9 region file and get the relevant information. Here is a "good" region file produced by ds9:
Region file format: DS9 version 4.1
global color=green dashlist=8 3 width=1 font="helvetica 10 normal roman" select=1 highlite=1 dash=0 fixed=0 edit=1 move=1 delete=1 include=1 source=1 image circle(135,-13,239.51794) -circle(221,237,83.569807)
This is what the region file is supposed to look like if you make it in ds9. To allow flexibility in the formatting (in case you ignore the globals line or the comment line), I propose the following:
Pass 1:
Do a line-by-line text search through the input region file for a line that says 'image'. If this is not found, report an error (meaning that the region file is in fk5 or some sky coordinate). This is the most common error and must be kept.
Store the line number where you found "image"
Pass 2:
Look at the line immediately after the "image" line. I think XSELECT treats this as the source region and we can safely assume that this format is fixed. If this line starts with a '-' then report an error. This is the second most common error and is related to XSELECT not actually being smart enough to handle out-of-order include/exclude regions in the .reg file.
If both Pass 1 and Pass 2 make it through, the file is valid.
wrappers.extract_det1_events can't read region files with negative heights. This seems to be an issue with the region package which is forced to region >=0.7 in the requirements.txt right now. Works fine for region=0.5 but newer versions (tested 0.6, 0.7, 0.8) will raise an error: ValueError: 'height' must be a strictly positive scalar.
Example SL observation for the issue: 10902336002A