mkobjects - simulated objects are not as expected (FWHM)
ira_peblo wrote on Mar 18, 2010
Dear IRAF,
it is already a month I am playing around with IRAF.mkobjects to simulate Globular Clusters (GCs) on a HST mosaic, but I am really concerned about the reliability of the output.
Most of all, I realized that the simulated objects systematically have a different FWHM than the input one.
Since I generate the King profile image to be convolved with the PSF, I do not actually know the input FWHM.
In fact, I can play on the King profile acting on the core radius and concentration parameter rather than on the FWHM.
Therefore, to test mkobjects, I had to fool it in this way:
> I generate a median GC template from a sample of real GC candidates cropped from the mosaic (the GC template is therefore already PSF convolved)
> This GC template is passed to IRAF.mkobjects as if it was a PSF. Asking IRAF.mkobjects to generate stellar sources will actually result into simulating GCs
The issue is that the simulated GCs have a systematically higher FWHM than the real GCs in the mosaic (about 0.4 on a FWHM of 2 pixels)!!!!!!!!!!!!
:shock: That means that just asking mkobjects to put some objects on the image, will broaden these same objects!!!!:shock:
Where am I wrong?!
Many thanks,
Paolo Bonfini
PLEASE CONTACT ME IF YOU TRIED SOMETHING SIMILAR (or if you think I may be useful to you)!!
it is already a month I am playing around with IRAF.mkobjects to simulate Globular Clusters (GCs) on a HST mosaic, but I am really concerned about the reliability of the output.
Most of all, I realized that the simulated objects systematically have a different FWHM than the input one.
Since I generate the King profile image to be convolved with the PSF, I do not actually know the input FWHM.
In fact, I can play on the King profile acting on the core radius and concentration parameter rather than on the FWHM.
Therefore, to test mkobjects, I had to fool it in this way:
> I generate a median GC template from a sample of real GC candidates cropped from the mosaic (the GC template is therefore already PSF convolved)
> This GC template is passed to IRAF.mkobjects as if it was a PSF. Asking IRAF.mkobjects to generate stellar sources will actually result into simulating GCs
The issue is that the simulated GCs have a systematically higher FWHM than the real GCs in the mosaic (about 0.4 on a FWHM of 2 pixels)!!!!!!!!!!!!
:shock: That means that just asking mkobjects to put some objects on the image, will broaden these same objects!!!!:shock:
Where am I wrong?!
Many thanks,
Paolo Bonfini
PLEASE CONTACT ME IF YOU TRIED SOMETHING SIMILAR (or if you think I may be useful to you)!!
Francisco Valdes wrote on Mar 18, 2010
Hello Paolo,
It was not totally clear about simulating globular clusters. I am guessing you are taking about distant, unresolved clusters, and not the stars in a nearby cluster. So in that case you want to have a profile that is one you supply and then convert it into a distant GC that is almost unresolved?
It is difficult to understand what the problem you see might be due to. First you should start with a profile function that is well resolved. Then this is turned into a simulated observation. Unless you turn off the PSF step any simulation will be convolved by a PSF which will broaden the profile. If the profile/distance/size you set is nearly unresolved then it will certainly be broader than shape in the absence of seeing.
My only other comment is that when you get down to the sampling limit, and a FWHM of 2 pixels seems to be that, then it is a challenge a) to have a good simulations and b) to then measure the result (such as with IMEXAM).
What I would do first is make a simulation that is clearly resolved; i.e. act as if you are much closer or the image has very high sampling (say 0.01 arcsec/pix) and don't use a seeing convolution. Check if this makes sense. You can then block average down to a your arcsec/pix scale and see what happens so that you know that it is not something about mkobjects and the parameters.
Similiarly, you could do things without any seeing and see if the effect your are seeing is related to that.
I hope this helps,
Frank Valdes
It was not totally clear about simulating globular clusters. I am guessing you are taking about distant, unresolved clusters, and not the stars in a nearby cluster. So in that case you want to have a profile that is one you supply and then convert it into a distant GC that is almost unresolved?
It is difficult to understand what the problem you see might be due to. First you should start with a profile function that is well resolved. Then this is turned into a simulated observation. Unless you turn off the PSF step any simulation will be convolved by a PSF which will broaden the profile. If the profile/distance/size you set is nearly unresolved then it will certainly be broader than shape in the absence of seeing.
My only other comment is that when you get down to the sampling limit, and a FWHM of 2 pixels seems to be that, then it is a challenge a) to have a good simulations and b) to then measure the result (such as with IMEXAM).
What I would do first is make a simulation that is clearly resolved; i.e. act as if you are much closer or the image has very high sampling (say 0.01 arcsec/pix) and don't use a seeing convolution. Check if this makes sense. You can then block average down to a your arcsec/pix scale and see what happens so that you know that it is not something about mkobjects and the parameters.
Similiarly, you could do things without any seeing and see if the effect your are seeing is related to that.
I hope this helps,
Frank Valdes
ira_peblo wrote on Mar 18, 2010
Dear Frank,
thanks for the quick reply. You understood my problem correctly. I am working on HST data with marginally sampled GCs.
I think I found my error, and your reply confirms my supects: to make things easy, in the beginning I set the model centre in the cross-section of the 4 central pixels of the image (hope you can understand me).
Doing this, I ended up with a core including AT LEAST 4 pixels! So obviously the FWHM would always be >> 2 pixels! What a stupid mistake! It wouldn't affect big objects but, as you say, when the FWHM goes down to 2 pixels that becomes important.
To correct this, I moved the model centre in the centre of the central pixel, and set the image size to an odd number.
Now the FWHM of the simulated objects are pretty consistent with the ones of the observed GCs!
What you say about sub-sampling is definitely right, but I think that with my new setup the subsampling performed by mkobjects (I refer to the default ngxsub and ngysub) is enough. At least it seems to work fine.
I generate the model I need directly in the pixel scale of the image on which I add them.
For example, if I assume a GC with core radius = 3pc, at the distance/scale I consider it appears as big as 0.2 pixels. Therefore, I generate a King profile image of, say, 20 pixels, with a core radius of 0.2 pixels. FWHM~2.
PS: I also tried to generate a King model doubling the sampling ( == doubling the core radius == doubling the scale), and passing half of the real image size in the relevant object file list. I think this is a quick-and-dirty way to let mkobjects do the dirty work and avoid re-sampling the final image, am I right?
PPS: How do I "switch off" the convolution with the PSF? (of course I do not involve any seeing, thanks to HST!). I do need the PSF, but I would like to try what happens without it!
Thank you very much,
Paolo Bonfini
thanks for the quick reply. You understood my problem correctly. I am working on HST data with marginally sampled GCs.
I think I found my error, and your reply confirms my supects: to make things easy, in the beginning I set the model centre in the cross-section of the 4 central pixels of the image (hope you can understand me).
Doing this, I ended up with a core including AT LEAST 4 pixels! So obviously the FWHM would always be >> 2 pixels! What a stupid mistake! It wouldn't affect big objects but, as you say, when the FWHM goes down to 2 pixels that becomes important.
To correct this, I moved the model centre in the centre of the central pixel, and set the image size to an odd number.
Now the FWHM of the simulated objects are pretty consistent with the ones of the observed GCs!
What you say about sub-sampling is definitely right, but I think that with my new setup the subsampling performed by mkobjects (I refer to the default ngxsub and ngysub) is enough. At least it seems to work fine.
I generate the model I need directly in the pixel scale of the image on which I add them.
For example, if I assume a GC with core radius = 3pc, at the distance/scale I consider it appears as big as 0.2 pixels. Therefore, I generate a King profile image of, say, 20 pixels, with a core radius of 0.2 pixels. FWHM~2.
PS: I also tried to generate a King model doubling the sampling ( == doubling the core radius == doubling the scale), and passing half of the real image size in the relevant object file list. I think this is a quick-and-dirty way to let mkobjects do the dirty work and avoid re-sampling the final image, am I right?
PPS: How do I "switch off" the convolution with the PSF? (of course I do not involve any seeing, thanks to HST!). I do need the PSF, but I would like to try what happens without it!
Thank you very much,
Paolo Bonfini
Francisco Valdes wrote on Mar 18, 2010
Dear Paolo,
I understand what you described. It sounds challenging. To turn off the PSF just set the mkobjects.radius parameter, which describes the PSF width, to zero or a small number.
You are correct that for profiles or explicit images as templates a size of 1 mean the size of the template. So if you have a profiled at x4 the final resolution you would use a size 0.25.
Good luck,
Frank
I understand what you described. It sounds challenging. To turn off the PSF just set the mkobjects.radius parameter, which describes the PSF width, to zero or a small number.
You are correct that for profiles or explicit images as templates a size of 1 mean the size of the template. So if you have a profiled at x4 the final resolution you would use a size 0.25.
Good luck,
Frank
Last post on Mar 18, 2010