# ingestImages.py fails due to missing entry in the fits metadata **URL:** \ **Category:** Data Management\ **Created:** [November 10, 2016, 3:04pm UTC](https://www.rubin.community/t/ingestimages-py-fails-due-to-missing-entry-in-the-fits-metadata/1391 "2016-11-10T15:04:10Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![boutigny](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/boutigny/32/26_2.png) [@boutigny](https://www.rubin.community/u/boutigny)\ **Post date:** [November 10, 2016, 3:04pm UTC](https://www.rubin.community/t/ingestimages-py-fails-due-to-missing-entry-in-the-fits-metadata/1391/1 "2016-11-10T15:04:11Z")
[ingestImages.py](http://ingestImages.py) is failing on some CFHT images downloaded by @idellant from the CADC portal. This is coming from the method : getExtensionName(md) in pipe\_taks/…/ingest.py which is looking for 2 separate “EXTNAME” entries in the metadata and only found one in @idellant exposures. In a regular CFHT exposure we have: EXTNAME = ‘COMPRESSED\_IMAGE’ / name of this binary table extension EXTNAME = 'ccd02 ’ / CCD number in the mosaic While in the faulty one we only have the second entry. Does this double “EXTNAME” entry mandatory in the fit standard, meaning that CADC has screwed up something during image processing ? Or is it non mandatory, in which case we have to fix pipe\_tasks/…/ingest.py in order to accept the single “EXTNAME” ? ---
**Author:** ![timj](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/timj/32/10_2.png) [@timj](https://www.rubin.community/u/timj)\ **Post date:** [November 10, 2016, 6:00pm UTC](https://www.rubin.community/t/ingestimages-py-fails-due-to-missing-entry-in-the-fits-metadata/1391/2 "2016-11-10T18:00:21Z")
> [@boutigny](#): > > 2 separate “EXTNAME” entries in the metadata I don’t even understand what two `EXTNAME` values in a single header means. Do you mean that you have a MEF with a table and an image and those are the two `EXTNAME` headers. That makes more sense. If that’s the case, is the binary table there but lacking `EXTNAME` or is it missing completely? ---
**Author:** ![jbosch](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/jbosch/32/12_2.png) [@jbosch](https://www.rubin.community/u/jbosch)\ **Post date:** [November 10, 2016, 6:06pm UTC](https://www.rubin.community/t/ingestimages-py-fails-due-to-missing-entry-in-the-fits-metadata/1391/3 "2016-11-10T18:06:54Z")
It looks to me like this is an image HDU that has been tile-compressed (which turns it into a binary table). That transformation probably added the “`COMPRESSED_IMAGE`” `EXTNAME`, and didn’t remove the existing `ccd02` one. I have no idea if that’s valid, though I wonder if `ccd02` is an invalid `EXTNAME` and that caused a compression library/utility to miss it. ---
**Author:** ![timj](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/timj/32/10_2.png) [@timj](https://www.rubin.community/u/timj)\ **Post date:** [November 10, 2016, 6:11pm UTC](https://www.rubin.community/t/ingestimages-py-fails-due-to-missing-entry-in-the-fits-metadata/1391/4 "2016-11-10T18:11:07Z")
Yes, `EXTNAME = COMPRESSED_IMAGE` is for tile image compression. I guess two `EXTNAME` headers does make sense (the `ccd02` is the actual name and then compression has to add a second one). Is it possible that the file without the `COMPRESSED_IMAGE` `EXTNAME` is a file that has not been compressed? ---
**Author:** ![jbosch](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/jbosch/32/12_2.png) [@jbosch](https://www.rubin.community/u/jbosch)\ **Post date:** [November 10, 2016, 6:20pm UTC](https://www.rubin.community/t/ingestimages-py-fails-due-to-missing-entry-in-the-fits-metadata/1391/5 "2016-11-10T18:20:00Z")
A quick grep of the FITS tile compression convention doesn’t turn up `EXTNAME` anywhere, so it seems adding `EXTNAME = 'COMPRESSED_IMAGE'` is not necessary. I’ve recommended to @boutigny that we change the ingest code to check for 2 `EXTNAME` entries and discard any containing `COMPRESSED_IMAGE` (instead of blindly grabbing the second entry), but I’m worried that that is still pretty fragile. It might be better to force individual obs packages to override this. ---
**Author:** ![timj](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/timj/32/10_2.png) [@timj](https://www.rubin.community/u/timj)\ **Post date:** [November 10, 2016, 6:28pm UTC](https://www.rubin.community/t/ingestimages-py-fails-due-to-missing-entry-in-the-fits-metadata/1391/6 "2016-11-10T18:28:45Z")
It is used: [http://fits.gsfc.nasa.gov/registry/tilecompression/m13\_rice.fits](http://fits.gsfc.nasa.gov/registry/tilecompression/m13_rice.fits) ---
**Author:** ![jbosch](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/jbosch/32/12_2.png) [@jbosch](https://www.rubin.community/u/jbosch)\ **Post date:** [November 10, 2016, 6:30pm UTC](https://www.rubin.community/t/ingestimages-py-fails-due-to-missing-entry-in-the-fits-metadata/1391/7 "2016-11-10T18:30:32Z")
> [@timj](#): > > It is used: [http://fits.gsfc.nasa.gov/registry/tilecompression/m13\_rice.fits](http://fits.gsfc.nasa.gov/registry/tilecompression/m13_rice.fits) Right, but I don’t think it’s _required_, so we can’t claim that CADC has generated malformed files here. ---
**Author:** ![boutigny](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/boutigny/32/26_2.png) [@boutigny](https://www.rubin.community/u/boutigny)\ **Post date:** [June 6, 2017, 10:17am UTC](https://www.rubin.community/t/ingestimages-py-fails-due-to-missing-entry-in-the-fits-metadata/1391/8 "2017-06-06T10:17:09Z")
Just to close this topic : The fix has been implemented in DM-10487