WCS — KeyError: u"Keyword 'A_0_0' not found." #82

paramoreta · 2016-04-28T16:08:04Z

Dear PyBro,

Trying to perform photometry over a selection of images (all equal in header keywords):

photometry.py --overwrite cig/cig96_20120911_CousinsR_001-b-o-f-c-t.fits cig/*-t.fits cig/cig96.db

returns an error that I do not understand:

_>> Examining the headers of the 71 FITS files given as input...
>> 100%[======================================================================>]
>> 1 different photometric filters were detected:
>>  Cousins R: 71 files (100.00 %)
>> Making sure there are no images with the same date and filter... done.
>> Sources image: cig/cig96_20120911_CousinsR_001-b-o-f-c-t.fits
>> Running SExtractor on the sources image... done.
>> Calculating coordinates of field center...
_

WARNING: VerifyWarning: Invalid 'BLANK' keyword in header.  The 'BLANK' keyword is only applicable to integer data, and will be ignored in this HDU. [astropy.io.fits.hdu.image]
2016-04-27 12:12:59,518 - astropy - WARNING - VerifyWarning: Invalid 'BLANK' keyword in header.  The 'BLANK' keyword is only applicable to integer data, and will be ignored in this HDU.
Traceback (most recent call last):
  File "/mnt/DATA/pablo/work/routines/lemon/photometry.py", line 1575, in <module>
    sys.exit(main())
  File "/mnt/DATA/pablo/work/routines/lemon/photometry.py", line 917, in main
    ra, dec = sources_img.center_wcs()
  File "/mnt/DATA/pablo/work/routines/lemon/fitsimage.py", line 723, in center_wcs
    return self.pix2world(*center)
  File "/mnt/DATA/pablo/work/routines/lemon/fitsimage.py", line 681, in pix2world
    wcs = self._get_wcs()
  File "/mnt/DATA/pablo/work/routines/lemon/methods.py", line 388, in memf
    cache[args, fkwargs] = f(*args, **kwargs)
  File "/mnt/DATA/pablo/work/routines/lemon/fitsimage.py", line 665, in _get_wcs
    return astropy.wcs.WCS(header)
  File "/usr/local/lib/python2.7/dist-packages/astropy/wcs/wcs.py", line 415, in __init__
    self._remove_sip_kw(tmp_header)
  File "/usr/local/lib/python2.7/dist-packages/astropy/wcs/wcs.py", line 991, in _remove_sip_kw
    del header[key]
  File "/usr/local/lib/python2.7/dist-packages/astropy/io/fits/header.py", line 227, in __delitem__
    raise KeyError("Keyword '%s' not found." % key)
KeyError: u"Keyword 'A_0_0' not found."

To prevent another error I was getting when using photometry.py, and just FYI (it ignore if this might be relevant for the current error) did as follows:

While my original images had the filter keyword labeled as "INSFLNAM" (beats me why astronomers thought that would be a suitable keyword name for the filter), I have manually added a new keyword "FILTER" with the same filter value.
This is:

Originally, the only keyword was:
INSFLAN = "Cousins R"
After the addition of a new one, both coexist (the original was not erased):
INSFLAN = "Cousins R"
FILTER = "Cousins R"

In my eyes, this filter keyword seems unrelated to the current error (coordinates related?) but it might be relevant somehow so I preferred to post it anyway, just in case.

If my suspicion about the coordinates is by any chance close to the problem, I must add that I have checked that all images have their proper WCS coordinates.

Any light over this dark path?

Thanks!

The text was updated successfully, but these errors were encountered:

vterron · 2016-04-29T00:09:45Z

This looks a lot like a problem caused by non-standard WCS keywords, which (that's the problem with... non-standard stuff) cause AstroPy to die amidst screams and explosions. These are images from the good'n old CAHA, right? I remember experiencing a very similar problem in the past, if not exactly the same. What I ended up doing was to remove all the WCS keywords that CAHA wrote to the headers, and them run astrometry do solve them astrometrically, this time properly. I think @javierblasco had a Python script that did exactly that — any chance you could ping him?

javierblasco · 2016-04-29T08:30:18Z

It is true I have a script in repipy to remove the WCS from the headers, called wipe_wcs.py, actually.

paramoreta · 2016-04-29T08:53:57Z

Thank you two for the input (and for rephrasing of the issue title).

Indeed these are CAHA observatory images.
Fun fact: I run wipe_wcs + astrom.py (both from @javierblasco) as the very first step of the whole data reduction.

I am doing this again as we speak though... and It still raises the same error:

wipe_wcs.py cig/*-t.fits
astrom.py --overwrite --radius 1 cig/*-t.fits

No error, and right after wiping+adding WCS, I run the photometry routine:

photometry.py --overwrite cig/cig96_20120911_CousinsR_001-b-o-f-c-t.fits cig/*-t.fits cig/cig96.db

>> Examining the headers of the 71 FITS files given as input...
>> 100%[======================================================================>]
>> 1 different photometric filters were detected:
>>  Cousins R: 71 files (100.00 %)
>> Making sure there are no images with the same date and filter... done.
>> Sources image: cig/cig96_20120911_CousinsR_001-b-o-f-c-t.fits
>> Running SExtractor on the sources image... done.
>> Calculating coordinates of field center...

WARNING: VerifyWarning: Invalid 'BLANK' keyword in header.  The 'BLANK' keyword is only applicable to integer data, and will be ignored in this HDU. [astropy.io.fits.hdu.image]
2016-04-29 10:52:17,628 - astropy - WARNING - VerifyWarning: Invalid 'BLANK' keyword in header.  The 'BLANK' keyword is only applicable to integer data, and will be ignored in this HDU.
Traceback (most recent call last):
  File "/mnt/DATA/pablo/work/routines/lemon/photometry.py", line 1575, in <module>
    sys.exit(main())
  File "/mnt/DATA/pablo/work/routines/lemon/photometry.py", line 917, in main
    ra, dec = sources_img.center_wcs()
  File "/mnt/DATA/pablo/work/routines/lemon/fitsimage.py", line 723, in center_wcs
    return self.pix2world(*center)
  File "/mnt/DATA/pablo/work/routines/lemon/fitsimage.py", line 681, in pix2world
    wcs = self._get_wcs()
  File "/mnt/DATA/pablo/work/routines/lemon/methods.py", line 388, in memf
    cache[args, fkwargs] = f(*args, **kwargs)
  File "/mnt/DATA/pablo/work/routines/lemon/fitsimage.py", line 665, in _get_wcs
    return astropy.wcs.WCS(header)
  File "/usr/local/lib/python2.7/dist-packages/astropy/wcs/wcs.py", line 415, in __init__
    self._remove_sip_kw(tmp_header)
  File "/usr/local/lib/python2.7/dist-packages/astropy/wcs/wcs.py", line 991, in _remove_sip_kw
    del header[key]
  File "/usr/local/lib/python2.7/dist-packages/astropy/io/fits/header.py", line 227, in __delitem__
    raise KeyError("Keyword '%s' not found." % key)
KeyError: u"Keyword 'A_0_0' not found."

vterron · 2016-04-29T20:56:07Z

Could it be that the keyword 'A_0_0' were in the original FITS headers, but
Javier's script were not removing it? In other words: is it present in the
original files? If so, does it go away after running the script? We
basically need to answer the question "at which point is this monster
written to the header?"
On Apr 29, 2016 09:53, "Pablo R. M." [email protected] wrote:

Thank you two for the input (and for rephrasing of the issue title).

Indeed these are CAHA observatory images.
Fun fact: I run wipe_wcs + astrom.py (both from @javierblasco
https://github.com/javierblasco) as the very first step of the whole
data reduction.

I am doing this again as we speak though... and It still raises the same
error:

wipe_wcs.py cig/-t.fits
astrom.py --overwrite --radius 1 cig/-t.fits

(no error)

Examining the headers of the 71 FITS files given as input...
100%[======================================================================>]
1 different photometric filters were detected:
Cousins R: 71 files (100.00 %)
Making sure there are no images with the same date and filter... done.
Sources image: cig/cig96_20120911_CousinsR_001-b-o-f-c-t.fits
Running SExtractor on the sources image... done.
Calculating coordinates of field center...

WARNING: VerifyWarning: Invalid 'BLANK' keyword in header. The 'BLANK' keyword is only applicable to integer data, and will be ignored in this HDU. [astropy.io.fits.hdu.image]
2016-04-29 10:52:17,628 - astropy - WARNING - VerifyWarning: Invalid 'BLANK' keyword in header. The 'BLANK' keyword is only applicable to integer data, and will be ignored in this HDU.
Traceback (most recent call last):
File "/mnt/DATA/pablo/work/routines/lemon/photometry.py", line 1575, in
sys.exit(main())
File "/mnt/DATA/pablo/work/routines/lemon/photometry.py", line 917, in main
ra, dec = sources_img.center_wcs()
File "/mnt/DATA/pablo/work/routines/lemon/fitsimage.py", line 723, in center_wcs
return self.pix2world(_center)
File "/mnt/DATA/pablo/work/routines/lemon/fitsimage.py", line 681, in pix2world
wcs = self._get_wcs()
File "/mnt/DATA/pablo/work/routines/lemon/methods.py", line 388, in memf
cache[args, fkwargs] = f(_args, **kwargs)
File "/mnt/DATA/pablo/work/routines/lemon/fitsimage.py", line 665, in _get_wcs
return astropy.wcs.WCS(header)
File "/usr/local/lib/python2.7/dist-packages/astropy/wcs/wcs.py", line 415, in init
self._remove_sip_kw(tmp_header)
File "/usr/local/lib/python2.7/dist-packages/astropy/wcs/wcs.py", line 991, in _remove_sip_kw
del header[key]
File "/usr/local/lib/python2.7/dist-packages/astropy/io/fits/header.py", line 227, in delitem
raise KeyError("Keyword '%s' not found." % key)
KeyError: u"Keyword 'A_0_0' not found."

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#82 (comment)

paramoreta · 2016-05-03T10:16:00Z

Could it be that the keyword 'A_0_0' were in the original FITS headers, but Javier's script were not removing it? In other words: is it present in the original files? If so, does it go away after running the script?

Yes, "A_0_0" keyword is present in every original FITS file header (as well as in those upon which photometry is being run) and no, Javier's scripts are not deleting or modifying it at any point.

IMHO, the question should be then rephrased to: why can not the photometry.py task find the keyword that is present in all the headers?

Or a less obvious but far more usual: might this user be misunderstanding the use of photometry.py task?
Unlikely since the task starts to run and the error points to a header problem but... maybe?

Just FYI, this is how I understood the use of the task:

photometry.py --overwrite cig/cig96_20120911_CousinsR_001-b-o-f-c-t.fits cig/*-t.fits cig/cig96.db

--overwrite [self explanatory]
cig/cig96_20120911_CousinsR_001-b-o-f-c-t.fits [sources image; I select, in this case, the first image among the 71 of available science images]
cig/*-t.fits [input images over which the photometry must be calculated (from 1 to 71)]
cig/cig96.db [output database in which the measurements will be stored; this db does not exist so a name must be provided]

paramoreta · 2016-05-03T11:56:49Z

Addendum.

Part of the FITS file header of the image:
cig/cig96_20120911_CousinsR_001-b-o-f-c-t.fits

where theA_0_0 keyword is:

A_ORDER =                    2 / Polynomial order, axis 1                       
A_0_0   =                    0 / no comment                                     
A_0_1   =                    0 / no comment                                     
A_0_2   =   -1.53681784102E-05 / no comment                                     
A_1_0   =                    0 / no comment                                     
A_1_1   =    1.45457447586E-05 / no comment                                     
A_2_0   =   -3.99817992516E-06 / no comment                                     
B_ORDER =                    2 / Polynomial order, axis 2                       
B_0_0   =                    0 / no comment                                     
B_0_1   =                    0 / no comment                                     
B_0_2   =   -5.13208652603E-07 / no comment                                     
B_1_0   =                    0 / no comment                                     
B_1_1   =   -1.32357516399E-05 / no comment                                     
B_2_0   =    2.60071080208E-06 / no comment                                     
AP_ORDER=                    2 / Inv polynomial order, axis 1                   
AP_0_0  =     -0.0101643113374 / no comment                                     
AP_0_1  =   -7.08650161246E-05 / no comment                                     
AP_0_2  =     1.5455032245E-05 / no comment                                     
AP_1_0  =    7.06070381388E-05 / no comment                                     
AP_1_1  =   -1.47344598324E-05 / no comment                                     
AP_2_0  =    4.05108886854E-06 / no comment                                     
BP_ORDER=                    2 / Inv polynomial order, axis 2                   
BP_0_0  =     0.00766996447064 / no comment                                     
BP_0_1  =    5.69021596807E-05 / no comment                                     
BP_0_2  =    4.38160875321E-07 / no comment                                     
BP_1_0  =    -2.9516810945E-05 / no comment                                     
BP_1_1  =    1.33074658603E-05 / no comment                                     
BP_2_0  =    -2.6375227472E-06 / no comment

hbouy · 2016-05-03T14:08:30Z

You can easily remove all these TAN-SIP keywords using missfits:
missfits -REMOVE_KEYWORD A_?,B_?,AP_?,BP_? *fits

if your camera's distortions are not too bad, it should not compromise the analysis.

paramoreta · 2016-05-03T16:53:13Z

Thanks for your input @hbouy. I guess that could help if I needed to remove the A_0_0 etc. keywords but the error seems to point the other way round, doesn't it? Not finding the keyword is bothering the script so removing it should cause a similar behavior. The problem I see is that while the keyword does exist, the script does not detect it.

vterron · 2016-05-03T23:19:25Z

You're right that the error message complains that keyword "A_0_0" is not found, but if this indeed is being caused by non-standard WCS keywords this could bite us in many shapes and forms. In other words: the keywords may be there, but AstroPy —this is just a guess, though— fail to read them at some point because they fail to conform to the standard.

My approach to test whether this theory makes sense would be: (a) removing all the existing WCS keywords, as suggested by @hbouy — thanks! and then (b) running the astrometry command on them, so that standard WCS keywords are written to the headers by Astrometry.net. In this manner we would be effectively wiping out the CAHA astrometric solution, replacing it with a standard-compliant —and most likely also more precise— one.

[Your understanding of how photometry works is absolutely correct]

paramoreta · 2016-05-04T15:23:34Z

Update:
I tried the option (a) that both of you @hbouy and @vterron suggested and then option (b), followed by the same photometry task. Thanks a lot for your suggestions. Partial success!

A different error raises when running photometry.py.

Here are the steps and returned outputs:

First, I run the missfits task to remove the A_0_0 et al. keywords:

missfits -REMOVE_KEYWORD A_?,B_?,AP_?,BP_? cig/test/*.fits
returning:

----- MissFITS 2.8.0 started on 2016-05-04 at 12:45:52 with 1 thread
> Examining input data...
> Looking for cig/test/cig96_20120912_CousinsR_067-b-o-f-c-t.head
> Reading input data...
> 
cig96_20120912_CousinsR_067-b-o-f-c-t.fits      "CIG96   "
> Looking for cig/test/cig96_20120912_CousinsR_068-b-o-f-c-t.head
> Reading input data...
> 
cig96_20120912_CousinsR_068-b-o-f-c-t.fits      "CIG96   "
> Looking for cig/test/cig96_20120912_CousinsR_069-b-o-f-c-t.head
> Reading input data...
> 
cig96_20120912_CousinsR_069-b-o-f-c-t.fits      "CIG96   "
> Looking for cig/test/cig96_20120912_CousinsR_070-b-o-f-c-t.head
> Reading input data...
> 
cig96_20120912_CousinsR_070-b-o-f-c-t.fits      "CIG96   "
> Writing XML file...
> 
> All done (in 0.1 s)

> WARNING: default.missfits not found, using internal defaults

(all seems good)

Then, I wipe WCS coordinates and run again the astrom.py task

wipe_wcs.py cig/test/*-t.fits
astrom.py --overwrite --radius 1 cig/test/*-t.fits

(all good here)

Finally, same photometry.py task as before, that does not fully work yet it starts:

>> Examining the headers of the 4 FITS files given as input...
>> 100%[======================================================================>]
>> 1 different photometric filters were detected:
>>  Cousins R: 4 files (100.00 %)
>> Making sure there are no images with the same date and filter... done.
>> Sources image: cig/test/cig96_20120912_CousinsR_067-b-o-f-c-t.fits
>> Running SExtractor on the sources image... done.
>> Calculating coordinates of field center... done.
>> α =  33.8568686  (02 15 25.65)
>> δ =   6.0102173 (+06 00 36.78)
>> Detected 2472 sources on which to do photometry.
>> 
>> Need to determine the instrumental magnitude of each source.
>> Doing photometry on the sources image, using the parameters:
>> FWHM (sources image) = 2.571 pixels, therefore:
>> Aperture radius = 2.571 x 3.00 = 7.713 pixels
>> Sky annulus, inner radius = 2.571 x 4.50 = 11.569 pixels
>> Sky annulus, width = 2.571 x 1.00 = 2.571 pixels
>> 
>> Running IRAF's qphot... done.
>> Detecting INDEF objects... done.
>> 1169 objects are INDEF in the sources image.
>> There are 1303 objects left on which to do photometry.
>> Making sure INDEF objects were removed... done.
>> 
>> Initializing output LEMONdB... done.
>> 
>> Let's do photometry on the 4 images taken in the Cousins R filter.
>> Calculating the median FWHM for this filter... done.
>> FWHM (Cousins R) = 2.567 pixels, therefore:
>> Aperture radius = 2.567 x 3.00 = 7.701 pixels
>> Sky annulus, inner radius = 2.567 x 4.50 = 11.552 pixels
>> Sky annulus, width = 2.567 x 1.00 = 2.567 pixels
>> 0%[>                                                                        ]

WARNING: VerifyWarning: Invalid 'BLANK' keyword in header.  The 'BLANK' keyword is only applicable to integer data, and will be ignored in this HDU. [astropy.io.fits.hdu.image]
2016-05-04 14:42:58,540 - astropy - WARNING - VerifyWarning: Invalid 'BLANK' keyword in header.  The 'BLANK' keyword is only applicable to integer data, and will be ignored in this HDU.
/mnt/DATA/pablo/work/routines/lemon/photometry.py:1003: UserWarning: >> Whoops! Sky annulus too thin, setting it to the minimum of 3.00 pixels
  warnings.warn(msg % sources_dannulus)
/usr/lib/python2.7/dist-packages/scipy/stats/stats.py:1373: VisibleDeprecationWarning: using a non-integer number instead of an integer will result in an error in the future
  return values[idx]
/mnt/DATA/pablo/work/routines/lemon/photometry.py:1324: UserWarning: >> Whoops! Sky annulus too thin, setting it to the minimum of 3.00 pixels
  warnings.warn(msg % dannulus)
Traceback (most recent call last):
  File "/mnt/DATA/pablo/work/routines/lemon/methods.py", line 592, in wrapper
    return func(*args, **kwargs)
  File "/mnt/DATA/pablo/work/routines/lemon/photometry.py", line 208, in parallel_photometry
    gain = options.gain or image.read_keyword(options.gaink)
  File "/mnt/DATA/pablo/work/routines/lemon/fitsimage.py", line 193, in read_keyword
    raise KeyError(msg)
KeyError: "cig/test/cig96_20120912_CousinsR_070-b-o-f-c-t.fits: keyword 'GAIN' not found"
Traceback (most recent call last):
  File "/mnt/DATA/pablo/work/routines/lemon/methods.py", line 592, in wrapper
    return func(*args, **kwargs)
  File "/mnt/DATA/pablo/work/routines/lemon/photometry.py", line 208, in parallel_photometry
    gain = options.gain or image.read_keyword(options.gaink)
  File "/mnt/DATA/pablo/work/routines/lemon/fitsimage.py", line 193, in read_keyword
    raise KeyError(msg)
KeyError: "cig/test/cig96_20120912_CousinsR_069-b-o-f-c-t.fits: keyword 'GAIN' not found"
Traceback (most recent call last):
  File "/mnt/DATA/pablo/work/routines/lemon/methods.py", line 592, in wrapper
    return func(*args, **kwargs)
  File "/mnt/DATA/pablo/work/routines/lemon/photometry.py", line 208, in parallel_photometry
    gain = options.gain or image.read_keyword(options.gaink)
  File "/mnt/DATA/pablo/work/routines/lemon/fitsimage.py", line 193, in read_keyword
    raise KeyError(msg)
KeyError: "cig/test/cig96_20120912_CousinsR_067-b-o-f-c-t.fits: keyword 'GAIN' not found"
Traceback (most recent call last):
  File "/mnt/DATA/pablo/work/routines/lemon/methods.py", line 592, in wrapper
    return func(*args, **kwargs)
  File "/mnt/DATA/pablo/work/routines/lemon/photometry.py", line 208, in parallel_photometry
    gain = options.gain or image.read_keyword(options.gaink)
  File "/mnt/DATA/pablo/work/routines/lemon/fitsimage.py", line 193, in read_keyword
    raise KeyError(msg)
KeyError: "cig/test/cig96_20120912_CousinsR_068-b-o-f-c-t.fits: keyword 'GAIN' not found"
Traceback (most recent call last):
  File "/mnt/DATA/pablo/work/routines/lemon/photometry.py", line 1575, in <module>
    sys.exit(main())
  File "/mnt/DATA/pablo/work/routines/lemon/photometry.py", line 1411, in main
    result.get() # reraise exceptions of the remote call, if any
  File "/usr/lib/python2.7/multiprocessing/pool.py", line 554, in get
    raise self._value
KeyError: "cig/test/cig96_20120912_CousinsR_070-b-o-f-c-t.fits: keyword 'GAIN' not found"

This time, the case is more simple: GAIN keyword is not found.
My CAHA images contain:

CCDGAIN =               20.000 / total analog Gain                              
CCDSENS =                1.430 / Sensitivity at selected Gain (e-/DN)

but I am not sure of which one is necessary.
I understand that renaming the keyword or adding a new keyword named "GAIN" would do, wouldn't it?

vterron · 2016-05-04T22:20:09Z

You don't need to modify the headers. From the help of photometry:

--gaink=        keyword for the gain of the CCD, in e-/ADU. Needed in
                order to accurately calculate the SNR of each
                measurement [default: GAIN]

So you just need to run the command again with --gaink=CCDGAIN

[By the way, astrom.py is not a LEMON script. I assume it's some kind of wrapper around the astrometry command]

paramoreta · 2016-05-05T14:30:35Z

I had completely missed that one, thanks @vterron.
And yes, you are correct, astrom.py is not part of LEMON but a wrapper from @javierblasco 's package 'repipy'.

And well, it all has finally worked! Thanks a lot @hbouy and @vterron for your fantastic inputs.

paramoreta · 2016-05-09T10:23:21Z

Well, this is unexpected:
Despite the photometry routine works, the database created seems to be empty.

photometry.py --overwrite --gaink=CCDSENS cig/cig96_20120912_CousinsR_001-b-o-f-c-t.fits cig/*-t.fits cig/cig96test.db

Returns:

>> Examining the headers of the 71 FITS files given as input...
>> 100%[======================================================================>]
>> 1 different photometric filters were detected:
>>  Cousins R: 71 files (100.00 %)
>> Making sure there are no images with the same date and filter... done.
>> Sources image: cig/cig96_20120912_CousinsR_001-b-o-f-c-t.fits
>> Running SExtractor on the sources image... done.
>> Calculating coordinates of field center... done.
>> α =  33.8530669  (02 15 24.74)
>> δ =   6.0054958 (+06 00 19.78)
>> Detected 2752 sources on which to do photometry.
>> 
>> Need to determine the instrumental magnitude of each source.
>> Doing photometry on the sources image, using the parameters:
>> FWHM (sources image) = 2.644 pixels, therefore:
>> Aperture radius = 2.644 x 3.00 = 7.932 pixels
>> Sky annulus, inner radius = 2.644 x 4.50 = 11.898 pixels
>> Sky annulus, width = 2.644 x 1.00 = 2.644 pixels
>> 
>> Running IRAF's qphot... done.
>> Detecting INDEF objects... done.
>> 1363 objects are INDEF in the sources image.
>> There are 1389 objects left on which to do photometry.
>> Making sure INDEF objects were removed... done.
>> 
>> Initializing output LEMONdB... done.
>> 
>> Let's do photometry on the 71 images taken in the Cousins R filter.
>> Calculating the median FWHM for this filter... done.
>> FWHM (Cousins R) = 2.515 pixels, therefore:
>> Aperture radius = 2.515 x 3.00 = 7.545 pixels
>> Sky annulus, inner radius = 2.515 x 4.50 = 11.317 pixels
>> Sky annulus, width = 2.515 x 1.00 = 2.515 pixels
>> 100%[======================================================================>]
>> Storing photometric measurements in the database...
>> 100%[======================================================================>]
>> Gathering statistics about tables and indexes... done.
>> You're done ^_^

Extra warning:

WARNING: VerifyWarning: Invalid 'BLANK' keyword in header.  The 'BLANK' keyword is only applicable to integer data, and will be ignored in this HDU. [astropy.io.fits.hdu.image]
2016-05-04 19:37:25,240 - astropy - WARNING - VerifyWarning: Invalid 'BLANK' keyword in header.  The 'BLANK' keyword is only applicable to integer data, and will be ignored in this HDU.
/mnt/DATA/pablo/work/routines/lemon/photometry.py:1003: UserWarning: >> Whoops! Sky annulus too thin, setting it to the minimum of 3.00 pixels
  warnings.warn(msg % sources_dannulus)
/usr/lib/python2.7/dist-packages/scipy/stats/stats.py:1373: VisibleDeprecationWarning: using a non-integer number instead of an integer will result in an error in the future
  return values[idx]
/mnt/DATA/pablo/work/routines/lemon/photometry.py:1324: UserWarning: >> Whoops! Sky annulus too thin, setting it to the minimum of 3.00 pixels
  warnings.warn(msg % dannulus)

This seems to be fine but when checking out the database, it seems to be empty:

a = extract.main("cig/cig96.db")
print a

(array([], shape=(0, 0), dtype=float64), array([], shape=(0, 0), dtype=float64), array([], shape=(0, 0), 
      dtype='|S15'), array([], shape=(0, 0), dtype=float64), array([], shape=(0, 0), 
      dtype='|S100'))

I can't really figure out why it is empty... Is it really relevant which source image I take, considering that in terms of counts and image quality, the one I chose is as good as the rest?

vterron · 2016-05-09T22:08:48Z

I can't tell for sure because extract.main() is not part of the pipeline (I assume it also belongs to repipy), but my theory is that there's a problem with the minimum number of comparison stars or images. See issue #76 for further information. I suspect that running photometry again with a couple of -v flags will show countless warnings explaining that and why the light curves could not be generated.

Also, just to make doubly sure — I assume that if you open the database with juicer you don't see any light curves either, right?

paramoreta · 2016-05-10T16:20:42Z

Apologies. I keep mixing tasks from both packages repipy and LEMON by mistake.
As a statement that Captain Obvious could sign himself, I'll just say that extract.main() gives the shape, type, etc. of the database and I run it just to check that the database created with photometry task had 'volume' and data in it.

Ok.
I think stopping here is the proper way to go now. The main issue (the key error A_0_0) is solved and it is quite likely that my images (and/or reduction) are not really suitable for photometry.py as they re now.
There are things missing and some other more simple routines are also failing to work properly so I need to make a full review of the reduction before going on.

Thanks guys for all the help provided so far!

vterron · 2016-05-10T22:44:24Z

I agree that's the most sensible approach. Let's close this issue and please open as many as you need if you come across other problems.

One last note, for the record — although using one of the images for sources detection (the first one passed to photometry, it never hurts to use an image with as much signal-to-noise ratio as possible. This improves the accuracy of the centroid detection of each astronomical object (and therefore also its celestial coordinates), especially in the case of faint ones. My suggestion would be to run lemon mosaic in order to combine all your images into a single one and then feed it as the first argument of `photometry.

vterron changed the title ~~Keyword unrecognition - photometry.py~~ WCS — KeyError: u"Keyword 'A_0_0' not found." Apr 29, 2016

vterron closed this as completed May 10, 2016

vterron added the question label May 10, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WCS — KeyError: u"Keyword 'A_0_0' not found." #82

WCS — KeyError: u"Keyword 'A_0_0' not found." #82

paramoreta commented Apr 28, 2016

vterron commented Apr 29, 2016 •

edited

Loading

javierblasco commented Apr 29, 2016

paramoreta commented Apr 29, 2016 •

edited

Loading

vterron commented Apr 29, 2016

paramoreta commented May 3, 2016

paramoreta commented May 3, 2016

hbouy commented May 3, 2016

paramoreta commented May 3, 2016

vterron commented May 3, 2016 •

edited

Loading

paramoreta commented May 4, 2016 •

edited

Loading

vterron commented May 4, 2016

paramoreta commented May 5, 2016

paramoreta commented May 9, 2016

vterron commented May 9, 2016

paramoreta commented May 10, 2016

vterron commented May 10, 2016

WCS — KeyError: u"Keyword 'A_0_0' not found." #82

WCS — KeyError: u"Keyword 'A_0_0' not found." #82

Comments

paramoreta commented Apr 28, 2016

vterron commented Apr 29, 2016 • edited Loading

javierblasco commented Apr 29, 2016

paramoreta commented Apr 29, 2016 • edited Loading

vterron commented Apr 29, 2016

paramoreta commented May 3, 2016

paramoreta commented May 3, 2016

hbouy commented May 3, 2016

paramoreta commented May 3, 2016

vterron commented May 3, 2016 • edited Loading

paramoreta commented May 4, 2016 • edited Loading

vterron commented May 4, 2016

paramoreta commented May 5, 2016

paramoreta commented May 9, 2016

vterron commented May 9, 2016

paramoreta commented May 10, 2016

vterron commented May 10, 2016

vterron commented Apr 29, 2016 •

edited

Loading

paramoreta commented Apr 29, 2016 •

edited

Loading

vterron commented May 3, 2016 •

edited

Loading

paramoreta commented May 4, 2016 •

edited

Loading