Problem with DAOPhot
craigswenson wrote on Jul 10, 2007
I'm getting an error when running the DAOPhot 'group' command that I don't know how to resolve.
Warning: Image header parameter not found (FUNCTION)
I've been experimenting with the autoalign.cl script and I'm sure it must be changing something in my header, but I'm not sure how to fix/update my header. I haven't been able to find out what is being modified in my headers yet, because whatever it is isn't displayed in the regular "full" header.
DAOPhot works fine on my un-aligned frames, so there's nothing wrong with the headers until after the align script is run.
Any ideas would be appreciated.
Thank you.
Warning: Image header parameter not found (FUNCTION)
I've been experimenting with the autoalign.cl script and I'm sure it must be changing something in my header, but I'm not sure how to fix/update my header. I haven't been able to find out what is being modified in my headers yet, because whatever it is isn't displayed in the regular "full" header.
DAOPhot works fine on my un-aligned frames, so there's nothing wrong with the headers until after the align script is run.
Any ideas would be appreciated.
Thank you.
Mike Fitzpatrick wrote on Jul 10, 2007
From an earlier reply to a similar problem:
Write back if you still have problems.
-Mike
As you already know, allstar needs the header parameter FUNCTION, from
the psf image, to fit the psf for all other stars. This parameter is
written when you run the psf task, which gets the FUNCTION parameter
from 'daopars'.
If you take a look at the psf header, you should find parameters such
as PSFX, PSFY, PSFHEIGHT, and PSFMAG. These are accompanied by the
FUNCTION parameter.
If the FUNCTION parameter is missing, you should check that you have the
function type set in 'daopars' (see 'phelp daopars' for a list of
available functions). Also be sure that 'update' is set to 'yes' in the
daophot parameters (epar daophot).
Write back if you still have problems.
-Mike
craigswenson wrote on Jul 10, 2007
Setting update to yes fixed my problem. Thank you very much.
dvodonnell wrote on Jul 10, 2007
I'm having the same problem, and setting Update to Yes didn't seem to fix it. I've used imheader on the psf .imh and it seems to report that there's no PIXEL file.
Any ideas?
Thanks.;.
Any ideas?
Thanks.;.
Mike Fitzpatrick wrote on Jul 10, 2007
If you mean the long IMHEADER output contains a line such as:
then it means the pixel file associated with the .imh can't be found. This can happen when you move imh images between machines and forget to copy the .pix files, have an invalid 'imdir' so it couldn't be created, or the directory doesn't exist. You can HEDIT the 'i_pixfile' header parameter to reset this pathname and reconnect to the .pix file, otherwise check that your 'imdir' directory exists and you can write to it (the value is set in login.cl).
Updating/reading of headers should still be allowed, but sometimes errors cascade from some underlying reason like this and so may be bogus. Try fixing the pixel file problem first.
Cheers,
-Mike
Pixel file "/tmp/foo.pix" [NO PIXEL FILE]then it means the pixel file associated with the .imh can't be found. This can happen when you move imh images between machines and forget to copy the .pix files, have an invalid 'imdir' so it couldn't be created, or the directory doesn't exist. You can HEDIT the 'i_pixfile' header parameter to reset this pathname and reconnect to the .pix file, otherwise check that your 'imdir' directory exists and you can write to it (the value is set in login.cl).
Updating/reading of headers should still be allowed, but sometimes errors cascade from some underlying reason like this and so may be bogus. Try fixing the pixel file problem first.
Cheers,
-Mike
dvodonnell wrote on Jul 10, 2007
Hmm, well I'm simply working in a single directory -- all of my other daofind, phot, pstselect (etc) output is being created fine. I don't know why there would be a problem with the .pix file.
I have both image.imh and image.pix in the directory, shouldn't it automatically detect it there?
If not, perhaps the problem is with my login.cl. Is there something that tells me what login.cl file IRAF is currently using (I have about 6 on my machine in various places...).
Thanks again for the help -- haven't used IRAF in a long time!
I have both image.imh and image.pix in the directory, shouldn't it automatically detect it there?
If not, perhaps the problem is with my login.cl. Is there something that tells me what login.cl file IRAF is currently using (I have about 6 on my machine in various places...).
Thanks again for the help -- haven't used IRAF in a long time!
dvodonnell wrote on Jul 10, 2007
update -- imh is seeing the pix now
still getting the Function error however
still getting the Function error however
Mike Fitzpatrick wrote on Jul 10, 2007
I have both image.imh and image.pix in the directory, shouldn't it automatically detect it there? [/quote[f not, perhaps the problem is with my login.cl. Is there something that tells me what login.cl file IRAF is currently using (I have about 6 on my machine in various places...). [/quote]
Only if the i_pixfile and your 'imdir' use "HDR$" to tell it to look in the same directory as the .imh file, otherwise it's an explicit path (with a node! prefix usually.
Do a "cl> show home". Note that certain paths are created by MKIRAF when writing the login.cl that may become invalid if what you do is simply copy the login.cl file to a new location rather than do a separate MKIRAF.
-Mike
dvodonnell wrote on Jul 10, 2007
Should the psf have its own pix file? apart from the pix that corresponds to the original image file?
if so, that's probably the problem here, because a psf pix file is not being generated, only a psf.imh.
if so, that's probably the problem here, because a psf pix file is not being generated, only a psf.imh.
Mike Fitzpatrick wrote on Jul 10, 2007
Then do a "cl> show imdir" to see where it's trying to put the .pix file and make sure it's valid. You can do
To reset it so the .pix is in the same dir as the .imh, and edit the login.cl to make the change for the next time.
-Mike
cl> reset imdir = HDR$
cl> flpr 0 # zero not oh
To reset it so the .pix is in the same dir as the .imh, and edit the login.cl to make the change for the next time.
-Mike
dvodonnell wrote on Jul 10, 2007
I've set the path to HDR$, and still no .pix file. I've done a system search and it doesn't look like it's putting it anywhere.
Really appreciate your help here Mike...
Really appreciate your help here Mike...
Mike Fitzpatrick wrote on Jul 10, 2007
Try a simple test first like
Do you get both a foo.imh and foo.pix file in the current directory or some error message? Did you do the 'flpr' so tasks would reset with the new value? Is you 'imtype' variable set to 'imh' or are you putting that explicitly as an extension to the image name?
-Mike
cl> imcopy dev$pix fooDo you get both a foo.imh and foo.pix file in the current directory or some error message? Did you do the 'flpr' so tasks would reset with the new value? Is you 'imtype' variable set to 'imh' or are you putting that explicitly as an extension to the image name?
-Mike
dvodonnell wrote on Jul 10, 2007
The test works fine -- imcopy gives me both a .imh and .pix.
I have been specifying image.imh (including the extension) at the prompts.
I have been specifying image.imh (including the extension) at the prompts.
dvodonnell wrote on Jul 10, 2007
...and if I remove the .imh extension, it reports an ambiguous image name, even though imtype is indeed set to imh.
Mike Fitzpatrick wrote on Jul 10, 2007
The 'ambiguous' name means you've got e.g. an image.fits and an image.imh in the same directory. The message comes when referring only to 'image', which some tasks may do internally. Note you can work on the FITS file directly (e.g. set 'imtype' to be 'fits' so new images are created as 'FITS'), otherwise it's best to move the files with the problematic extensions.
-Mike
-Mike
dvodonnell wrote on Jul 10, 2007
Ok, that's fine now, it will read the files without putting .imh. Unfortunately I still have absolutely no idea why this silly thing isn't producing a .pix.
Any remaining ideas greatly appreciated....
Any remaining ideas greatly appreciated....
Mike Fitzpatrick wrote on Jul 10, 2007
Let's backup a bit then: Is there indeed a FUNCTION keyword in your psf.imh header in the first place? If so, the lack of a .pix may be the masked cascading problem I mentioned earlier; If not, then the question is 'How are you creating the psf.imh image"?
The imcopy test indicates your 'imdir' is fine. A missing .pix can also occur if an image was mapped (created) but then an error occurred when writing it. Sometimes obscure things like a /tmp directory at 100% capacity can cause it, other times its a more obvious error message from the system.
-Mike
The imcopy test indicates your 'imdir' is fine. A missing .pix can also occur if an image was mapped (created) but then an error occurred when writing it. Sometimes obscure things like a /tmp directory at 100% capacity can cause it, other times its a more obvious error message from the system.
-Mike
dvodonnell wrote on Jul 10, 2007
Here's my imheader output on my psf .imh:
imutil> imheader mosaic_fixed2.psf.imh longheader=yes
mosaic_fixed2.psf.imh[0][real]:
No bad pixels, min=unknown, max=unknown
Line storage mode, physdim [0], length of user area 1 s.u.
Created Wed 18:34:03 15-Aug-2007, Last modified Wed 18:34:03 15-Aug-2007
Pixel file "" [NO PIXEL FILE]Mike Fitzpatrick wrote on Jul 10, 2007
That says you've got no header keywords, the image dimension is zero, and there is no pixel file specified.
What was the command that created the image? Is it an IRAF task or something locally written?
-Mike
What was the command that created the image? Is it an IRAF task or something locally written?
-Mike
dvodonnell wrote on Jul 10, 2007
The main image was originally a .fits file, converted to imh/pix using imcopy,
>imcopy mosaic.fits mosaic.imh
That successfully created the original .imh and .pix, both of which seem valid.
As for the PSF image, I'm simply using the psf command to generate that as output, which yields only that .imh file with the seemingly bad header.
>imcopy mosaic.fits mosaic.imh
That successfully created the original .imh and .pix, both of which seem valid.
As for the PSF image, I'm simply using the psf command to generate that as output, which yields only that .imh file with the seemingly bad header.
Mike Fitzpatrick wrote on Jul 10, 2007
So what happens if you create it from the original mosaic.fits image? Is imtype still set to FITS? What are the parameters to the PSF task you used.
I'm thinking having a mosaic.fits and mosaic.imh in the same directory may be confusing things, Using imh isn't required but if you want to do it try using a different name so the images are unique.
-Mike
I'm thinking having a mosaic.fits and mosaic.imh in the same directory may be confusing things, Using imh isn't required but if you want to do it try using a different name so the images are unique.
-Mike
dvodonnell wrote on Jul 10, 2007
I've (a) tried removing the .fits from the directory, and (b) just using the .fits off the bat for the psf input. They both yield the same result. Hope it's not over-kill, but here's my whole psf process. The .mag and .pst files I'm using seem fine, so I don't think they're the issue.
Mike Fitzpatrick wrote on Jul 10, 2007
I'm about at the end of what I know about DAOPHOT. The second output of PSF looks normal but what's up with the 'cannot open image' message in the first call? Did you do something to fix it in another window or just run the task twice? Does putting the .fits extension on the output psf image name likewise create an empty image with no keywords? What about setting the 'imtype' to be 'fits'?
-Mike
-Mike
dvodonnell wrote on Jul 10, 2007
I've got our sysadmin to through iraf on another machine, and things seem to be working now. There must be some kind of conflict in the configuration on my machine hidden somewhere. Sorry to whoever is reading this post in the future for help -- not the triumphant ending you were looking for.
Just wanted to say thanks for all your help though, much appreciated!
Just wanted to say thanks for all your help though, much appreciated!
Guest wrote on Dec 04, 2013
If the error is due to long path, you can use Long Path Tool, it handles such issues..
Last post on Dec 04, 2013