Welcome to iraf.net Thursday, September 21 2017 @ 12:26 PM GMT


 Forum Index > Help Desk > General IRAF New Topic Post Reply
 Problem with DAOPhot
   
craigswenson
 07/10/2007 10:13PM (Read 16801 times)  
++---
Junior

Status: offline


Registered: 07/10/2007
Posts: 23
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.

 
Profile Email
 Quote
fitz
 07/10/2007 10:13PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3967
From an earlier reply to a similar problem:[quote:305d664454]
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).
[/quote:305d664454]Write back if you still have problems.-Mike

 
Profile Email
 Quote
craigswenson
 07/10/2007 10:13PM  
++---
Junior

Status: offline


Registered: 07/10/2007
Posts: 23
Setting update to yes fixed my problem. Thank you very much.

 
Profile Email
 Quote
dvodonnell
 07/10/2007 10:13PM  
+----
Newbie

Status: offline


Registered: 08/15/2007
Posts: 12
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.;.

 
Profile Email
 Quote
fitz
 07/10/2007 10:13PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3967
If you mean the long IMHEADER output contains a line such as:[code:1:0c62c9a8a0] Pixel file "/tmp/foo.pix" [NO PIXEL FILE][/code:1:0c62c9a8a0]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

 
Profile Email
 Quote
dvodonnell
 07/10/2007 10:13PM  
+----
Newbie

Status: offline


Registered: 08/15/2007
Posts: 12
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!

 
Profile Email
 Quote
dvodonnell
 07/10/2007 10:13PM  
+----
Newbie

Status: offline


Registered: 08/15/2007
Posts: 12
update -- imh is seeing the pix nowstill getting the Function error however

 
Profile Email
 Quote
fitz
 07/10/2007 10:13PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3967
[quote:39268003c8]I have both image.imh and image.pix in the directory, shouldn't it automatically detect it there? [/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.[/quote:39268003c8]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]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

 
Profile Email
 Quote
dvodonnell
 07/10/2007 10:13PM  
+----
Newbie

Status: offline


Registered: 08/15/2007
Posts: 12
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.

 
Profile Email
 Quote
fitz
 07/10/2007 10:13PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3967
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[code:1:b31893c3d7]
cl> reset imdir = HDR$
cl> flpr 0 # zero not oh
[/code:1:b31893c3d7]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

 
Profile Email
 Quote
dvodonnell
 07/10/2007 10:13PM  
+----
Newbie

Status: offline


Registered: 08/15/2007
Posts: 12
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...

 
Profile Email
 Quote
fitz
 07/10/2007 10:13PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3967
Try a simple test first like[code:1:15723c41ab]cl> imcopy dev$pix foo[/code:1:15723c41ab]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

 
Profile Email
 Quote
dvodonnell
 07/10/2007 10:13PM  
+----
Newbie

Status: offline


Registered: 08/15/2007
Posts: 12
The test works fine -- imcopy gives me both a .imh and .pix.
I have been specifying image.imh (including the extension) at the prompts.

 
Profile Email
 Quote
dvodonnell
 07/10/2007 10:13PM  
+----
Newbie

Status: offline


Registered: 08/15/2007
Posts: 12
...and if I remove the .imh extension, it reports an ambiguous image name, even though imtype is indeed set to imh.

 
Profile Email
 Quote
fitz
 07/10/2007 10:13PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3967
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

 
Profile Email
 Quote
dvodonnell
 07/10/2007 10:13PM  
+----
Newbie

Status: offline


Registered: 08/15/2007
Posts: 12
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....

 
Profile Email
 Quote
fitz
 07/10/2007 10:13PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3967
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

 
Profile Email
 Quote
dvodonnell
 07/10/2007 10:13PM  
+----
Newbie

Status: offline


Registered: 08/15/2007
Posts: 12
Here's my imheader output on my psf .imh:[code:1:822284cc91]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][/code:1:822284cc91]

 
Profile Email
 Quote
fitz
 07/10/2007 10:13PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3967
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

 
Profile Email
 Quote
dvodonnell
 07/10/2007 10:13PM  
+----
Newbie

Status: offline


Registered: 08/15/2007
Posts: 12
The main image was originally a .fits file, converted to imh/pix using imcopy,>imcopy mosaic.fits mosaic.imhThat 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.

 
Profile Email
 Quote
fitz
 07/10/2007 10:13PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3967
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

 
Profile Email
 Quote
dvodonnell
 07/10/2007 10:13PM  
+----
Newbie

Status: offline


Registered: 08/15/2007
Posts: 12
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.

 
Profile Email
 Quote
fitz
 07/10/2007 10:13PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3967
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

 
Profile Email
 Quote
dvodonnell
 07/10/2007 10:13PM  
+----
Newbie

Status: offline


Registered: 08/15/2007
Posts: 12
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!

 
Profile Email
 Quote
Anonymous: aliceten
 12/04/2013 10:01AM  



If the error is due to long path, you can use Long Path Tool, it handles such issues..

 
 Quote
   
Content generated in: 0.65 seconds
New Topic Post Reply

Normal Topic Normal Topic
Sticky Topic Sticky Topic
Locked Topic Locked Topic
New Post New Post
Sticky Topic W/ New Post Sticky Topic W/ New Post
Locked Topic W/ New Post Locked Topic W/ New Post
View Anonymous Posts 
Anonymous users can post 
Filtered HTML Allowed 
Censored Content 
dog allergies remedies cialis 20 mg chilblain remedies


Privacy Policy
Terms of Use

User Functions

Login