C-WAYS Resolution Worksheet - Revision history

Rebull: /* Exploring POSS images */

2012-03-27T16:51:33Z

Exploring POSS images

Rebull at 22:38, 23 March 2012

2012-03-23T22:38:34Z

Rebull: /* Exploring POSS images */

2012-03-22T02:53:06Z

Exploring POSS images

Rebull at 02:29, 22 March 2012

2012-03-22T02:29:55Z

Rebull: /* Moving into the IR */

2012-03-21T16:17:11Z

Moving into the IR

Rebull at 03:11, 21 March 2012

2012-03-21T03:11:57Z

Rebull: /* Postscript: Slight improvements are sometimes possible */

2012-03-20T21:54:39Z

Postscript: Slight improvements are sometimes possible

Rebull: /* Skyview basics and other things to note */

2012-03-20T20:34:22Z

Skyview basics and other things to note

Rebull: /* Postscript: Slight improvements are sometimes possible */

2012-03-20T17:34:55Z

Postscript: Slight improvements are sometimes possible

Rebull: /* Postscript: Slight improvements are sometimes possible */

2012-03-20T17:34:01Z

Postscript: Slight improvements are sometimes possible

@@ Line 63: / Line 63: @@
 OK, returning to my question above - What size are the individual pixels in the image as returned to you, and what size are the pixels you can see in the image itself by eye? Skyview did exactly what you asked it to do, and gave you an image 300 pixels across. What is the native resolution of the DSS image (e.g., what is the size of the pixels you can see, vs the pixels you asked it for [xx degrees over yy pixels])?
-The original POSS spatial resolution was set by the seeing at Palomar that night, plus the size of the silver grains. When it got scanned, during the digitization process, the resolution becomes more or less the size of the pixels you see there. (That's why they look so irregular in the image.)
+The original POSS spatial resolution was set by the seeing at Palomar that night, plus the size of the silver grains. When it got scanned, during the digitization process, the resolution becomes more or less the size of the pixels you see there. (That's one reason why they look so irregular in the image; the other reason is the resampling that we are exploring here. Compare this image to what you get in Q1.6 for a vivid demonstration of what is going on.)
 '''Q1.5 :''' Now, let's be careful. Normally, to 'believe' a detection of anything, astronomers require that it be seen in more than 1 pixel. If something is seen in just 1 pixel, it's hard to tell if it's a single hot pixel, or a cosmic ray, or a real detection. Thus, spatial resolution, if cited without a "per pixel", is most frequently quoted as certainly more than 1 pixel, often approaching 2 pixels. What this physically means, in essence, is BOTH the following two questions: (1) "How many pixels have to be affected before I believe it is a real detection?" and (2) "How close do two sources have to be before I can no longer distinguish them as two individual sources?"  (Real life numbers: the quoted resolution of IRAC is ~2 arcsec, but the native pixel size is 1.2 arcsec, and standard mosaics have the pixels resampled to be 0.6 arcsec.) The quoted resolution of the DSS is 1.7 arcsec per pixel (or about 2 arcsec, depending on the photographic plate). How does this match with what you calculated above?

@@ Line 54: / Line 54: @@
 '''Q1.3 :''' Go back to Skyview and ask for a smaller image, 1 degree on a side, also with the default 300 px. How big are those pixels in arcseconds/arcminutes/degrees?
-'''Q1.4 :''' Go back to Skyview and ask for a much smaller image, 0.1 degree, still with the default 300 px. How big are those pixels -- what do I mean by pixels? What size are the individual pixels in the image as returned to you, and what size are the pixels you can see in the image itself by eye?  You will need to zoom in, probably a lot, and you will need to estimate an average size of the irregular pixels. You will need to find a way to measure distances on images, and unfortunately, ds9 doesn't provide a really easy way to do this.(*) As our first but certainly not last example of "astronomers using whatever software you are most familiar with to do the job", you are more than welcome to use your own favorite FITS viewer (if yours has an easy way to do this). Otherwise, you will have to do this by hand. Note that as you move your mouse around on the image in ds9, it will give you an updated readout of the ra and dec in the top. You can change this from hh:mm:ss ddd:mm:ss format to decimal degrees for both ra and dec by picking from the "wcs" menu at the top, either 'degrees' or 'sexagesimal'. Make a note of the RA/Dec of the corners of an example pixel and calculate the distance along the sides of a pixel as you see it in the image (as opposed to that in the FITS header). (Yes, the pixels will be irregular; see if you can find an average pixel in the image.)
+'''Q1.4 :''' Go back to Skyview and ask for a much smaller image, 0.1 degree, still with the default 300 px. How big are those pixels -- what do I mean by pixels? What size are the individual pixels in the image as returned to you, and what size are the pixels you can see in the image itself by eye?  You will need to zoom in, probably a lot, and you will need to estimate an average size of the irregular pixels. You will need to find a way to measure distances on images, and unfortunately, ds9 doesn't provide a really easy way to do this.(*) As our first but certainly not last example of "astronomers using whatever software you are most familiar with to do the job", you are more than welcome to use your own favorite FITS viewer (if yours has an easy way to do this). Otherwise, you will have to do this by hand. Note that as you move your mouse around on the image in ds9, it will give you an updated readout of the ra and dec in the top. You can change this from hh:mm:ss ddd:mm:ss format to decimal degrees for both ra and dec by picking from the "wcs" menu at the top, either 'degrees' or 'sexagesimal'. Make a note of the RA/Dec of the corners of an example pixel and calculate the distance along the sides of a pixel as you see it in the image (as opposed to that in the FITS header). (Yes, the pixels will be irregular; see if you can find an average pixel in the image.) WATCH YOUR UNITS. RA by default is in hours, not degrees. Dec by default IS in degrees.
-Technically, to be absolutely correct, because you are calculating distances on a sphere, in order to do this, you need to do spherical trigonometry. This matters because the angle subtended by 1 hour of RA on the celestial equator is much larger than that subtended by 1 hour of RA near the celestial pole. However, over these relatively small distances, it should be mostly fine to simply subtract the ra and dec to get a reasonable estimate of the size of the pixels. It does make a difference, though. See [http://spiff.rit.edu/classes/phys301/lectures/precession/precession.html#sep this excerpt from someone's class notes] with some really nice graphics and explanations of why you need to do this, and how to do it right. (hint: For the distances we'll consider here, you need a cosine of the declination. I won't make you do the full spherical trig for distances more than a degree.) For the ambitious, anticipating skills you'll need downstream from this worksheet, try programming a spreadsheet to do this for you, given two ra,dec position pairs. '''NB: Be sure to watch your units on the Dec-- some cosine functions want radians, and some take degrees.'''  (Bonus: how much of a difference does it make if you leave out the cos(dec) term? How much does the cos(dec) term matter for one of the other BRCs?)
+Technically, to be absolutely correct, because you are calculating distances on a sphere, in order to do this, you need to do spherical trigonometry. This matters because the angle subtended by 1 hour of RA on the celestial equator is much larger than that subtended by 1 hour of RA near the celestial pole. However, over these relatively small distances, it should be mostly fine to simply subtract the RA and Dec to get a reasonable estimate of the size of the pixels BUT WATCH YOUR UNITS because RA by default is in hours:min of time:sec of time, not deg:arcmin:arcsec. It does make a difference, though. See [http://spiff.rit.edu/classes/phys301/lectures/precession/precession.html#sep this excerpt from someone's class notes] with some really nice graphics and explanations of why you need to do this, and how to do it right. (hint: For the distances we'll consider here, you need a cosine of the declination. I won't make you do the full spherical trig for distances more than a degree.) For the ambitious, anticipating skills you'll need downstream from this worksheet, try programming a spreadsheet to do this for you, given two RA,Dec position pairs. '''NB: Be sure to watch your units on the Dec-- some cosine functions want radians, and some take degrees.'''  (Bonus: how much of a difference does it make if you leave out the cos(dec) term? How much does the cos(dec) term matter for one of the other BRCs?)
 (*) ds9 can calculate distances, just in a clunky way. Select Region, Shape, select Ruler. Click on one end of what you want to measure, then move to the other end and click again.  A line with arrows will be drawn connecting the two, along with the distance in text and dotted lines completing the triangle.  By default, the distance will be in physical units, but by accessing the region's Get Information panel, you can change both the endpoints and (more usefully) distance to WCS.

@@ Line 65: / Line 65: @@
 The original POSS spatial resolution was set by the seeing at Palomar that night, plus the size of the silver grains. When it got scanned, during the digitization process, the resolution becomes more or less the size of the pixels you see there. (That's why they look so irregular in the image.)
-'''Q1.5 :''' Now, let's be careful. Normally, to 'believe' a detection of anything, astronomers require that it be seen in more than 1 pixel. If something is seen in just 1 pixel, it's hard to tell if it's a single hot pixel, or a cosmic ray, or a real detection. Thus, spatial resolution, if cited without a "per pixel", is most frequently quoted as certainly more than 1 pixel, often approaching 2 pixels. What this physically means, in essence, is BOTH the following two questions: (1) "How many pixels have to be affected before I believe it is a real detection?" and (2) "How close do two sources have to be before I can no longer distinguish them as two individual sources?"  (Real life numbers: the quoted resolution of IRAC is ~2 arcsec, but the native pixel size is 1.2 arcsec, and standard mosaics have the pixels resampled to be 0.6 arcsec.) The quoted resolution of the DSS is 1.7 arcsec per pixel. How does this match with what you calculated above?
+'''Q1.5 :''' Now, let's be careful. Normally, to 'believe' a detection of anything, astronomers require that it be seen in more than 1 pixel. If something is seen in just 1 pixel, it's hard to tell if it's a single hot pixel, or a cosmic ray, or a real detection. Thus, spatial resolution, if cited without a "per pixel", is most frequently quoted as certainly more than 1 pixel, often approaching 2 pixels. What this physically means, in essence, is BOTH the following two questions: (1) "How many pixels have to be affected before I believe it is a real detection?" and (2) "How close do two sources have to be before I can no longer distinguish them as two individual sources?"  (Real life numbers: the quoted resolution of IRAC is ~2 arcsec, but the native pixel size is 1.2 arcsec, and standard mosaics have the pixels resampled to be 0.6 arcsec.) The quoted resolution of the DSS is 1.7 arcsec per pixel (or about 2 arcsec, depending on the photographic plate). How does this match with what you calculated above?
 '''Q1.6 :''' What happens if you ask it for a 300 px image without an image size specified (again for that same position, DSS). How big is that image you get in degrees? How many arcsec/arcmin/degrees per pixel do you get?

@@ Line 54: / Line 54: @@
 '''Q1.3 :''' Go back to Skyview and ask for a smaller image, 1 degree on a side, also with the default 300 px. How big are those pixels in arcseconds/arcminutes/degrees?
-'''Q1.4 :''' Go back to Skyview and ask for a much smaller image, 0.1 degree, still with the default 300 px. How big are those pixels -- what do I mean by pixels? What size are the individual pixels in the image as returned to you, and what size are the pixels you can see in the image itself by eye?  You will need to zoom in, probably a lot, and you will need to estimate an average size of the irregular pixels. You will need to find a way to measure distances on images, and unfortunately, ds9 doesn't provide an easy way to do this. As our first but certainly not last example of "astronomers using whatever software you are most familiar with to do the job", you are more than welcome to use your own favorite FITS viewer (if yours has an easy way to do this). Otherwise, you will have to do this by hand. Note that as you move your mouse around on the image in ds9, it will give you an updated readout of the ra and dec in the top. You can change this from hh:mm:ss ddd:mm:ss format to decimal degrees for both ra and dec by picking from the "wcs" menu at the top, either 'degrees' or 'sexagesimal'. Make a note of the RA/Dec of the corners of an example pixel and calculate the distance along the sides of a pixel as you see it in the image (as opposed to that in the FITS header). (Yes, the pixels will be irregular; see if you can find an average pixel in the image.)
+'''Q1.4 :''' Go back to Skyview and ask for a much smaller image, 0.1 degree, still with the default 300 px. How big are those pixels -- what do I mean by pixels? What size are the individual pixels in the image as returned to you, and what size are the pixels you can see in the image itself by eye?  You will need to zoom in, probably a lot, and you will need to estimate an average size of the irregular pixels. You will need to find a way to measure distances on images, and unfortunately, ds9 doesn't provide a really easy way to do this.(*) As our first but certainly not last example of "astronomers using whatever software you are most familiar with to do the job", you are more than welcome to use your own favorite FITS viewer (if yours has an easy way to do this). Otherwise, you will have to do this by hand. Note that as you move your mouse around on the image in ds9, it will give you an updated readout of the ra and dec in the top. You can change this from hh:mm:ss ddd:mm:ss format to decimal degrees for both ra and dec by picking from the "wcs" menu at the top, either 'degrees' or 'sexagesimal'. Make a note of the RA/Dec of the corners of an example pixel and calculate the distance along the sides of a pixel as you see it in the image (as opposed to that in the FITS header). (Yes, the pixels will be irregular; see if you can find an average pixel in the image.)
 Technically, to be absolutely correct, because you are calculating distances on a sphere, in order to do this, you need to do spherical trigonometry. This matters because the angle subtended by 1 hour of RA on the celestial equator is much larger than that subtended by 1 hour of RA near the celestial pole. However, over these relatively small distances, it should be mostly fine to simply subtract the ra and dec to get a reasonable estimate of the size of the pixels. It does make a difference, though. See [http://spiff.rit.edu/classes/phys301/lectures/precession/precession.html#sep this excerpt from someone's class notes] with some really nice graphics and explanations of why you need to do this, and how to do it right. (hint: For the distances we'll consider here, you need a cosine of the declination. I won't make you do the full spherical trig for distances more than a degree.) For the ambitious, anticipating skills you'll need downstream from this worksheet, try programming a spreadsheet to do this for you, given two ra,dec position pairs. '''NB: Be sure to watch your units on the Dec-- some cosine functions want radians, and some take degrees.'''  (Bonus: how much of a difference does it make if you leave out the cos(dec) term? How much does the cos(dec) term matter for one of the other BRCs?)
 OK, returning to my question above - What size are the individual pixels in the image as returned to you, and what size are the pixels you can see in the image itself by eye? Skyview did exactly what you asked it to do, and gave you an image 300 pixels across. What is the native resolution of the DSS image (e.g., what is the size of the pixels you can see, vs the pixels you asked it for [xx degrees over yy pixels])?

← Older revision		Revision as of 16:17, 21 March 2012
Line 94:		Line 94:

	'''Q2.7 :''' Pick another wavelength from Skyview to explore. You may wish to use [[Finding cluster members]] to aid in your selection of another good wavelength, but you don't have to. Not everything will be available at every location, since some are just galactic plane surveys (e.g., MSX), or only not galactic plane (e.g., GALEX), or only one hemisphere, etc. What did you pick? What is the native resolution of that survey? and a big question: Will that band be helpful to us in finding young stars in the region you are investigating?		'''Q2.7 :''' Pick another wavelength from Skyview to explore. You may wish to use [[Finding cluster members]] to aid in your selection of another good wavelength, but you don't have to. Not everything will be available at every location, since some are just galactic plane surveys (e.g., MSX), or only not galactic plane (e.g., GALEX), or only one hemisphere, etc. What did you pick? What is the native resolution of that survey? and a big question: Will that band be helpful to us in finding young stars in the region you are investigating?
		+
		+	'''Q2.8 : (added late!)''' So, knowing what you do now, why is it that IRAS sources are given as, e.g., "IRAS 21391+5802" and 2MASS sources are given as, e.g., "2MASS 21402612+5814243" ?

	=Finder Chart IRSA tool=		=Finder Chart IRSA tool=

@@ Line 115: / Line 115: @@
 However.
-I have swept some things under the rug. IRAS data was so interesting, and it was going to be so long before astronomers got any more data in those wavelengths on that scale, that very clever people got to work on how to get even more information out of IRAS data. Imagine those big IRAS pixels scanning over a patch of warm sky. The next time the spacecraft scans that same patch of sky, the pixels are offset a little bit from where it was on the last pass, and consequently the fluxes it measures are just a little different. Same for the next scan, and the next. If you have lots of scans over the same region, you can recover a little bit of the information on a slightly higher (better) spatial resolution.  [http://irsa.ipac.caltech.edu/IRASdocs/hires_over.html This page] has some general information on the specific application of this method to IRAS, called "Hi-Res", along with example pictures. It uses the Maximum Correlation Method (MCM; [http://adsabs.harvard.edu/abs/1990AJ.....99.1674A H.H. Aumann, J.W. Fowler and M. Melnyk, 1990, AJ, 99, 1674]). It is computationally expensive (meaning it takes a while to run), and requires lots of individual tweaking and customization, so it has not been run (blindly) over the whole sky. The degree of improvement is related to the number of scans; as for WISE, the number of passes is a function of the ecliptic latitude, so just running Hi-Res doesn't get you a specific improved resolution.  Hi-Res got famous in the context of IRAS.  People are developing ways to [http://arxiv.org/abs/0812.4310 run this kind of algorithm on WISE] and even Spitzer data, but we're not going to try and use it, as there are no particularly user-friendly interfaces to it (at least at the level we would need).
+I have swept some things under the rug. IRAS data was so interesting, and it was going to be so long before astronomers got any more data in those wavelengths on that scale, that very clever people got to work on how to get even more information out of IRAS data. Imagine those big IRAS pixels scanning over a patch of warm sky. The next time the spacecraft scans that same patch of sky, the pixels are offset a little bit from where it was on the last pass, and consequently the fluxes it measures are just a little different. Same for the next scan, and the next. If you have lots of scans over the same region, you can recover a little bit of the information on a slightly higher (better) spatial resolution.  [http://irsa.ipac.caltech.edu/IRASdocs/hires_over.html This page] has some general information on the specific application of this method to IRAS, called "Hi-Res", along with example pictures. It uses the Maximum Correlation Method (MCM; [http://adsabs.harvard.edu/abs/1990AJ.....99.1674A H.H. Aumann, J.W. Fowler and M. Melnyk, 1990, AJ, 99, 1674]). It is computationally expensive (meaning it takes a while to run), and requires lots of individual tweaking and customization, so it has not been run (blindly) over the whole sky. The degree of improvement is related to the number of scans; as for WISE, the number of passes is a function of the ecliptic latitude, so just running Hi-Res doesn't get you a specific improved resolution.  Hi-Res got famous in the context of IRAS.  People are developing ways to [http://arxiv.org/abs/0812.4310 run this kind of algorithm on WISE] and even Spitzer data, but we're not going to try and use it, as there are no particularly user-friendly interfaces to it (at least at the level we would need), and the incremental benefit we'd gain from this probably outweighs the work it would take to get there.
 In the context of our project, we won't need to care about any of this, but I thought I should be complete in case anyone cares! :)

← Older revision		Revision as of 20:34, 20 March 2012
Line 39:		Line 39:

	One last word of advice. When you go to download the FITS file (from Skyview, or, for that matter, from any of a number of other servers), the default filename is related to the process id on the server, e.g., it won't mean anything to you 10 minutes after you download it. In the process of doing these exercises, you should rename the images straightaway to be something that you can understand later on.		One last word of advice. When you go to download the FITS file (from Skyview, or, for that matter, from any of a number of other servers), the default filename is related to the process id on the server, e.g., it won't mean anything to you 10 minutes after you download it. In the process of doing these exercises, you should rename the images straightaway to be something that you can understand later on.
		+
		+	ds9 Tutorials from Babar:
		+	*[http://youtu.be/c5YmJp_rgtI Video 1: How to load and view and image in ds9]
		+	*[http://youtu.be/gQIhh6u7L8s Video 2: How to read information about your image in the information panel of ds9]

	=Exploring POSS images=		=Exploring POSS images=

@@ Line 111: / Line 111: @@
 However.
-I have swept some things under the rug. IRAS data was so interesting, and it was going to be so long before astronomers got any more data in those wavelengths on that scale, that very clever people got to work on how to get even more information out of IRAS data. Imagine those big IRAS pixels scanning over a patch of warm sky. The next time the spacecraft scans that same patch of sky, the pixels are offset a little bit from where it was on the last pass, and consequently the fluxes it measures are just a little different. Same for the next scan, and the next. If you have lots of scans over the same region, you can recover a little bit of the information on a slightly higher (better) spatial resolution.  [http://irsa.ipac.caltech.edu/IRASdocs/hires_over.html This page] has some general information on the specific application of this method to IRAS, called "Hi-Res", along with example pictures. It uses the Maximum Correlation Method (MCM; H.H. Aumann, J.W. Fowler and M. Melnyk, 1990, AJ, 99, 1674). It is computationally expensive (meaning it takes a while to run), and requires lots of individual tweaking and customization, so it has not been run (blindly) over the whole sky. The degree of improvement is related to the number of scans; as for WISE, the number of passes is a function of the ecliptic latitude, so just running Hi-Res doesn't get you a specific improved resolution.  Hi-Res got famous in the context of IRAS.  People are developing ways to [http://arxiv.org/abs/0812.4310 run this kind of algorithm on WISE] and even Spitzer data, but there are no particularly user-friendly interfaces to it.
+I have swept some things under the rug. IRAS data was so interesting, and it was going to be so long before astronomers got any more data in those wavelengths on that scale, that very clever people got to work on how to get even more information out of IRAS data. Imagine those big IRAS pixels scanning over a patch of warm sky. The next time the spacecraft scans that same patch of sky, the pixels are offset a little bit from where it was on the last pass, and consequently the fluxes it measures are just a little different. Same for the next scan, and the next. If you have lots of scans over the same region, you can recover a little bit of the information on a slightly higher (better) spatial resolution.  [http://irsa.ipac.caltech.edu/IRASdocs/hires_over.html This page] has some general information on the specific application of this method to IRAS, called "Hi-Res", along with example pictures. It uses the Maximum Correlation Method (MCM; H.H. Aumann, J.W. Fowler and M. Melnyk, 1990, AJ, 99, 1674). It is computationally expensive (meaning it takes a while to run), and requires lots of individual tweaking and customization, so it has not been run (blindly) over the whole sky. The degree of improvement is related to the number of scans; as for WISE, the number of passes is a function of the ecliptic latitude, so just running Hi-Res doesn't get you a specific improved resolution.  Hi-Res got famous in the context of IRAS.  People are developing ways to [http://arxiv.org/abs/0812.4310 run this kind of algorithm on WISE] and even Spitzer data, but we're not going to try and use it, as there are no particularly user-friendly interfaces to it (at least at the level we would need).
 In the context of our project, we won't need to care about any of this, but I thought I should be complete in case anyone cares! :)