Details
-
Type:
Bug
-
Status: Invalid
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: pipe_tasks
-
Labels:
-
Story Points:1
-
Epic Link:
-
Team:Data Release Production
Description
ingestImages.py does not read the first HDU and prints the following warning (for obs_cfht) :
ingest.parse WARN: Error reading rawDownload/1022062p.fits.fz extensions set(['ccd00'])
|
setting extnum = 0 instead of 1 in https://github.com/lsst/pipe_tasks/blob/master/python/lsst/pipe/tasks/ingest.py#L70 seems to fix the problem. But it is probably just a workaround
Attachments
Issue Links
Activity
This is indeed the secret code for "first non-empty extension", which used to be written 0; this is present in RFC-304 if you read very carefully, and I've just added a comment to make it clearer. The doxygen was updated, e.g. https://lsst-web.ncsa.illinois.edu/doxygen/x_masterDoxyDoc/classlsst_1_1afw_1_1image_1_1_image.html#ab91d1364181ff985b97845a8798c9d7b
We talked more about this and Colin Slater, Meredith Rawls and I concur that the default in the config, ParseTask.hdu, should in fact be zero. In this specific case the user will almost always want to read the metadata from the primary header (which frequently will have no image data). In the case of multi-extension files the primary will almost always be empty, but have useful metadata.
I believe this should be closed as a duplicate of DM-10297.
Looks like DM-10297 is done, so this should be too. Since the fix was effectively exactly the same as the one Dominique Boutigny suggested, I think we can safely shut this down. Thanks Meredith Rawls, Simon Krughoff, et al.
Dup of DM-10297.
Robert Lupton why did you change the default extension to be INT_MIN I would have thought that zero would be a perfectly reasonable default. Is this a secret code for "find the first non-empty extension"?