Possible bug in imcombine v2.14.1?
emma wrote on Oct 29, 2010
Hello :)
I wanted to report a possible bug in imcombine in v2.14.1, related to the new imcmb parameter. In the revsion notes for v2.14.1 (v2141revs.txt), it says:
images.immatch.imcombine
A new parameter "imcmb" was added to control the value written to
the IMCMBnnn keywords in the output image. The value is a keyword
in the input images to be copied to the output IMCMBnnn keywords.
The default parameter value, "$I", is the basename input image
name as before.
This means that, as default, the IMCMBnnn keywords should be written as they would have been using v2.14. However, this appears not to be the case. Running v2.14.1 of imcombine does not write the IMCMBnnn keywords, even when the imcmb parameter is explicitly set to be equal to "$I".
Would it be possible for someone to take a look into this? I would very much like those keywords in the header ;)
Many thanks,
Emma :)
I wanted to report a possible bug in imcombine in v2.14.1, related to the new imcmb parameter. In the revsion notes for v2.14.1 (v2141revs.txt), it says:
images.immatch.imcombine
A new parameter "imcmb" was added to control the value written to
the IMCMBnnn keywords in the output image. The value is a keyword
in the input images to be copied to the output IMCMBnnn keywords.
The default parameter value, "$I", is the basename input image
name as before.
This means that, as default, the IMCMBnnn keywords should be written as they would have been using v2.14. However, this appears not to be the case. Running v2.14.1 of imcombine does not write the IMCMBnnn keywords, even when the imcmb parameter is explicitly set to be equal to "$I".
Would it be possible for someone to take a look into this? I would very much like those keywords in the header ;)
Many thanks,
Emma :)
emma wrote on Oct 29, 2010
Hi Mike,
I was wondering whether you've had the opportunity to take a look at this yet?
Many thanks,
Emma :)
I was wondering whether you've had the opportunity to take a look at this yet?
Many thanks,
Emma :)
Mike Fitzpatrick wrote on Oct 29, 2010
Hi Emma,
Sorry for the delayed reply. I had a chance to verify that in v2.14.1 this feature does indeed appear to work.
I suspect what may have happened is that in the v2.14.1 upgrade the patch file was applied, but the binaries weren't updated so you're still using the original v2.14 version of imcombine. If the date on the $iraf/bin.<arch>/x_images.e binary is before Sep 2008 then this probably explains it.
Sorry for the delayed reply. I had a chance to verify that in v2.14.1 this feature does indeed appear to work.
I suspect what may have happened is that in the v2.14.1 upgrade the patch file was applied, but the binaries weren't updated so you're still using the original v2.14 version of imcombine. If the date on the $iraf/bin.<arch>/x_images.e binary is before Sep 2008 then this probably explains it.
emma wrote on Oct 29, 2010
Hi Mike,
Thanks for the reply :) Unfortunately, this was a fresh install of IRAF v2.14.1; the x_images.e binary is dated September 8, 2008 ...
Is there anything else I could try?
Many thanks,
Emma :)
Thanks for the reply :) Unfortunately, this was a fresh install of IRAF v2.14.1; the x_images.e binary is dated September 8, 2008 ...
Is there anything else I could try?
Many thanks,
Emma :)
Mike Fitzpatrick wrote on Oct 29, 2010
Maybe I'm misunderstanding the problem. The test I tried was
A long listing of the bar.fits head shows each of the input foo*.fits files. If you're doing something different could you post an example?
cl> imcombine foo*.fits bar.fitsA long listing of the bar.fits head shows each of the input foo*.fits files. If you're doing something different could you post an example?
emma wrote on Oct 29, 2010
Ok, I just tried:
imcombine foo*.fits[1] bar.fits
and bar.fits contains a keyword:
NCOMBINE= 11
but no list of IMCMBnnn keywords :(
Something to do with MEFs then?
Thanks!
Emma :)
imcombine foo*.fits[1] bar.fits
and bar.fits contains a keyword:
NCOMBINE= 11
but no list of IMCMBnnn keywords :(
Something to do with MEFs then?
Thanks!
Emma :)
Mike Fitzpatrick wrote on Oct 29, 2010
Yup, it is peculiar to MEF files. Frank is looking at it as a bug we'll fix for the (imminent) v2.15 release.
-Mike
-Mike
emma wrote on Oct 29, 2010
Super, thank you very much! :D
Francisco Valdes wrote on Oct 29, 2010
Hi Emma,
This bug has been identified and fixed. There is no workaround (other than extracting simple images from the MEF before combining).
Sorry for the problem and thanks for reporting this.
Yours,
Frank Valdes
This bug has been identified and fixed. There is no workaround (other than extracting simple images from the MEF before combining).
Sorry for the problem and thanks for reporting this.
Yours,
Frank Valdes
NUMBER: 567
MODULE: imcombine and relatives
SYSTEM: V2.14
DATE: Wed Nov 17 15:14:11 MST 2010
FROM: valdes
BUG: The addition of the image names using imcmb="$I" does not work for
input images with a square bracket; e.g. foo[1], foo[im1], foo[*,*].
The IMCMB value, in order to allow long filenames, is stripped of
any path. For an obscure reason related to VMS directories this
code failed to find a rootname.
STATUS: This has been fixed for the next release.
Last post on Oct 29, 2010