IC 417 Resolution Worksheet - Revision history

Rebull: /* Pulling it all together */

2015-03-30T22:18:23Z

Pulling it all together

Rebull: /* Skyview */

2015-03-10T23:37:03Z

Skyview

Rebull: /* Postscript on the resolution issues: Slight improvements are sometimes possible */

2015-03-10T15:38:38Z

Postscript on the resolution issues: Slight improvements are sometimes possible

Rebull: /* Pulling it all together */

2015-03-10T15:37:14Z

Pulling it all together

Rebull: /* Next steps directly related to these skills and issues */

2015-03-10T15:35:59Z

Next steps directly related to these skills and issues

Rebull: /* Pulling it all together */

2015-03-10T15:35:29Z

Pulling it all together

Rebull: /* FinderChart: Obtaining images of our region, and resolution of various surveys */

2015-03-10T15:28:49Z

FinderChart: Obtaining images of our region, and resolution of various surveys

Rebull: /* Notes on Distances */

2015-03-10T15:28:09Z

Notes on Distances

Rebull: /* Notes on Distances */

2015-03-10T15:24:16Z

Notes on Distances

Rebull: /* Notes on Distances */

2015-03-10T15:23:24Z

Notes on Distances

@@ Line 159: / Line 159: @@
 Recall that '''THE POINT''' of doing this is to start to develop a sense of (1) what resolution these various telescopes have (and how to get reliable images out of these tools); and (2) why this matters for our multi-wavelength catalog merging.  Is this starting to make more sense?
-Questions to be sure you know the answer to:
+Questions to be sure you know the answer to (for reference, I guess these are Q4.x):
 # How can you get access to data using Skyview? Using FinderChart? When would you use one vs. the other?
 # Just because you have resampled an image to really tiny pixels, does it add information to the image? (Will you laugh at CSI and Law & Order and their compatriots when they wave a magic wand over an image?)

@@ Line 30: / Line 30: @@
 For [http://skyview.gsfc.nasa.gov/ Skyview], we will use the full Query form, not Quick View and not Non-Astronomer's page.
-Skyview pulls together some huge number of surveys in one place and makes them accessible to you in an easy, fast interface. It will resample and regrid and remosaic all sorts of surveys for you, from gamma rays to the radio. I don't know exactly if it conserves flux (e.g., if one can still do photometry off of the mosaics it provides); I would err on the side of caution and NOT use this for anything other than morphology, e.g., do science by eye with the mosaics, and you can use them for distance measurements on the images, but don't do photometry on these mosaics.
+Skyview pulls together some huge number of surveys in one place and makes them accessible to you in an easy, fast interface. It will resample and regrid and remosaic all sorts of surveys for you, from gamma rays to the radio. (That is, as we will see, both a strength and a weakness.) I don't know exactly if it conserves flux (e.g., if one can still do photometry off of the mosaics it provides); I would err on the side of caution and NOT use this for anything other than morphology, e.g., do science by eye with the mosaics, and you can use them for distance measurements on the images, but don't do photometry on these mosaics.
 Skyview will always spawn the same second window for the results. The first time you call it, it will spawn a second browser tab or window (depending on your local configuration), and then, if you don't close that second tab or window explicitly, the next search results will go into that same window, even if it's hidden below where you are currently working.  ''It will make it seem as if nothing has happened when you submit your search request.''

← Older revision		Revision as of 15:38, 10 March 2015
Line 175:		Line 175:

	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, each of which are at slightly different positions (that's important), 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.		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, each of which are at slightly different positions (that's important), 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.
		+
		+	Note - critical to making this process work is that the camera moves between scans to slightly different positions, and the source it is looking at is not changing in brightness. Will this process work on security camera videos?

	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! :)		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! :)

@@ Line 161: / Line 161: @@
 Questions to be sure you know the answer to:
 # How can you get access to data using Skyview? Using FinderChart? When would you use one vs. the other?
 # Will we see disks or rings in our data?
 # How does the spatial resolution of 2MASS, WISE, and IRAC compare?

@@ Line 180: / Line 180: @@
 For our project, we have a list of "things in which we are interested" which consists of (a) objects Xavier identified one way or another as possible YSOs; (b) objects from the literature that someone identified as interesting (OB stars, carbon stars, halpha stars). This list of sources is inhomogeneous in that some sources come from WISE directly, and some come from other observations. Our path forward:
-* Assemble list of objects from the literature
+* Assemble list of objects from the literature.
 * For each of those objects, make sure that we are confident in which source it matches in 2MASS/WISE at least. (Will use FinderChart for this.)
 * Take list of objects from the literature with corrected positions, and merge it to list from Xavier.
 * Take net list of "things in which we are interested" and pass it to FinderChart for POSS/2MASS/WISE; take notes on which look like point sources and which look like artifacts or non-point-sources.
 * If at all possible, also look at these objects (those surviving prior step) in GLIMPSE and IPHAS using ds9. (This will be a little harder than FinderChart in that it has a little steeper learning curve to make it work smoothly.)  Take notes on which look like point sources and which may be breaking into pieces in the higher-resolution images.

@@ Line 159: / Line 159: @@
 Recall that '''THE POINT''' of doing this is to start to develop a sense of (1) what resolution these various telescopes have (and how to get reliable images out of these tools); and (2) why this matters for our multi-wavelength catalog merging.  Is this starting to make more sense?
-Basic questions to be sure you know the answer to:
+Questions to be sure you know the answer to:
-* How can you get access to data using Skyview? Using FinderChart? When would you use one vs. the other?
+# How can you get access to data using Skyview? Using FinderChart? When would you use one vs. the other?
-* Will we see disks or rings in our data?
+# Will we see disks or rings in our data?
-* How does the spatial resolution of 2MASS, WISE, and IRAC compare?
+# How does the spatial resolution of 2MASS, WISE, and IRAC compare?
-* Is is possible that the sources seen as individual with WISE will break into pieces when viewed with IRAC?
+# Is is possible that the sources seen as individual with WISE will break into pieces when viewed with IRAC?
-* Is there any guarantee that a single source seen with IRAC is really a single object?
+# Is there any guarantee that a single source seen with IRAC is really a single object?
+#Bonus question: Using Fig 1 from Jose et al., over what size region (approximately) does this figure imply they are reporting optical broadband photometry? You don't have to measure all the line segments exactly, but an approximate estimate of the area covered by the optical broadband photometry is useful in the context of the writeup we will have to do eventually. "We used the optical photometry from Jose et al. (2008) over a region x by y arcmin in the center of our field."
 =Postscript on the resolution issues: Slight improvements are sometimes possible=

@@ Line 106: / Line 106: @@
 We are studying a square that is ~1 deg on a side, centered on 5:28:00 34:30:00. (bonus: what is that in decimal degrees?)
-Go to [http://irsa.ipac.caltech.edu/applications/finderchart/ FinderChart] and ask it for degree-size images at that coordinate for POSS, 2MASS, WISE, and IRAS. (There aren't any SDSS data.) Turn off catalog searching because otherwise it gets just too confusing.
+Go to [http://irsa.ipac.caltech.edu/applications/finderchart/ FinderChart] and ask it for degree-size images at that coordinate for POSS, 2MASS, WISE, and IRAS. (There aren't any SDSS data.) Turn off catalog searching for now because otherwise it gets just too confusing.
 '''Q2.1 :''' For the images that it returns, what is the size of each pixel for each survey? (Make the image big enough in your view of it that you can see pixels, and measure the size of it.) Try at least one image from each of the surveys.  Three of these four surveys were electronic from the start; the original POSS was photographs, so the 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, this gets mapped into the pixels you see in the images.

@@ Line 86: / Line 86: @@
 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 relatively small distances, it should be mostly fine to simply subtract the RA and Dec to get a reasonable estimate of the distance BUT WATCH YOUR UNITS because RA by default is in hours:min of time:sec of time, not deg:arcmin:arcsec.
-The spherical trig 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 in most cases.) 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?)
+The spherical trig 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 in most cases.) 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 in IC417 does it make if you leave out the cos(dec) term? Is that going to get worse or better if we move close to the north celestial pole?)
 =Getting started: what sizes do we expect?=

@@ Line 82: / Line 82: @@
 You can also measure distances by hand by comparing pixel coordinates. Note that as you move your mouse around on the image in any of these FITS viewers, it will give you an updated readout of the ra and dec near the top. You can change this from hh:mm:ss ddd:mm:ss format to decimal degrees for both ra and dec -- for ds9, you do this by picking from the "wcs" menu at the top, either 'degrees' or 'sexagesimal'. Make a note of the RA/Dec from which you want to measure a distance, and the RA/Dec of the end point of the distance measure.
-No matter how, exactly, you do this, WATCH YOUR UNITS. '''RA by default is in hours, not degrees. Dec by default IS in degrees.'''
+No matter how, exactly, you do this, WATCH YOUR UNITS. '''RA by default is in hours, not degrees. Dec by default IS in degrees.''' How do you convert between hours and degrees? (Hint: there are 24 hours of RA ...and 360 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 relatively small distances, it should be mostly fine to simply subtract the RA and Dec to get a reasonable estimate of the distance BUT WATCH YOUR UNITS because RA by default is in hours:min of time:sec of time, not deg:arcmin:arcsec.
 The spherical trig 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?)
 =Getting started: what sizes do we expect?=