Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Too long with UKIRT images
04-09-2008, 14:16
Post: #1
Too long with UKIRT images
Hi all...

I'm running SWARP with my UKIRT-WFCAM images (8 stacks of 4 images each 4048x4048pix), the ZPN problem is not there anymore, as discussed in other tread, but it seams the mosaicing is more time consuming than prevented. I'm running single tread without weighting images in a PC mandriva linux machine (3Ghz and 4Gbyte Memory). It looks like it will take 2 hours just to resample the first extention...

valentinuzzi rawdir> swarp @lista.lis
----- SWarp 2.17.1 started on 2008-04-09 at 15:07:24 with 1 thread

------- Output File coadd.fits:
"no ident" WEIGHTED no ext. header 33793x33631 32 bits (floats)
Center: 160,-8.69 0.946x0.941 Scale: 2.798e-05x2.799e-05 /pixel
Gain: 0 e-/ADU Flux scaling (astrom/photom): 1 X / 1 X
-------------- File w20050502_00166_sf_out.fit:
Extension #1: "no ident" unweighted no ext. header 4166x4167 32 bits (integers)
Center: 160,-9.02 0.00091x0.000915 Scale: 2.185e-07x2.196e-07 /pixel
Gain: 4.5 e-/ADU Flux scaling (astrom/photom): 1.632e+04 X / 1 X
Background: 2.609255e+07 RMS: 98111.38
^CResampling line: 1 / 8324

and also I'm not understanding why the log shows resampling line: 1/8324, if the total linea are 4048 ????

Maybe is just me not running properly...

Thanks for any help...
Find all posts by this user
Quote this message in a reply
04-09-2008, 15:42
Post: #2
RE: Too long with UKIRT images
valentinuzzi Wrote:------- Output File coadd.fits:
"no ident" WEIGHTED no ext. header 33793x33631 32 bits (floats)
Center: 160,-8.69 0.946x0.941 Scale: 2.798e-05x2.799e-05 /pixel
Gain: 0 e-/ADU Flux scaling (astrom/photom): 1 X / 1 X
-------------- File w20050502_00166_sf_out.fit:
Extension #1: "no ident" unweighted no ext. header 4166x4167 32 bits (integers)
Center: 160,-9.02 0.00091x0.000915 Scale: 2.185e-07x2.196e-07 /pixel
Gain: 4.5 e-/ADU Flux scaling (astrom/photom): 1.632e+04 X / 1 X
Background: 2.609255e+07 RMS: 98111.38

Are you sure you want to produce an image of size 33793x33631 pixels? What happens is, that SWarp tries to resample the pixel size of your data by a factor of 16000(!). If that is intented, I guess you just have to wait... Toungue

But if it is not indented, you have to find out, why SWarp thinks it has to resample your data by that huge factor. It could be a problem with the header of one or more involved files. I once had a problem trying to stack XMM-Newton images, where SWarp told me I would not have sufficient memory on my machine. I then figured out, I had to stack MOS1, MOS2 and PN for themselves - after that I was able to also coadd those three files. Not sure what happened, anyway. Cool

HTH, best regards Jan
Find all posts by this user
Quote this message in a reply
04-09-2008, 16:09
Post: #3
RE: Too long with UKIRT images
Jan Kohnert Wrote:Are you sure you want to produce an image of size 33793x33631 pixels? What happens is, that SWarp tries to resample the pixel size of your data by a factor of 16000(!). If that is intented, I guess you just have to wait... Toungue

But if it is not indented, you have to find out, why SWarp thinks it has to resample your data by that huge factor. It could be a problem with the header of one or more involved files. I once had a problem trying to stack XMM-Newton images, where SWarp told me I would not have sufficient memory on my machine. I then figured out, I had to stack MOS1, MOS2 and PN for themselves - after that I was able to also coadd those three files. Not sure what happened, anyway. Cool

HTH, best regards Jan

I'm not sure I've understood the point, you mean I've to chop my mosaics, and then coadd them?

Why SWARP wants to make a 32000x32000 image is unknown for me, in fact the result would be 16000x16000 pixel cohadded frame. UKIRT-WFCAM has 4 ccd at the corners, shifted pointings of one chip dimension let you cover a whole field consisting of 4x4 ccd area (1 ccd 4000 pix = total area 16000x16000 pix). So the resulting mosaic do have 16000x16000 pixels and not that side (maybe the fact that the images are double precision instead of real???). So I do not know the peculiarities of SWARP, and maybe I'm not placing the right config parameters... the fact is that it will take hours just to resample 1 CCD (#1 extention) of the first stacked image... do not know if that can be solved, anyway thank you very much... Tiziano.
Find all posts by this user
Quote this message in a reply
04-09-2008, 17:05
Post: #4
RE: Too long with UKIRT images
Well, something is obviously screwed up in your astrometric solution/header : look at the pixel scale reported by swarp (it should be something like 0.402: the one you have is much too small. You need to fix up your astrometric solution before you can resample... An an example, I've attached a typical SWARP output for a single WFCAM chip:


^[[1A-------------- File COSMOS.chip.101.fits:
"SW3" WEIGHTED EXT. HEADER 2196x2203 32 bits (floats)
Center: 10:00:31.36 +02:00:05.3 14.7'x14.8' Scale: 0.4022 ''/pixel
Gain: 1.03 e-/ADU Flux scaling (astrom/photom): 0.1391 X / 0.9618 X

cheers
henry
Visit this user's website Find all posts by this user
Quote this message in a reply
04-09-2008, 17:08
Post: #5
RE: Too long with UKIRT images
Hi Valentin,

valentinuzzi Wrote:I'm not sure I've understood the point, you mean I've to chop my mosaics, and then coadd them?

Well, yes, no. I just think, it might be a good idea not take all images into the list while testing. It is likely, that some image headers are broken and you have to find out which and where. But I don't think you will have to split your images, although I cannot completely rule out that.

valentinuzzi Wrote:Why SWARP wants to make a 32000x32000 image is unknown for me, in fact the result would be 16000x16000 pixel cohadded frame. UKIRT-WFCAM has 4 ccd at the corners, shifted pointings of one chip dimension let you cover a whole field consisting of 4x4 ccd area (1 ccd 4000 pix = total area 16000x16000 pix). So the resulting mosaic do have 16000x16000 pixels and not that side (maybe the fact that the images are double precision instead of real???).

So I guess you have one dithered pointing. Then there really is something evil is going on. In the section I quoted in my first post, SWarp tells you a lot of information. amongst others that it thinks your images are containing integer data instead of double. If you really are sure, your data is stored in double precession, you might want to check the images headers to contain the correct information.

But you also might have hit a bug. Can you try to give just one image to SWarp and the see what happens? If things still are broken then, it could help to put your configuration and at least one image onto the web or so, for people to debug this.

Best regards Jan
Find all posts by this user
Quote this message in a reply
04-09-2008, 17:25
Post: #6
RE: Too long with UKIRT images
Henry Joy McCracken Wrote:Well, something is obviously screwed up in your astrometric solution/header : look at the pixel scale reported by swarp (it should be something like 0.402: the one you have is much too small. You need to fix up your astrometric solution before you can resample... An an example, I've attached a typical SWARP output for a single WFCAM chip:


^[[1A-------------- File COSMOS.chip.101.fits:
"SW3" WEIGHTED EXT. HEADER 2196x2203 32 bits (floats)
Center: 10:00:31.36 +02:00:05.3 14.7'x14.8' Scale: 0.4022 ''/pixel
Gain: 1.03 e-/ADU Flux scaling (astrom/photom): 0.1391 X / 0.9618 X

cheers
henry

Yes, this might be the point... I tried to use only one image, but the problem is the same... it is misunderstanding the pixel scale... I'm using interleaved images, so that might be the problem, but maybe some header keyword, or maybe the stacking with primary header is a problem. With Montage software I didn't have any problem of this kind, but takes long time and not uses weigthing images... tomorrow I will try more tests, will update...
Find all posts by this user
Quote this message in a reply
04-10-2008, 09:00 (This post was last modified: 04-10-2008 13:40 by valentinuzzi.)
Post: #7
RE: Too long with UKIRT images
Henry Joy McCracken Wrote:Well, something is obviously screwed up in your astrometric solution/header :

Finally I've got it!!!!

The problem SWARP has with WFCAM-UKIRT images is related to the final reduced, interleaved stacked images coming from CASU. For images like that, already reduced, the following header keywords must be updated:

CTYPE1 from 'RA---ZPX' to 'RA---ZPN'
CTYPE2 from 'DEC--ZPX' to 'DEC--ZPN'

Then everything runs perfect!!! By the way I produced a Montage similar quality mosaic of one of my clusters in 45 minutes, instead of 180 with Montage, and finally I have also my weightimages.

Thank you for help, Tiziano.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)