----------------------------

#24484 Jun 3, 2006

In MaximDL, the value for FWHM reported in the Information Window

(Aperture mode) is highly dependent on the value set for the aperture

radius. I've observed this on several images, but let's concentrate on

just one simple image I took of Arcturus a week ago. The webpage is here:

www.princeton.edu/~rvd

The jpg of the unprocessed stacked image is here:

www.princeton.edu/~rvd

A cross-sectional line profile is here:

www.princeton.edu/~rvd

The individual exposures from which this stacked image was made were

only half saturated (peak values were about 35000). In any case, the

line profile shows that the top is not clipped. The line profile also

clearly and unambiguously shows that the FWHM is 4.0 pixels. If I set

the aperture radius to 2, MaximDL reports 4.0. But, as I increase the

aperture radius, the value steadily grows. With radius set to 5,

MaximDL reports FWHM = 4.5. With radius set to 8, it reports FWHM =

5.0. For these particular measurements, I had "gap width" and "annulus

radius" set to 5 and 10, respectively, although I get similar results

for other settings. Also, I looked at the line profile from four

different orientations and in all cases it is clear that the correct

value of FWHM is very close to 4.0.

Is there any specific recommendation on how to use the Information

Window's report to get reliable estimates of FWHM?

--

Robert J. Vanderbei

www.princeton.edu/~rvdb

"I sleep in the daytime, work in the nighttime,

I might not ever get home" -- Talking Heads

----------------------------

#24491 Jun 3, 2006

Robert,

The reality is, there is *no* "official" way to measure FWHM, and every

technique used is ad-hoc -- and a compromise.

We use a method similar to that used in IRAF, which is to fit a Gaussian to the

star profile.

This technique is however sensitive to background level, so it is *very*

important to use a large background annulus (outer ring) to ensure an accurate

background measurement. If that is done, the sensitivity to measurement radius

(inner ring) is reduced.

As a practical matter, adjusting the radius so that it encompases the visible

star light, and no more, is probably a good idea.

Doug

---------------

Doug George

dgeorge@...

Diffraction Limited

Makers of Cyanogen Imaging Products

www.cyanogen.com

25 Conover Street

Ottawa, Ontario,

Canada, K2G 4C3

Phone: (613) 225-2732

Fax: (613) 225-9688

---------------

Robert Vanderbei wrote: >

> In MaximDL, the value for FWHM reported in the Information Window

> (Aperture mode) is highly dependent on the value set for the aperture

> radius. I've observed this on several images, but let's concentrate on

> just one simple image I took of Arcturus a week ago. The webpage is here:

>

> www.princeton.edu/~rvd

>

> The jpg of the unprocessed stacked image is here:

>

> www.princeton.edu/~rvd

>

> A cross-sectional line profile is here:

>

> www.princeton.edu/~rvd

>

> The individual exposures from which this stacked image was made were

> only half saturated (peak values were about 35000). In any case, the

> line profile shows that the top is not clipped. The line profile also

> clearly and unambiguously shows that the FWHM is 4.0 pixels. If I set

> the aperture radius to 2, MaximDL reports 4.0. But, as I increase the

> aperture radius, the value steadily grows. With radius set to 5,

> MaximDL reports FWHM = 4.5. With radius set to 8, it reports FWHM =

> 5.0. For these particular measurements, I had "gap width" and "annulus

> radius" set to 5 and 10, respectively, although I get similar results

> for other settings. Also, I looked at the line profile from four

> different orientations and in all cases it is clear that the correct

> value of FWHM is very close to 4.0.

>

> Is there any specific recommendation on how to use the Information

> Window's report to get reliable estimates of FWHM?

----------------------------

#24492 Jun 3, 2006

Hi Doug,

Actually, I still think something must be wrong. The example I posted

has a very high S/N ratio and the background level is almost nil and

the outer annulus that I selected is quite large. Given all of that

it is hard for me to imagine any "correct" gaussian fit that would

give FWHM >= 5 on this example. I have posted the fits file at

www.princeton.edu/~rvd

If it is possible for you to make a picture showing the gaussian fit

overlayed on the horizontal or vertical line profile, I'd sure love to

see it (and I think it will convince you that there is something that

could be improved here).

--Bob

--- In MaxImDL@yahoogroups.co

>

> Robert,

>

> The reality is, there is *no* "official" way to measure FWHM, and every

> technique used is ad-hoc -- and a compromise.

>

> We use a method similar to that used in IRAF, which is to fit a

Gaussian to the

> star profile.

>

> This technique is however sensitive to background level, so it is

*very*

> important to use a large background annulus (outer ring) to ensure

an accurate

> background measurement. If that is done, the sensitivity to

measurement radius

> (inner ring) is reduced.

>

> As a practical matter, adjusting the radius so that it encompases

the visible

> star light, and no more, is probably a good idea.

>

> Doug

>

---------------

>

> Doug George

> dgeorge@...

>

> Diffraction Limited

> Makers of Cyanogen Imaging Products

> www.cyanogen.com

>

> 25 Conover Street

> Ottawa, Ontario,

> Canada, K2G 4C3

>

> Phone: (613) 225-2732

> Fax: (613) 225-9688

>

---------------

>

>

> Robert Vanderbei wrote:

> >

> > In MaximDL, the value for FWHM reported in the Information Window

> > (Aperture mode) is highly dependent on the value set for the aperture

> > radius. I've observed this on several images, but let's

concentrate on

> > just one simple image I took of Arcturus a week ago. The webpage

is here:

> >

> > www.princeton.edu/~rvd

> >

> > The jpg of the unprocessed stacked image is here:

> >

> > www.princeton.edu/~rvd

> >

> > A cross-sectional line profile is here:

> >

> > www.princeton.edu/~rvd

> >

> > The individual exposures from which this stacked image was made were

> > only half saturated (peak values were about 35000). In any case, the

> > line profile shows that the top is not clipped. The line profile

also

> > clearly and unambiguously shows that the FWHM is 4.0 pixels. If I

set

> > the aperture radius to 2, MaximDL reports 4.0. But, as I increase

the

> > aperture radius, the value steadily grows. With radius set to 5,

> > MaximDL reports FWHM = 4.5. With radius set to 8, it reports FWHM =

> > 5.0. For these particular measurements, I had "gap width" and

"annulus

> > radius" set to 5 and 10, respectively, although I get similar results

> > for other settings. Also, I looked at the line profile from four

> > different orientations and in all cases it is clear that the correct

> > value of FWHM is very close to 4.0.

> >

> > Is there any specific recommendation on how to use the Information

> > Window's report to get reliable estimates of FWHM?

>

----------------------------

#24494 Jun 3, 2006

Interesting observation Bob.

Here's my attempt at a graphical overlay of a reference gaussian

curve, as opposed to a computational fit:

winfij.homeip.net/gaus

It seems to show that the line profile is a reasonable gaussian curve.

A manual measurement of the FWHM from the graph gives a value of

around 4 as you noted. However, a measurement of the fitted gaussian

gives a value of around 4.5

A slight difference in the fitting of the gaussian could easily

explain the difference up to 5.0 I think, since this is not a perfect

fit to the line profile.

What do you think?

Regards,

John

--- In MaxImDL@yahoogroups.co

>

> Hi Doug,

>

> Actually, I still think something must be wrong. The example I posted

> has a very high S/N ratio and the background level is almost nil and

> the outer annulus that I selected is quite large. Given all of that

> it is hard for me to imagine any "correct" gaussian fit that would

> give FWHM >= 5 on this example. I have posted the fits file at

>

> www.princeton.edu/~rvd

>

> If it is possible for you to make a picture showing the gaussian fit

> overlayed on the horizontal or vertical line profile, I'd sure love to

> see it (and I think it will convince you that there is something that

> could be improved here).

>

> --Bob

>

>

> --- In MaxImDL@yahoogroups.co

> >

> > Robert,

> >

> > The reality is, there is *no* "official" way to measure FWHM, and

every

> > technique used is ad-hoc -- and a compromise.

> >

> > We use a method similar to that used in IRAF, which is to fit a

> Gaussian to the

> > star profile.

> >

> > This technique is however sensitive to background level, so it is

> *very*

> > important to use a large background annulus (outer ring) to ensure

> an accurate

> > background measurement. If that is done, the sensitivity to

> measurement radius

> > (inner ring) is reduced.

> >

> > As a practical matter, adjusting the radius so that it encompases

> the visible

> > star light, and no more, is probably a good idea.

> >

> > Doug

> >

---------------

> >

> > Doug George

> > dgeorge@

> >

> > Diffraction Limited

> > Makers of Cyanogen Imaging Products

> > www.cyanogen.com

> >

> > 25 Conover Street

> > Ottawa, Ontario,

> > Canada, K2G 4C3

> >

> > Phone: (613) 225-2732

> > Fax: (613) 225-9688

> >

---------------

> >

> >

> > Robert Vanderbei wrote:

> > >

> > > In MaximDL, the value for FWHM reported in the Information Window

> > > (Aperture mode) is highly dependent on the value set for the

aperture

> > > radius. I've observed this on several images, but let's

> concentrate on

> > > just one simple image I took of Arcturus a week ago. The webpage

> is here:

> > >

> > > www.princeton.edu/~rvd

> > >

> > > The jpg of the unprocessed stacked image is here:

> > >

> > > www.princeton.edu/~rvd

> > >

> > > A cross-sectional line profile is here:

> > >

> > > www.princeton.edu/~rvd

> > >

> > > The individual exposures from which this stacked image was made

were

> > > only half saturated (peak values were about 35000). In any

case, the

> > > line profile shows that the top is not clipped. The line profile

> also

> > > clearly and unambiguously shows that the FWHM is 4.0 pixels. If I

> set

> > > the aperture radius to 2, MaximDL reports 4.0. But, as I increase

> the

> > > aperture radius, the value steadily grows. With radius set to 5,

> > > MaximDL reports FWHM = 4.5. With radius set to 8, it reports

FWHM =

> > > 5.0. For these particular measurements, I had "gap width" and

> "annulus

> > > radius" set to 5 and 10, respectively, although I get similar

results

> > > for other settings. Also, I looked at the line profile from four

> > > different orientations and in all cases it is clear that the

correct

> > > value of FWHM is very close to 4.0.

> > >

> > > Is there any specific recommendation on how to use the Information

> > > Window's report to get reliable estimates of FWHM?

> >

>

----------------------------

#24497 Jun 4, 2006

Now I understand...

I wrote a matlab program to mimic what Doug says is done in MaximDL.

That is, I fit a gaussian to the data by first estimating the

background (using the outer annulus) and then computing the centroid

and the x and y variances by masking out everything outside the inner

circle. I get results that are consistent with MaximDL.

And, now I understand why this is a bad method. Statistics based on

Gaussian random variables are notoriously non-robust and this is an

example of that. If you look at your plot or the one I made (which is

posted at

www.princeton.edu/~rvd

the star psf is not really a Gaussian. It has "fat tails". How much

of these fat tails one includes in the computation makes a big

difference in the estimation of the variance. For this example, shown

in the aforementioned pdf file, I used

r0 = 5, r1 = 10, and r2 = 15

for the three radii and, with those values, I get

fwhm_x = 4.47, fwhm_y = 4.41

and clearly the plotted Gaussian fit looks too fat at the half-height

point.

I then added to my matlab code a simpler calculation that just looks

at the x-slice and the y-slice and does a simple brute force

computation of the fwhm. The horizontal bar in the pdf file

illustrates this for the x-slice. Using this method, I get

fwhm_x = 3.91, fwhm_y = 3.98.

These values are much more accurate, they are robust, and they are

easy to compute. I have posted the matlab code at

www.princeton.edu/~rvd

(yeah, I know matlab sucks but I don't have handy any c-code for

reading fits files).

--Bob

--- In MaxImDL@yahoogroups.co

>

> Interesting observation Bob.

>

> Here's my attempt at a graphical overlay of a reference gaussian

> curve, as opposed to a computational fit:

>

> winfij.homeip.net/gaus

>

> It seems to show that the line profile is a reasonable gaussian curve.

> A manual measurement of the FWHM from the graph gives a value of

> around 4 as you noted. However, a measurement of the fitted gaussian

> gives a value of around 4.5

> A slight difference in the fitting of the gaussian could easily

> explain the difference up to 5.0 I think, since this is not a perfect

> fit to the line profile.

>

> What do you think?

>

> Regards,

>

> John

>

>

> --- In MaxImDL@yahoogroups.co

> >

> > Hi Doug,

> >

> > Actually, I still think something must be wrong. The example I posted

> > has a very high S/N ratio and the background level is almost nil and

> > the outer annulus that I selected is quite large. Given all of that

> > it is hard for me to imagine any "correct" gaussian fit that would

> > give FWHM >= 5 on this example. I have posted the fits file at

> >

> > www.princeton.edu/~rvd

> >

> > If it is possible for you to make a picture showing the gaussian fit

> > overlayed on the horizontal or vertical line profile, I'd sure love to

> > see it (and I think it will convince you that there is something that

> > could be improved here).

> >

> > --Bob

> >

> >

> > --- In MaxImDL@yahoogroups.co

> > >

> > > Robert,

> > >

> > > The reality is, there is *no* "official" way to measure FWHM, and

> every

> > > technique used is ad-hoc -- and a compromise.

> > >

> > > We use a method similar to that used in IRAF, which is to fit a

> > Gaussian to the

> > > star profile.

> > >

> > > This technique is however sensitive to background level, so it is

> > *very*

> > > important to use a large background annulus (outer ring) to ensure

> > an accurate

> > > background measurement. If that is done, the sensitivity to

> > measurement radius

> > > (inner ring) is reduced.

> > >

> > > As a practical matter, adjusting the radius so that it encompases

> > the visible

> > > star light, and no more, is probably a good idea.

> > >

> > > Doug

> > >

---------------

> > >

> > > Doug George

> > > dgeorge@

> > >

> > > Diffraction Limited

> > > Makers of Cyanogen Imaging Products

> > > www.cyanogen.com

> > >

> > > 25 Conover Street

> > > Ottawa, Ontario,

> > > Canada, K2G 4C3

> > >

> > > Phone: (613) 225-2732

> > > Fax: (613) 225-9688

> > >

---------------

> > >

> > >

> > > Robert Vanderbei wrote:

> > > >

> > > > In MaximDL, the value for FWHM reported in the Information Window

> > > > (Aperture mode) is highly dependent on the value set for the

> aperture

> > > > radius. I've observed this on several images, but let's

> > concentrate on

> > > > just one simple image I took of Arcturus a week ago. The webpage

> > is here:

> > > >

> > > > www.princeton.edu/~rvd

> > > >

> > > > The jpg of the unprocessed stacked image is here:

> > > >

> > > > www.princeton.edu/~rvd

> > > >

> > > > A cross-sectional line profile is here:

> > > >

> > > >

www.princeton.edu/~rvd

> > > >

> > > > The individual exposures from which this stacked image was made

> were

> > > > only half saturated (peak values were about 35000). In any

> case, the

> > > > line profile shows that the top is not clipped. The line profile

> > also

> > > > clearly and unambiguously shows that the FWHM is 4.0 pixels. If I

> > set

> > > > the aperture radius to 2, MaximDL reports 4.0. But, as I increase

> > the

> > > > aperture radius, the value steadily grows. With radius set to 5,

> > > > MaximDL reports FWHM = 4.5. With radius set to 8, it reports

> FWHM =

> > > > 5.0. For these particular measurements, I had "gap width" and

> > "annulus

> > > > radius" set to 5 and 10, respectively, although I get similar

> results

> > > > for other settings. Also, I looked at the line profile from four

> > > > different orientations and in all cases it is clear that the

> correct

> > > > value of FWHM is very close to 4.0.

> > > >

> > > > Is there any specific recommendation on how to use the

Information

> > > > Window's report to get reliable estimates of FWHM?

> > >

> >

>

----------------------------

#24498 Jun 4, 2006

Hi Bob-

Since you are interested in the math behind this, you might want to look at

the IRAF methods for calculating FWHM (fwhmpsf, psfmeasure, etc). AFAIK all

the common methods used rely on fitting the data to a function (usually

Gaussian), sometimes after using bilinear/bicubic interpolation to increase

the number of points fit. Some tools may use a brute force measurement like

you describe, but only for simple tasks like star extraction or as the first

step in a more complex algorithm. It is well accepted that the actual FWHM

value will depend on the algorithm used (which is why it is usually stated

in papers), but I haven't heard of the FWHM being strongly dependent on

aperture details.

I'd be interested in your comparison of the IRAF methods and that used in

Maxim.

Chris

**********************

Chris L Peterson

Cloudbait Observatory

www.cloudbait.com

----- Original Message -----

From: "vanderbei" rvdb@...>

To: MaxImDL@yahoogroups.co

Sent: Sunday, June 04, 2006 6:49 AM

Subject: [MaxImDL] Re: Question on FWHM...

> Now I understand...

>

> I wrote a matlab program to mimic what Doug says is done in MaximDL.

> That is, I fit a gaussian to the data by first estimating the

> background (using the outer annulus) and then computing the centroid

> and the x and y variances by masking out everything outside the inner

> circle. I get results that are consistent with MaximDL.

>

> And, now I understand why this is a bad method. Statistics based on

> Gaussian random variables are notoriously non-robust and this is an

> example of that. If you look at your plot or the one I made (which is

> posted at

> www.princeton.edu/~rvd

> the star psf is not really a Gaussian. It has "fat tails". How much

> of these fat tails one includes in the computation makes a big

> difference in the estimation of the variance. For this example, shown

> in the aforementioned pdf file, I used

>

> r0 = 5, r1 = 10, and r2 = 15

>

> for the three radii and, with those values, I get

>

> fwhm_x = 4.47, fwhm_y = 4.41

>

> and clearly the plotted Gaussian fit looks too fat at the half-height

> point.

>

> I then added to my matlab code a simpler calculation that just looks

> at the x-slice and the y-slice and does a simple brute force

> computation of the fwhm. The horizontal bar in the pdf file

> illustrates this for the x-slice. Using this method, I get

>

> fwhm_x = 3.91, fwhm_y = 3.98.

>

> These values are much more accurate, they are robust, and they are

> easy to compute. I have posted the matlab code at

>

> www.princeton.edu/~rvd

>

> (yeah, I know matlab sucks but I don't have handy any c-code for

> reading fits files).

>

> --Bob

----------------------------

#24499 Jun 4, 2006

Hi Bob,

>(yeah, I know matlab sucks but I don't have handy any c-code for reading

fits files)

Take a look at: fits.gsfc.nasa.gov/fit

Just in case you didn't know about this site already. You probably do, but

as I said 'just in case'.

Regards

Robin

[Non-text portions of this message have been removed]

----------------------------

#24500 Jun 4, 2006

I'd be interested in your comparison of the IRAF methods and that used in

Maxim

If any folks are wondering what the heck IRAF is, take a look here:

iraf.noao.edu iraf.noao.edu/>

IRAF can be made to run on Windows platforms but you need to install CygWin

(www.cygwin.com www.cygwin.com/> ) to do it. CygWin is a

*nix emulator.

Even then getting IRAF to work is not for the faint heartedg>! It is also

possible to get PyFITS, PyRAF, WCSTools and the HEATools toolset working.

Some of these will work with just Windows and Python, others need CygWin as

well. If you want more info just drop me a line.

Regards

Robin

-----Original Message-----

From: MaxImDL@yahoogroups.co

Chris Peterson

Sent: 04 June 2006 16:31

To: MaxImDL@yahoogroups.co

Subject: Re: [MaxImDL] Re: Question on FWHM...

Hi Bob-

Since you are interested in the math behind this, you might want to look at

the IRAF methods for calculating FWHM (fwhmpsf, psfmeasure, etc). AFAIK all

the common methods used rely on fitting the data to a function (usually

Gaussian), sometimes after using bilinear/bicubic interpolation to increase

the number of points fit. Some tools may use a brute force measurement like

you describe, but only for simple tasks like star extraction or as the first

step in a more complex algorithm. It is well accepted that the actual FWHM

value will depend on the algorithm used (which is why it is usually stated

in papers), but I haven't heard of the FWHM being strongly dependent on

aperture details.

I'd be interested in your comparison of the IRAF methods and that used in

Maxim.

Chris

**********************

Chris L Peterson

Cloudbait Observatory

www.cloudbait.com

>Stuff deleted

[Non-text portions of this message have been removed]

----------------------------

#24501 Jun 4, 2006

Since the Gaussian curve is only an approximation of the star profile, the

value for FWHM derived from using a Gaussian curve will vary with the

encircled energy. A simple cure is to always use the same encircled energy

value when calculating the FWHM. Otherwise, one would need to use a

parameterized function that more closely fits the actual data.

The non-Gaussian nature of the curve is real, but many amateur instruments

have high scatter and optical aberrations that give the curve an especially

broad foot, making it even more susceptible to variations (poor, variable

fit to Gaussian) when the encircled energy percentage is varied.

Ron Wodaski

www.newastro.com www.newastro.com/>

_____

From: MaxImDL@yahoogroups.co

Chris Peterson

Sent: Sunday, June 04, 2006 8:31 AM

To: MaxImDL@yahoogroups.co

Subject: Re: [MaxImDL] Re: Question on FWHM...

Hi Bob-

Since you are interested in the math behind this, you might want to look at

the IRAF methods for calculating FWHM (fwhmpsf, psfmeasure, etc). AFAIK all

the common methods used rely on fitting the data to a function (usually

Gaussian), sometimes after using bilinear/bicubic interpolation to increase

the number of points fit. Some tools may use a brute force measurement like

you describe, but only for simple tasks like star extraction or as the first

step in a more complex algorithm. It is well accepted that the actual FWHM

value will depend on the algorithm used (which is why it is usually stated

in papers), but I haven't heard of the FWHM being strongly dependent on

aperture details.

I'd be interested in your comparison of the IRAF methods and that used in

Maxim.

Chris

**********************

Chris L Peterson

Cloudbait Observatory

www.cloudbait.com

----- Original Message -----

From: "vanderbei" rvdb@...>

To: MaxImDL@yahoogroups.co

Sent: Sunday, June 04, 2006 6:49 AM

Subject: [MaxImDL] Re: Question on FWHM...

> Now I understand...

>

> I wrote a matlab program to mimic what Doug says is done in MaximDL.

> That is, I fit a gaussian to the data by first estimating the

> background (using the outer annulus) and then computing the centroid

> and the x and y variances by masking out everything outside the inner

> circle. I get results that are consistent with MaximDL.

>

> And, now I understand why this is a bad method. Statistics based on

> Gaussian random variables are notoriously non-robust and this is an

> example of that. If you look at your plot or the one I made (which is

> posted at

> www.princeton.edu/~rvd

> the star psf is not really a Gaussian. It has "fat tails". How much

> of these fat tails one includes in the computation makes a big

> difference in the estimation of the variance. For this example, shown

> in the aforementioned pdf file, I used

>

> r0 = 5, r1 = 10, and r2 = 15

>

> for the three radii and, with those values, I get

>

> fwhm_x = 4.47, fwhm_y = 4.41

>

> and clearly the plotted Gaussian fit looks too fat at the half-height

> point.

>

> I then added to my matlab code a simpler calculation that just looks

> at the x-slice and the y-slice and does a simple brute force

> computation of the fwhm. The horizontal bar in the pdf file

> illustrates this for the x-slice. Using this method, I get

>

> fwhm_x = 3.91, fwhm_y = 3.98.

>

> These values are much more accurate, they are robust, and they are

> easy to compute. I have posted the matlab code at

>

> www.princeton.edu/~rvd

>

> (yeah, I know matlab sucks but I don't have handy any c-code for

> reading fits files).

>

> --Bob

SPONSORED LINKS

Maxim

groups.yahoo.com/gads?

tor&w2=Maxim+lighting&

101&.sig=IEGgA7N_kUnmp

groups.yahoo.com/gads?

2=Maxim+lighting&w3=Cc

sig=TLpOhyndoPQy7J4kdB

groups.yahoo.com/gads?

xim+lighting&w3=Ccd+ca

QBTuZcDE2Wt6J5LcckhsEQ

Ccd

groups.yahoo.com/gads?

axim+lighting&w3=Ccd+c

=skpUF0u1wf-lSpjPrcxLP

groups.yahoo.com/gads?

hting&w3=Ccd+camera&w4

Oednf6jSzp5XUtg> .Sony

groups.yahoo.com/gads?

m+lighting&w3=Ccd+came

J6r9Y1axXgBW4eQA5sOQ> ccd .

_____

YAHOO! GROUPS LINKS

*. Visit your group "MaxImDL groups.yahoo.com/group

on the web.

*. To unsubscribe from this group, send an email to:

MaxImDL-unsubscribe@ya

mailto:MaxImDL-unsubsc

*. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service

docs.yahoo.com/info/te

_____

__________ NOD32 1.1577 (20060604) Information __________

This message was checked by NOD32 antivirus system.

www.eset.com

[Non-text portions of this message have been removed]

----------------------------

#24508 Jun 4, 2006

Hi Robin,

Thanks for the pointer. I have downloaded from there in the past but

had forgotten the link.

--Bob

--- In MaxImDL@yahoogroups.co

rpehlm@...> wrote: >

> Hi Bob,

>

>

>

> >(yeah, I know matlab sucks but I don't have handy any c-code for

reading > fits files)

>

>

>

> Take a look at: fits.gsfc.nasa.gov/fit

>

> Just in case you didn't know about this site already. You probably

do, but > as I said 'just in case'.

>

>

>

> Regards

>

> Robin

>

>

>

>

>

> [Non-text portions of this message have been removed]

>

----------------------------

#24509 Jun 4, 2006

I'm a die-hard Unix guy and only converted to windows when I got into

astroimaging. I have cygwin already installed and I recently

downloaded the IRAF tools for the cygwin environment. But, as you

say, it is not trivial to install. I don't have the time to work on

it just now. Hopefully soon.

--- In MaxImDL@yahoogroups.co

rpehlm@...> wrote: >

> >I'd be interested in your comparison of the IRAF methods and that

used in > Maxim

>

>

>

> If any folks are wondering what the heck IRAF is, take a look here:

> iraf.noao.edu iraf.noao.edu/>

>

>

>

> IRAF can be made to run on Windows platforms but you need to install

CygWin > (www.cygwin.com www.cygwin.com/> ) to do it. CygWin is a

> *nix emulator.

>

> Even then getting IRAF to work is not for the faint heartedg>! It

is also > possible to get PyFITS, PyRAF, WCSTools and the HEATools toolset

working. > Some of these will work with just Windows and Python, others need

CygWin as > well. If you want more info just drop me a line.

>

>

>

> Regards

>

> Robin

>

>

>

> -----Original Message-----

> From: MaxImDL@yahoogroups.co

Behalf Of > Chris Peterson

> Sent: 04 June 2006 16:31

> To: MaxImDL@yahoogroups.co

> Subject: Re: [MaxImDL] Re: Question on FWHM...

>

>

>

> Hi Bob-

>

> Since you are interested in the math behind this, you might want to

look at > the IRAF methods for calculating FWHM (fwhmpsf, psfmeasure, etc).

AFAIK all > the common methods used rely on fitting the data to a function (usually

> Gaussian), sometimes after using bilinear/bicubic interpolation to

increase > the number of points fit. Some tools may use a brute force

measurement like > you describe, but only for simple tasks like star extraction or as

the first >

> step in a more complex algorithm. It is well accepted that the

actual FWHM > value will depend on the algorithm used (which is why it is usually

stated > in papers), but I haven't heard of the FWHM being strongly dependent on

> aperture details.

>

> I'd be interested in your comparison of the IRAF methods and that

used in > Maxim.

>

> Chris

>

> **********************

> Chris L Peterson

> Cloudbait Observatory

> www.cloudbait.com

>

>

>

> >Stuff deleted

>

>

>

> [Non-text portions of this message have been removed]

>

----------------------------

#24512 Jun 4, 2006

By the Central Limit Theorem, the observed PSF is equal to the

convolution of the instrument's PSF convolved with a Gaussian

distribution representing the "seeing". In the best case, the

instrument's PSF decays with radius r like 1/r, which means it has a

MUCH fatter tail than a Gaussian. Hence, a Gaussian distribution is

never correct and this fact has nothing to do with inferior optics.

The instrument I used for the Arcturus experiment is a well-collimated

10" RC from RCOS.

The simple "cure" of always using the same radius is only a good cure

when I am talking to myself. But, if someone asks me what kind of

fwhm I typically get, I don't want to have to tell a long story. And,

that person doesn't want to hear a long stroy. A single number should

suffice (especially since the definition is unambiguous). Even worse,

what if I ask someone what fwhm they get? They will tell me a number.

But, if it came from fitting a Gaussian model, the number is sure to

be almost meaningless and the person telling the number is almost

surely unable to provide the further details to give the number meaning.

So, since the concept is unambiguous, I suggest that MaximDL should

report this number according to its definition and not according to

some fit to an inappropriate model.

Just because professional astronomers do it wrong (at least if Doug is

correct that IRAF does it how he says), that should not be an excuse

for MaximDL to perpetuate the mistake.

Just my 2c.

--Bob

--- In MaxImDL@yahoogroups.co

>

> Since the Gaussian curve is only an approximation of the star

profile, the

> value for FWHM derived from using a Gaussian curve will vary with the

> encircled energy. A simple cure is to always use the same encircled

energy

> value when calculating the FWHM. Otherwise, one would need to use a

> parameterized function that more closely fits the actual data.

>

> The non-Gaussian nature of the curve is real, but many amateur

instruments

> have high scatter and optical aberrations that give the curve an

especially

> broad foot, making it even more susceptible to variations (poor,

variable

> fit to Gaussian) when the encircled energy percentage is varied.

>

>

> Ron Wodaski

> www.newastro.com www.newastro.com/>

>

>

>

>

>

> _____

>

> From: MaxImDL@yahoogroups.co

Behalf Of

> Chris Peterson

> Sent: Sunday, June 04, 2006 8:31 AM

> To: MaxImDL@yahoogroups.co

> Subject: Re: [MaxImDL] Re: Question on FWHM...

>

>

> Hi Bob-

>

> Since you are interested in the math behind this, you might want to

look at

> the IRAF methods for calculating FWHM (fwhmpsf, psfmeasure, etc).

AFAIK all

> the common methods used rely on fitting the data to a function (usually

> Gaussian), sometimes after using bilinear/bicubic interpolation to

increase

> the number of points fit. Some tools may use a brute force

measurement like

> you describe, but only for simple tasks like star extraction or as

the first

>

> step in a more complex algorithm. It is well accepted that the

actual FWHM

> value will depend on the algorithm used (which is why it is usually

stated

> in papers), but I haven't heard of the FWHM being strongly dependent on

> aperture details.

>

> I'd be interested in your comparison of the IRAF methods and that

used in

> Maxim.

>

> Chris

>

> **********************

> Chris L Peterson

> Cloudbait Observatory

> www.cloudbait.com

>

>

> ----- Original Message -----

> From: "vanderbei" rvdb@...>

> To: MaxImDL@yahoogroups.co

> Sent: Sunday, June 04, 2006 6:49 AM

> Subject: [MaxImDL] Re: Question on FWHM...

>

>

> > Now I understand...

> >

> > I wrote a matlab program to mimic what Doug says is done in MaximDL.

> > That is, I fit a gaussian to the data by first estimating the

> > background (using the outer annulus) and then computing the centroid

> > and the x and y variances by masking out everything outside the inner

> > circle. I get results that are consistent with MaximDL.

> >

> > And, now I understand why this is a bad method. Statistics based on

> > Gaussian random variables are notoriously non-robust and this is an

> > example of that. If you look at your plot or the one I made (which is

> > posted at

> > www.princeton.edu/~rvd

> > the star psf is not really a Gaussian. It has "fat tails". How much

> > of these fat tails one includes in the computation makes a big

> > difference in the estimation of the variance. For this example, shown

> > in the aforementioned pdf file, I used

> >

> > r0 = 5, r1 = 10, and r2 = 15

> >

> > for the three radii and, with those values, I get

> >

> > fwhm_x = 4.47, fwhm_y = 4.41

> >

> > and clearly the plotted Gaussian fit looks too fat at the half-height

> > point.

> >

> > I then added to my matlab code a simpler calculation that just looks

> > at the x-slice and the y-slice and does a simple brute force

> > computation of the fwhm. The horizontal bar in the pdf file

> > illustrates this for the x-slice. Using this method, I get

> >

> > fwhm_x = 3.91, fwhm_y = 3.98.

> >

> > These values are much more accurate, they are robust, and they are

> > easy to compute. I have posted the matlab code at

> >

> > www.princeton.edu/~rvd

> >

> > (yeah, I know matlab sucks but I don't have handy any c-code for

> > reading fits files).

> >

> > --Bob

>

>

>

>

> SPONSORED LINKS

> Maxim

>

groups.yahoo.com/gads?

>

tor&w2=Maxim+lighting&

> 101&.sig=IEGgA7N_kUnmp

>

groups.yahoo.com/gads?

>

2=Maxim+lighting&w3=Cc

> sig=TLpOhyndoPQy7J4kdB

>

groups.yahoo.com/gads?

>

xim+lighting&w3=Ccd+ca

> QBTuZcDE2Wt6J5LcckhsEQ

> Ccd

>

groups.yahoo.com/gads?

>

axim+lighting&w3=Ccd+c

> =skpUF0u1wf-lSpjPrcxLP

>

groups.yahoo.com/gads?

>

hting&w3=Ccd+camera&w4

> Oednf6jSzp5XUtg> .Sony

>

groups.yahoo.com/gads?

>

m+lighting&w3=Ccd+came

> J6r9Y1axXgBW4eQA5sOQ> ccd .

>

> _____

>

> YAHOO! GROUPS LINKS

>

>

> .

> *. Visit your group "MaxImDL groups.yahoo.com/group

> on the web.

>

>

> *. To unsubscribe from this group, send an email to:

> MaxImDL-unsubscribe@ya

> mailto:MaxImDL-unsubsc

>

>

> *. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service

> docs.yahoo.com/info/te

>

>

> _____

>

>

>

>

> __________ NOD32 1.1577 (20060604) Information __________

>

> This message was checked by NOD32 antivirus system.

> www.eset.com

>

>

>

> [Non-text portions of this message have been removed]

>

----------------------------

#24513 Jun 4, 2006

Hi John,

This is a good theory except that I doubt very much that IRAF or

MaximDL do curve fitting. If MaximDL did curve fitting, the result

would be largely independent of the selected radii. Although we'll

have to wait for Doug to confirm it, I'm quite sure that MaximDL

simply computes the mean and the variance of the "encircled"

distribution and then assumes that the psf is gaussian with that mean

and that variance. That is a much much cruder approximation than the

curve fitting that you are imaging.

==Bob

--- In MaxImDL@yahoogroups.co

>

> Presumably fitting to a gaussian rather than just taking the slice

> gives a better result if the star is at all saturated?

> That is, assuming the fitting algorithm can compensate for a saturated

> star.

> A simple slice would be using a bogus value for the max, so would give

> completely the wrong result.

>

> This was always the reason I assumed a curve fitting was used.

>

> John

----------------------------

#24515 Jun 4, 2006

The most common IRAF technique subsamples the stellar profile using bicubic

interpolation (at a finer scale near the center of the profile), then fits

the resulting computed profile to a cubic spline function. The FWHM is

calculated analytically from that with the assumption that it is a Gaussian

FWHM.

The algorithm works very well, and I used a variation of it for a star

extractor that produced an accurate FWHM (or at least, consistent) for dim

stars illuminating only around r=1.5 pixels to highly saturated stars many

pixels wide (and clipped).

The IRAF function can also calculate the width based on the radius

containing some fraction of the total flux (typically 50%), but I see the

Gaussian FWHM given in papers much more often.

Chris

**********************

Chris L Peterson

Cloudbait Observatory

www.cloudbait.com

----- Original Message -----

From: "vanderbei" rvdb@...>

To: MaxImDL@yahoogroups.co

Sent: Sunday, June 04, 2006 12:18 PM

Subject: [MaxImDL] Re: Question on FWHM...

> This is a good theory except that I doubt very much that IRAF or

> MaximDL do curve fitting...

----------------------------

#24517 Jun 4, 2006

Hi Chris,

That is certainly more sophisticated than what I did in my matlab

code. The results from my matlab code match quite well with what I

get from MaximDL, so I still am betting that MaximDL does the same as

what I did. But, only Doug can tell us for sure.

I don't think I understand exactly what you are saying IRAF does. I

understand how to subsample the stellar profile using bicubic

interpolation (and, in fact, we can all do this in MaximDL using the

rescale function). I also understand what it means to make a cubic

spline function that represents the subsampled profile. Both of these

steps are very sensible. From this I would calculate the FWHM in the

two slice directions by checking where the spline hits half intensity

on both sides of the slice and computing the difference. But, that

makes no assumption that the profile is Gaussian. It is just a direct

calculation of the FWHM based on this refined "depixelated"

representation of the PSF. The fact that you say IRAF does this last

step "based on the assumption that it is gaussian" makes me think IRAF

might be doing something different (and bad!). Can you provide

details for this last step?

BTW, even though I have downloaded the IRAF "tar" file for cygwin I

have not even "untarred" it successfully yet. I suppose once I do

that, I will be able to answer my questions myself.

--Bob

--- In MaxImDL@yahoogroups.co

>

> The most common IRAF technique subsamples the stellar profile using

bicubic

> interpolation (at a finer scale near the center of the profile),

then fits

> the resulting computed profile to a cubic spline function. The FWHM is

> calculated analytically from that with the assumption that it is a

Gaussian

> FWHM.

>

> The algorithm works very well, and I used a variation of it for a star

> extractor that produced an accurate FWHM (or at least, consistent)

for dim

> stars illuminating only around r=1.5 pixels to highly saturated

stars many

> pixels wide (and clipped).

>

> The IRAF function can also calculate the width based on the radius

> containing some fraction of the total flux (typically 50%), but I

see the

> Gaussian FWHM given in papers much more often.

>

> Chris

>

> **********************

> Chris L Peterson

> Cloudbait Observatory

> www.cloudbait.com

>

>

> ----- Original Message -----

> From: "vanderbei" rvdb@...>

> To: MaxImDL@yahoogroups.co

> Sent: Sunday, June 04, 2006 12:18 PM

> Subject: [MaxImDL] Re: Question on FWHM...

>

>

> > This is a good theory except that I doubt very much that IRAF or

> > MaximDL do curve fitting...

>

----------------------------

#24521 Jun 4, 2006

Nonetheless, the fact is that an SCT will put a lot more energy into that

tail than an RC will.

That is just one reason why, most of the time, reporting a FWHM involves a

long story. G> A single number does not suffice, especially since the

definition is in fact ambiguous (it always involves curve fitting if you

want to be accurate, and this derives directly from the fact that the energy

distribution is non-Gaussian).

Fitting to a Gaussian curve gives you an approximation of the FWHM. If you

need more precision, then you have to look at parameterized curves. Moffat

functions are commonly used for modeling stellar profiles.

FWHM certainly has its uses, but with respect to that (variable) broad foot,

a more suitable number would be one I've suggested before: the width of the

star at a specific S/N value. This tells you what the stars are going to

look like in the final image, and incorporates low-level effects that have a

huge impact on the final result - scattering, miscollimation, optical

aberrations that put energy well out from the star (and not necessarily

symmetrically), and so on. Convention leans heavily on FWHM, but there are

other useful numbers to help understand what is going on, and what to

expect. If we designate the number I described as "Full Width at Minimum

S/N" (FWMSN for short), the the relationship between FWHM and FWMSN (for one

example) says a lot about the state of the optical path.

Ron Wodaski

www.newastro.com www.newastro.com/>

_____

From: MaxImDL@yahoogroups.co

vanderbei

Sent: Sunday, June 04, 2006 12:15 PM

To: MaxImDL@yahoogroups.co

Subject: [MaxImDL] Re: Question on FWHM...

By the Central Limit Theorem, the observed PSF is equal to the

convolution of the instrument's PSF convolved with a Gaussian

distribution representing the "seeing". In the best case, the

instrument's PSF decays with radius r like 1/r, which means it has a

MUCH fatter tail than a Gaussian. Hence, a Gaussian distribution is

never correct and this fact has nothing to do with inferior optics.

The instrument I used for the Arcturus experiment is a well-collimated

10" RC from RCOS.

The simple "cure" of always using the same radius is only a good cure

when I am talking to myself. But, if someone asks me what kind of

fwhm I typically get, I don't want to have to tell a long story. And,

that person doesn't want to hear a long stroy. A single number should

suffice (especially since the definition is unambiguous). Even worse,

what if I ask someone what fwhm they get? They will tell me a number.

But, if it came from fitting a Gaussian model, the number is sure to

be almost meaningless and the person telling the number is almost

surely unable to provide the further details to give the number meaning.

So, since the concept is unambiguous, I suggest that MaximDL should

report this number according to its definition and not according to

some fit to an inappropriate model.

Just because professional astronomers do it wrong (at least if Doug is

correct that IRAF does it how he says), that should not be an excuse

for MaximDL to perpetuate the mistake.

Just my 2c.

--Bob

--- In MaxImDL@yahoogroups.co

>

> Since the Gaussian curve is only an approximation of the star

profile, the

> value for FWHM derived from using a Gaussian curve will vary with the

> encircled energy. A simple cure is to always use the same encircled

energy

> value when calculating the FWHM. Otherwise, one would need to use a

> parameterized function that more closely fits the actual data.

>

> The non-Gaussian nature of the curve is real, but many amateur

instruments

> have high scatter and optical aberrations that give the curve an

especially

> broad foot, making it even more susceptible to variations (poor,

variable

> fit to Gaussian) when the encircled energy percentage is varied.

>

>

> Ron Wodaski

> www.newastro.com www.newastro.com/>

>

>

>

>

>

> _____

>

> From: MaxImDL@yahoogroups.co

Behalf Of

> Chris Peterson

> Sent: Sunday, June 04, 2006 8:31 AM

> To: MaxImDL@yahoogroups.co

> Subject: Re: [MaxImDL] Re: Question on FWHM...

>

>

> Hi Bob-

>

> Since you are interested in the math behind this, you might want to

look at

> the IRAF methods for calculating FWHM (fwhmpsf, psfmeasure, etc).

AFAIK all

> the common methods used rely on fitting the data to a function (usually

> Gaussian), sometimes after using bilinear/bicubic interpolation to

increase

> the number of points fit. Some tools may use a brute force

measurement like

> you describe, but only for simple tasks like star extraction or as

the first

>

> step in a more complex algorithm. It is well accepted that the

actual FWHM

> value will depend on the algorithm used (which is why it is usually

stated

> in papers), but I haven't heard of the FWHM being strongly dependent on

> aperture details.

>

> I'd be interested in your comparison of the IRAF methods and that

used in

> Maxim.

>

> Chris

>

> **********************

> Chris L Peterson

> Cloudbait Observatory

> www.cloudbait.com

>

>

> ----- Original Message -----

> From: "vanderbei" rvdb@...>

> To: MaxImDL@yahoogroups.co

> Sent: Sunday, June 04, 2006 6:49 AM

> Subject: [MaxImDL] Re: Question on FWHM...

>

>

> > Now I understand...

> >

> > I wrote a matlab program to mimic what Doug says is done in MaximDL.

> > That is, I fit a gaussian to the data by first estimating the

> > background (using the outer annulus) and then computing the centroid

> > and the x and y variances by masking out everything outside the inner

> > circle. I get results that are consistent with MaximDL.

> >

> > And, now I understand why this is a bad method. Statistics based on

> > Gaussian random variables are notoriously non-robust and this is an

> > example of that. If you look at your plot or the one I made (which is

> > posted at

> > www.princeton.edu/~rvd

> > the star psf is not really a Gaussian. It has "fat tails". How much

> > of these fat tails one includes in the computation makes a big

> > difference in the estimation of the variance. For this example, shown

> > in the aforementioned pdf file, I used

> >

> > r0 = 5, r1 = 10, and r2 = 15

> >

> > for the three radii and, with those values, I get

> >

> > fwhm_x = 4.47, fwhm_y = 4.41

> >

> > and clearly the plotted Gaussian fit looks too fat at the half-height

> > point.

> >

> > I then added to my matlab code a simpler calculation that just looks

> > at the x-slice and the y-slice and does a simple brute force

> > computation of the fwhm. The horizontal bar in the pdf file

> > illustrates this for the x-slice. Using this method, I get

> >

> > fwhm_x = 3.91, fwhm_y = 3.98.

> >

> > These values are much more accurate, they are robust, and they are

> > easy to compute. I have posted the matlab code at

> >

> > www.princeton.edu/~rvd

> >

> > (yeah, I know matlab sucks but I don't have handy any c-code for

> > reading fits files).

> >

> > --Bob

>

>

>

>

> SPONSORED LINKS

> Maxim

>

groups.yahoo.com/gads?

groups.yahoo.com/gads?

> &k=Maxim+semiconductor

>

tor&w2=Maxim+lighting&

> 101&.sig=IEGgA7N_kUnmp

>

groups.yahoo.com/gads?

groups.yahoo.com/gads?

> &k=Maxim+lighting&w1=M

>

2=Maxim+lighting&w3=Cc

> sig=TLpOhyndoPQy7J4kdB

>

groups.yahoo.com/gads?

groups.yahoo.com/gads?

> &k=Ccd+camera&w1=Maxim

>

xim+lighting&w3=Ccd+ca

> QBTuZcDE2Wt6J5LcckhsEQ

> Ccd

>

groups.yahoo.com/gads?

groups.yahoo.com/gads?

> &k=Ccd+scanner&w1=Maxi

>

axim+lighting&w3=Ccd+c

> =skpUF0u1wf-lSpjPrcxLP

>

groups.yahoo.com/gads?

groups.yahoo.com/gads?

> &k=Ccd&w1=Maxim+semico

>

hting&w3=Ccd+camera&w4

> Oednf6jSzp5XUtg> Sony

>

groups.yahoo.com/gads?

groups.yahoo.com/gads?

> &k=Sony+ccd&w1=Maxim+s

>

m+lighting&w3=Ccd+came

> J6r9Y1axXgBW4eQA5sOQ> ccd

>

> _____

>

> YAHOO! GROUPS LINKS

>

>

>

> * Visit your group "MaxImDL groups.yahoo.com/group

> on the web.

>

>

> * To unsubscribe from this group, send an email to:

> MaxImDL-unsubscribe@ya

> mailto:MaxImDL-unsubsc

>

>

> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service

> docs.yahoo.com/info/te

>

>

> _____

>

>

>

>

> __________ NOD32 1.1577 (20060604) Information __________

>

> This message was checked by NOD32 antivirus system.

> www.eset.com

>

>

>

> [Non-text portions of this message have been removed]

>

SPONSORED LINKS

Maxim

groups.yahoo.com/gads?

tor&w2=Maxim+lighting&

101&.sig=IEGgA7N_kUnmp

groups.yahoo.com/gads?

2=Maxim+lighting&w3=Cc

sig=TLpOhyndoPQy7J4kdB

groups.yahoo.com/gads?

xim+lighting&w3=Ccd+ca

QBTuZcDE2Wt6J5LcckhsEQ

Ccd

groups.yahoo.com/gads?

axim+lighting&w3=Ccd+c

=skpUF0u1wf-lSpjPrcxLP

groups.yahoo.com/gads?

hting&w3=Ccd+camera&w4

Oednf6jSzp5XUtg> .Sony

groups.yahoo.com/gads?

m+lighting&w3=Ccd+came

J6r9Y1axXgBW4eQA5sOQ> ccd .

_____

YAHOO! GROUPS LINKS

*. Visit your group "MaxImDL groups.yahoo.com/group

on the web.

*. To unsubscribe from this group, send an email to:

MaxImDL-unsubscribe@ya

mailto:MaxImDL-unsubsc

*. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service

docs.yahoo.com/info/te

_____

__________ NOD32 1.1578 (20060604) Information __________

This message was checked by NOD32 antivirus system.

www.eset.com

[Non-text portions of this message have been removed]

----------------------------

#24522 Jun 4, 2006

--- In MaxImDL@yahoogroups.co

> Nonetheless, the fact is that an SCT will put a lot more energy into

that > tail than an RC will.

This is true but it is totally tangential to the discussion since even

an excellent optical system has much fatter tails than a gaussian.

>

> That is just one reason why, most of the time, reporting a FWHM

involves a > long story. G> A single number does not suffice, especially since the

> definition is in fact ambiguous (it always involves curve fitting if you

> want to be accurate, and this derives directly from the fact that

the energy > distribution is non-Gaussian).

The definition is utterly precise. It is the "full width at half

maximum". There is no ambiguity in that. Please take a look at the

pdf file I referenced earlier:

www.princeton.edu/~rvd

The gaussian fit is obviously bad and not well defined because it is

strongly dependent on the radius one chooses for sampling the star.

The fwhm, on the other hand, is clear and, more importantly,

unambiguous. And, its definition has nothing to do with the quality

of the optical system.

>

> Fitting to a Gaussian curve gives you an approximation of the FWHM.

A very ill-defined definition. I can get any value between 3.8 and

5.5 using MaximDL with different radii.

If you > need more precision, then you have to look at parameterized curves.

Moffat > functions are commonly used for modeling stellar profiles.

That would be fine. But, fwhm is also fine. It's just that MaximDL

doesn't compute it.

>

> FWHM certainly has its uses, but with respect to that (variable)

broad foot, > a more suitable number would be one I've suggested before: the width

of the > star at a specific S/N value. This tells you what the stars are going to

> look like in the final image, and incorporates low-level effects

that have a > huge impact on the final result - scattering, miscollimation, optical

> aberrations that put energy well out from the star (and not necessarily

> symmetrically), and so on.

This is a reasonable alternative. But, I don't see anything

conceptually wrong with fwhm. The problem is simply that MaximDL (and

possibly other software) are not actually computing it even though

they claim they are. As far as fwmsn giving a truer picture of how a

star will look in the final image, this is true if one limits oneself

to linear stretches of the data and thereby chop off the tops of all

the bright stars. I prefer to apply a log stretch so that I don't

abruptly chop off the tops in my final images. In that case, this

distinction between fwhm and fwmsn is blurred.

> Convention leans heavily on FWHM, but there are

> other useful numbers to help understand what is going on, and what to

> expect. If we designate the number I described as "Full Width at Minimum

> S/N" (FWMSN for short), the the relationship between FWHM and FWMSN

(for one > example) says a lot about the state of the optical path.

One final comment...for fwmsn, you need to define what you mean by

noise and that's another whole can of worms. If one restricts oneself

only to shot noise (which is probably a good idea), then N = sqrt(S)

and so S/N = sqrt(S) and specifying a minimum S/N is directly related

to specifying a minimum S. And, since one stretches images based on

minimum and maximum levels of adu (ie S), I would suggest rephrasing

your idea as "full width at a specified signal level" or FWS.

--Bob

----------------------------

#24539 Jun 5, 2006

See my comments below.

Ron Wodaski

www.newastro.com www.newastro.com/>

_____

From: MaxImDL@yahoogroups.co

vanderbei

Sent: Sunday, June 04, 2006 5:44 PM

To: MaxImDL@yahoogroups.co

Subject: [MaxImDL] Re: Question on FWHM...

--- In MaxImDL@yahoogroups.co

>

> Nonetheless, the fact is that an SCT will put a lot more energy into

that

> tail than an RC will.

This is true but it is totally tangential to the discussion since even

an excellent optical system has much fatter tails than a gaussian.

--> It may not be relevant to you, but it's a critical point during

processing. Measuring FWHM is non-predictive unless you include the tail.

From a processing perspective, the usefulness of the FWHM metric is greatly

reduced unless one takes into account the differences between optical

systems.

>

> That is just one reason why, most of the time, reporting a FWHM

involves a

> long story. G> A single number does not suffice, especially since the

> definition is in fact ambiguous (it always involves curve fitting if you

> want to be accurate, and this derives directly from the fact that

the energy

> distribution is non-Gaussian).

The definition is utterly precise. It is the "full width at half

maximum". There is no ambiguity in that.

--> The ambiguity is in the match between the FWHM number and the star

profile. The FWHM can poorly characterize the star profile. If portions of

the star profile that are variable are included, yes, that pollutes the FWHM

measurement. Whether the FWHM is useful and representative is what is

ambiguous.

Please take a look at the

pdf file I referenced earlier:

www.princeton.edu/~rvd

The gaussian fit is obviously bad and not well defined because it is

strongly dependent on the radius one chooses for sampling the star.

The fwhm, on the other hand, is clear and, more importantly,

unambiguous. And, its definition has nothing to do with the quality

of the optical system.

--> And it also has limited utility for the very same reason.

>

> Fitting to a Gaussian curve gives you an approximation of the FWHM.

A very ill-defined definition. I can get any value between 3.8 and

5.5 using MaximDL with different radii.

If you

> need more precision, then you have to look at parameterized curves.

Moffat

> functions are commonly used for modeling stellar profiles.

That would be fine. But, fwhm is also fine. It's just that MaximDL

doesn't compute it.

--> It sounds to me like what you are saying is that the FWHM should be

computed based on a truncated curve, keeping only the portion that

approximates a Gaussian.

>

> FWHM certainly has its uses, but with respect to that (variable)

broad foot,

> a more suitable number would be one I've suggested before: the width

of the

> star at a specific S/N value. This tells you what the stars are going to

> look like in the final image, and incorporates low-level effects

that have a

> huge impact on the final result - scattering, miscollimation, optical

> aberrations that put energy well out from the star (and not necessarily

> symmetrically), and so on.

This is a reasonable alternative. But, I don't see anything

conceptually wrong with fwhm.

--> What I see as the weakness is the disconnect from the optical system.

The FWHM winds up measuring the seeing plus some portion of the optical

system that is poorly defined; varies with aperture/algorithm, etc. You are

questioning the accuracy of the FWHM measurement; I am questioning its

usefulness as well.

The problem is simply that MaximDL (and

possibly other software) are not actually computing it even though

they claim they are. As far as fwmsn giving a truer picture of how a

star will look in the final image, this is true if one limits oneself

to linear stretches of the data and thereby chop off the tops of all

the bright stars. I prefer to apply a log stretch so that I don't

abruptly chop off the tops in my final images. In that case, this

distinction between fwhm and fwmsn is blurred.

--> Not at all. The outer diameters of a processed star image is identical

whether one lops off the tops or does a non-linear stretch. The outer

diameter is always a function of the S/N revealed by the processing, by

whatever means.

> Convention leans heavily on FWHM, but there are

> other useful numbers to help understand what is going on, and what to

> expect. If we designate the number I described as "Full Width at Minimum

> S/N" (FWMSN for short), the the relationship between FWHM and FWMSN

(for one

> example) says a lot about the state of the optical path.

One final comment...for fwmsn, you need to define what you mean by

noise and that's another whole can of worms. If one restricts oneself

only to shot noise (which is probably a good idea), then N = sqrt(S)

and so S/N = sqrt(S) and specifying a minimum S/N is directly related

to specifying a minimum S. And, since one stretches images based on

minimum and maximum levels of adu (ie S), I would suggest rephrasing

your idea as "full width at a specified signal level" or FWS.

--> This is true only if it's true. G> That is, it's only true if the

sub-exposures are shot-noise limited. So that is a special case that allows

a simplification. When the special case is not met, the more general

specification must be used.

--> Since signal varies dramatically throughout the image, and thus S/N

does, yes, there may be different signal levels at which the full width is

interesting. However, it is the minimal useful signal level that is the most

interesting in most cases, as it defines the limit of processing. Knowing

the character of the data at that particular S/N allows one to filter or

process the data accurately.

--Bob

SPONSORED LINKS

Maxim

groups.yahoo.com/gads?

tor&w2=Maxim+lighting&

101&.sig=IEGgA7N_kUnmp

groups.yahoo.com/gads?

2=Maxim+lighting&w3=Cc

sig=TLpOhyndoPQy7J4kdB

groups.yahoo.com/gads?

xim+lighting&w3=Ccd+ca

QBTuZcDE2Wt6J5LcckhsEQ

Ccd

groups.yahoo.com/gads?

axim+lighting&w3=Ccd+c

=skpUF0u1wf-lSpjPrcxLP

groups.yahoo.com/gads?

hting&w3=Ccd+camera&w4

Oednf6jSzp5XUtg> .Sony

groups.yahoo.com/gads?

m+lighting&w3=Ccd+came

J6r9Y1axXgBW4eQA5sOQ> ccd .

_____

YAHOO! GROUPS LINKS

*. Visit your group "MaxImDL groups.yahoo.com/group

on the web.

*. To unsubscribe from this group, send an email to:

MaxImDL-unsubscribe@ya

mailto:MaxImDL-unsubsc

*. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service

docs.yahoo.com/info/te

_____

__________ NOD32 1.1578 (20060604) Information __________

This message was checked by NOD32 antivirus system.

www.eset.com

[Non-text portions of this message have been removed]

----------------------------

#24540 Jun 5, 2006

Hi Bob-

The psfmeasure function is fairly complex. Its initial bicubic resampling is

unusual in that it is essentially performed in a polar coordinate space. A

center is estimated, and then the profile is subsampled with a _varying_

radius, so the resolution of the reconstructed profile is higher near the

center (I didn't do this in my code).

The actual radius at half the maximum is measured very much like you

suggest, but is then analytically converted to a new value based on the

assumption of a Gaussian profile. It is this value that is given by the

function for FWHM. The function also displays other metrics, including the

actual radius. But I've noticed that papers present the (assumed Gaussian)

FWHM most of the time.

I have a paper copy of the paper describing the function, or I'd include a

link. Maybe you can track it down- the author is Francisco Valdes, and the

paper was presented at the ASP conference in 1994. The code is available for

inspection, but is hard to figure out without the descriptive paper.

Here is some data I published on the SBIG list a while back, which might be

interesting (note that this is using imexamine, not psfmeasure, and I didn't

record the aperture details used in Maxim):

The first row is from a calibrated image,

with a star at 90% of saturation. The "actual" FWHM is determined from the

average FWHM of eight central stars, using IRAF's imexamine tool. The

following three rows are bicubic resamples of the original image, at 1/2,

1/4, and 1/8 respectively. The values are in pixels and (arcseconds):

Actual Maxim CCDSoft AIP v1 IRAF Scale

4.10 (3.3") 4.30 (3.4") 4.39 (3.5") 4.09 (3.3") 4.15 (3.3") 0.8"/px

2.05 (3.3") 2.31 (3.7") 2.21 (3.5") 2.37 (3.8") 2.10 (3.4") 1.6"/px

1.03 (3.3") 1.28 (4.1") 1.19 (3.8") 1.69 (5.4") 1.06 (3.4") 3.2"/px

0.51 (3.3") 1.17 (7.5") 0.96 (6.1") ---- 0.61 (3.9") 6.4"/px

Chris

**********************

Chris L Peterson

Cloudbait Observatory

www.cloudbait.com

----- Original Message -----

From: "vanderbei" rvdb@...>

To: MaxImDL@yahoogroups.co

Sent: Sunday, June 04, 2006 2:43 PM

Subject: [MaxImDL] Re: Question on FWHM...

> Hi Chris,

>

> That is certainly more sophisticated than what I did in my matlab

> code. The results from my matlab code match quite well with what I

> get from MaximDL, so I still am betting that MaximDL does the same as

> what I did. But, only Doug can tell us for sure.

>

> I don't think I understand exactly what you are saying IRAF does. I

> understand how to subsample the stellar profile using bicubic

> interpolation (and, in fact, we can all do this in MaximDL using the

> rescale function). I also understand what it means to make a cubic

> spline function that represents the subsampled profile. Both of these

> steps are very sensible. From this I would calculate the FWHM in the

> two slice directions by checking where the spline hits half intensity

> on both sides of the slice and computing the difference. But, that

> makes no assumption that the profile is Gaussian. It is just a direct

> calculation of the FWHM based on this refined "depixelated"

> representation of the PSF. The fact that you say IRAF does this last

> step "based on the assumption that it is gaussian" makes me think IRAF

> might be doing something different (and bad!). Can you provide

> details for this last step?

>

> BTW, even though I have downloaded the IRAF "tar" file for cygwin I

> have not even "untarred" it successfully yet. I suppose once I do

> that, I will be able to answer my questions myself.

>

> --Bob

----------------------------

#24542 Jun 5, 2006

Hi Ron,

All of your points are interesting but they are really on another

topic than what I was interested in.

What I was hoping to discuss and hopefully get resolved in a future

release is the fact that MaximDL's computation of FWHM wrong. It is a

computation of something but that something is not FWHM. What's

worse, the computation in MaximDL depends strongly on a user specified

parameter (the radius) even though the concept of FWHM has nothing to

do with this parameter.

If it is any inspiration to Doug, it seems to me that AstroArt does

the calculation correctly.

--Bob

--- In MaxImDL@yahoogroups.co

>

> See my comments below.

>

>

> Ron Wodaski

> www.newastro.com www.newastro.com/>

>

>

>

>

>

> _____

>

> From: MaxImDL@yahoogroups.co

Behalf Of

> vanderbei

> Sent: Sunday, June 04, 2006 5:44 PM

> To: MaxImDL@yahoogroups.co

> Subject: [MaxImDL] Re: Question on FWHM...

>

>

> --- In MaxImDL@yahoogroups.co

> >

> > Nonetheless, the fact is that an SCT will put a lot more energy into

> that

> > tail than an RC will.

>

> This is true but it is totally tangential to the discussion since even

> an excellent optical system has much fatter tails than a gaussian.

>

> --> It may not be relevant to you, but it's a critical point during

> processing. Measuring FWHM is non-predictive unless you include the

tail.

> From a processing perspective, the usefulness of the FWHM metric is

greatly

> reduced unless one takes into account the differences between optical

> systems.

>

> >

> > That is just one reason why, most of the time, reporting a FWHM

> involves a

> > long story. G> A single number does not suffice, especially since the

> > definition is in fact ambiguous (it always involves curve fitting

if you

> > want to be accurate, and this derives directly from the fact that

> the energy

> > distribution is non-Gaussian).

>

> The definition is utterly precise. It is the "full width at half

> maximum". There is no ambiguity in that.

>

> --> The ambiguity is in the match between the FWHM number and the star

> profile. The FWHM can poorly characterize the star profile. If

portions of

> the star profile that are variable are included, yes, that pollutes

the FWHM

> measurement. Whether the FWHM is useful and representative is what is

> ambiguous.

>

> Please take a look at the

> pdf file I referenced earlier:

>

> www.princeton.edu/~rvd

>

> The gaussian fit is obviously bad and not well defined because it is

> strongly dependent on the radius one chooses for sampling the star.

> The fwhm, on the other hand, is clear and, more importantly,

> unambiguous. And, its definition has nothing to do with the quality

> of the optical system.

>

> --> And it also has limited utility for the very same reason.

>

> >

> > Fitting to a Gaussian curve gives you an approximation of the FWHM.

>

> A very ill-defined definition. I can get any value between 3.8 and

> 5.5 using MaximDL with different radii.

>

> If you

> > need more precision, then you have to look at parameterized curves.

> Moffat

> > functions are commonly used for modeling stellar profiles.

>

> That would be fine. But, fwhm is also fine. It's just that MaximDL

> doesn't compute it.

>

> --> It sounds to me like what you are saying is that the FWHM should be

> computed based on a truncated curve, keeping only the portion that

> approximates a Gaussian.

>

> >

> > FWHM certainly has its uses, but with respect to that (variable)

> broad foot,

> > a more suitable number would be one I've suggested before: the width

> of the

> > star at a specific S/N value. This tells you what the stars are

going to

> > look like in the final image, and incorporates low-level effects

> that have a

> > huge impact on the final result - scattering, miscollimation, optical

> > aberrations that put energy well out from the star (and not

necessarily

> > symmetrically), and so on.

>

> This is a reasonable alternative. But, I don't see anything

> conceptually wrong with fwhm.

>

> --> What I see as the weakness is the disconnect from the optical

system.

> The FWHM winds up measuring the seeing plus some portion of the optical

> system that is poorly defined; varies with aperture/algorithm, etc.

You are

> questioning the accuracy of the FWHM measurement; I am questioning its

> usefulness as well.

>

> The problem is simply that MaximDL (and

> possibly other software) are not actually computing it even though

> they claim they are. As far as fwmsn giving a truer picture of how a

> star will look in the final image, this is true if one limits oneself

> to linear stretches of the data and thereby chop off the tops of all

> the bright stars. I prefer to apply a log stretch so that I don't

> abruptly chop off the tops in my final images. In that case, this

> distinction between fwhm and fwmsn is blurred.

>

> --> Not at all. The outer diameters of a processed star image is

identical

> whether one lops off the tops or does a non-linear stretch. The outer

> diameter is always a function of the S/N revealed by the processing, by

> whatever means.

>

> > Convention leans heavily on FWHM, but there are

> > other useful numbers to help understand what is going on, and what to

> > expect. If we designate the number I described as "Full Width at

Minimum

> > S/N" (FWMSN for short), the the relationship between FWHM and FWMSN

> (for one

> > example) says a lot about the state of the optical path.

>

> One final comment...for fwmsn, you need to define what you mean by

> noise and that's another whole can of worms. If one restricts oneself

> only to shot noise (which is probably a good idea), then N = sqrt(S)

> and so S/N = sqrt(S) and specifying a minimum S/N is directly related

> to specifying a minimum S. And, since one stretches images based on

> minimum and maximum levels of adu (ie S), I would suggest rephrasing

> your idea as "full width at a specified signal level" or FWS.

>

> --> This is true only if it's true. G> That is, it's only true if the

> sub-exposures are shot-noise limited. So that is a special case that

allows

> a simplification. When the special case is not met, the more general

> specification must be used.

>

> --> Since signal varies dramatically throughout the image, and thus S/N

> does, yes, there may be different signal levels at which the full

width is

> interesting. However, it is the minimal useful signal level that is

the most

> interesting in most cases, as it defines the limit of processing.

Knowing

> the character of the data at that particular S/N allows one to filter or

> process the data accurately.

>

> --Bob

>

>

>

>

>

>

>

>

> SPONSORED LINKS

> Maxim

>

groups.yahoo.com/gads?

>

tor&w2=Maxim+lighting&

> 101&.sig=IEGgA7N_kUnmp

>

groups.yahoo.com/gads?

>

2=Maxim+lighting&w3=Cc

> sig=TLpOhyndoPQy7J4kdB

>

groups.yahoo.com/gads?

>

xim+lighting&w3=Ccd+ca

> QBTuZcDE2Wt6J5LcckhsEQ

> Ccd

>

groups.yahoo.com/gads?

>

axim+lighting&w3=Ccd+c

> =skpUF0u1wf-lSpjPrcxLP

>

groups.yahoo.com/gads?

>

hting&w3=Ccd+camera&w4

> Oednf6jSzp5XUtg> .Sony

>

groups.yahoo.com/gads?

>

m+lighting&w3=Ccd+came

> J6r9Y1axXgBW4eQA5sOQ> ccd .

>

> _____

>

> YAHOO! GROUPS LINKS

>

>

> .

> *. Visit your group "MaxImDL groups.yahoo.com/group

> on the web.

>

>

> *. To unsubscribe from this group, send an email to:

> MaxImDL-unsubscribe@ya

> mailto:MaxImDL-unsubsc

>

>

> *. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service

> docs.yahoo.com/info/te

>

>

> _____

>

>

>

>

> __________ NOD32 1.1578 (20060604) Information __________

>

> This message was checked by NOD32 antivirus system.

> www.eset.com

>

>

>

> [Non-text portions of this message have been removed]

>

----------------------------

#24545 Jun 5, 2006

Hi Chris,

Thanks for the pointer. I was able to find the Valdes paper here:

iraf.noao.edu/iraf/ftp

The description there is consistent with what you wrote here. To

elaborate slightly, the IRAF algorithm computes a width essentially

exactly as I described before (after resampling and splining for

greater accuracy which mitigates against pixelization). However,

instead of computing the full width at half max, they compute full

width (w) that encloses a certain fraction (f) of the total flux.

This width is then converted to a FWHM number by assuming that the

profile is Gaussian in which case the conversion formula is:

FWHM = w sqrt(log(2)/log(1/(1-f

As you can see, if f=0.5, FWHM = w. That is, if f=0.5 the IRAF

computation matches what I suggested. In practice, IRAF uses f=0.8.

I haven't done this calculation yet, but I suspect it gives a value

that is rather similar to the f=0.5 value.

--Bob

--- In MaxImDL@yahoogroups.co

>

> Hi Bob-

>

> The psfmeasure function is fairly complex. Its initial bicubic

resampling is

> unusual in that it is essentially performed in a polar coordinate

space. A

> center is estimated, and then the profile is subsampled with a

_varying_

> radius, so the resolution of the reconstructed profile is higher

near the

> center (I didn't do this in my code).

>

> The actual radius at half the maximum is measured very much like you

> suggest, but is then analytically converted to a new value based on the

> assumption of a Gaussian profile. It is this value that is given by the

> function for FWHM. The function also displays other metrics,

including the

> actual radius. But I've noticed that papers present the (assumed

Gaussian)

> FWHM most of the time.

>

> I have a paper copy of the paper describing the function, or I'd

include a

> link. Maybe you can track it down- the author is Francisco Valdes,

and the

> paper was presented at the ASP conference in 1994. The code is

available for

> inspection, but is hard to figure out without the descriptive paper.

>

> Here is some data I published on the SBIG list a while back, which

might be

> interesting (note that this is using imexamine, not psfmeasure, and

I didn't

> record the aperture details used in Maxim):

>

> The first row is from a calibrated image,

> with a star at 90% of saturation. The "actual" FWHM is determined

from the

> average FWHM of eight central stars, using IRAF's imexamine tool. The

> following three rows are bicubic resamples of the original image, at

1/2,

> 1/4, and 1/8 respectively. The values are in pixels and (arcseconds):

>

> Actual Maxim CCDSoft AIP v1 IRAF Scale

> 4.10 (3.3") 4.30 (3.4") 4.39 (3.5") 4.09 (3.3") 4.15 (3.3") 0.8"/px

> 2.05 (3.3") 2.31 (3.7") 2.21 (3.5") 2.37 (3.8") 2.10 (3.4") 1.6"/px

> 1.03 (3.3") 1.28 (4.1") 1.19 (3.8") 1.69 (5.4") 1.06 (3.4") 3.2"/px

> 0.51 (3.3") 1.17 (7.5") 0.96 (6.1") ---- 0.61 (3.9") 6.4"/px

>

> Chris

>

> **********************

> Chris L Peterson

> Cloudbait Observatory

> www.cloudbait.com

>

>

> ----- Original Message -----

> From: "vanderbei" rvdb@...>

> To: MaxImDL@yahoogroups.co

> Sent: Sunday, June 04, 2006 2:43 PM

> Subject: [MaxImDL] Re: Question on FWHM...

>

>

> > Hi Chris,

> >

> > That is certainly more sophisticated than what I did in my matlab

> > code. The results from my matlab code match quite well with what I

> > get from MaximDL, so I still am betting that MaximDL does the same as

> > what I did. But, only Doug can tell us for sure.

> >

> > I don't think I understand exactly what you are saying IRAF does. I

> > understand how to subsample the stellar profile using bicubic

> > interpolation (and, in fact, we can all do this in MaximDL using the

> > rescale function). I also understand what it means to make a cubic

> > spline function that represents the subsampled profile. Both of these

> > steps are very sensible. From this I would calculate the FWHM in the

> > two slice directions by checking where the spline hits half intensity

> > on both sides of the slice and computing the difference. But, that

> > makes no assumption that the profile is Gaussian. It is just a direct

> > calculation of the FWHM based on this refined "depixelated"

> > representation of the PSF. The fact that you say IRAF does this last

> > step "based on the assumption that it is gaussian" makes me think IRAF

> > might be doing something different (and bad!). Can you provide

> > details for this last step?

> >

> > BTW, even though I have downloaded the IRAF "tar" file for cygwin I

> > have not even "untarred" it successfully yet. I suppose once I do

> > that, I will be able to answer my questions myself.

> >

> > --Bob

>

----------------------------

#24548 Jun 6, 2006

vanderbei wrote:

> What I was hoping to discuss and hopefully get resolved in a future

> release is the fact that MaximDL's computation of FWHM wrong. It is a

> computation of something but that something is not FWHM.

I disagree with that characterization. Years ago there was a similar argument

over how to calculate FWHM, and we did end up changing our implementation. I

decided to look at how IRAF did the calculation, and use the same method. It

was of course a different implementation; we don't use FORTRAN. But it worked

the same way.

From what you are saying, it sounds like the IRAF implementation has been

changed since that time.

If you would like to submit an algorithm for consideration, we will certainly

evalulate it. The only constraint that I'll put on it, is that it has to

execute reasonably quickly. It has to be responsive when you're waving the

cursor around the image.

Doug

---------------

Doug George

dgeorge@...

Diffraction Limited

Makers of Cyanogen Imaging Products

www.cyanogen.com

25 Conover Street

Ottawa, Ontario,

Canada, K2G 4C3

Phone: (613) 225-2732

Fax: (613) 225-9688

---------------

----------------------------

#24550 Jun 6, 2006

Hi Doug,

I have now studied the IRAF documentation and I have also experimented

with MaximDL using the Arcturus image I posted a few days ago. I

think the situation is as follows.

IRAF does indeed assume a Gaussian profile (bad move on their part).

For a gaussian distribution, the radius R_f that encompasses a

fraction f of the total energy is given by

R_f = sqrt(-2 sigma^2 log(1-f))

and the height I(R_f) of the psf at this radius is given by

I(R_f) = (1-f)I(0).

Hence, f can also be thought of as a 1-f max height parameter. In

other words, taking f=1/2 we get the radius R_f of half max. Using

the gaussian assumption, it is easy to related R_f to R_0.5. The

relation is

R_0.5 = R_f sqrt( log(1/2)/log(1-f) ).

IRAF recommends computing R_f at f=0.8 (i.e., compute the radius at

which the psf height is 20% of the max height). Their recommendation

on how to do this is similar to what I suggested in a previous email

and I'm sure MaximDL does it this way too. That is fit a curve,

resampling and splining as seen fit, and figure out the radius at

which the height is 20% of the max value. Then the R_f is converted

to R_0.5 by the above formula. Doubling the answer gives FWHM. This

is a well-defined procedure. It is a bit of a kludge because of the

translation of a result computed at f=0.8 to an imputed result at

f=0.5. This imputation depends on the assumption of gaussianity and

therefore this computation strictly speaking does not really give

FWHM. BUT, IT IS WELL DEFINED. Because f is fixed at 0.8, it does

not depend on any parameters such as a radius that MaximDL needs.

Hence, this computation gives well defined values that can be

exchanged among people and two such values can be compared one against

another.

But, in MaximDL, the result depends strongly on the "aperture radius".

Here's what I think is happening. I think MaximDL is using the given

aperture radius as the R_f value and is then computing the associated

f value (the formula is f = 1-I(R_f)/I(0)). It is then using the

above formula to impute R_0.5 from R_f using this computed f value.

I'd be willing to bet real money that this is how it is being done. I

have modified my matlab code to do this computation and, on my

Arcturus fit file, I'm getting results fairly consistent with

MaximDL's. The problem with this method, of course, is that f is now

not a fixed number. And, it must be fixed in order to have a

well-defined algorithm. IRAF recommends f=0.8. Although I would

recommend f = 0.5, these two numbers aren't that far apart and so the

results are similar. But, by tying this number to the "aperture

radius", the values of f can vary a great deal and this messes

everything up. I hope you will tell me if I have correctly "reverse

engineered" what MaximDL does. I also hope that in a future release

of MaximDL, the code will be changed so that it always computes the

FWHM using a fixed value of f (either f=0.5 or f=0.8).

Finally, as you can see, what I am suggesting will not cause MaximDL

to run more slowly. In fact, the "corrected" code might be more

efficient.

And finally, finally... I think MaximDL is great. I have been using

it for years and really enjoy it. I hope you don't take offense to my

"complaints" about the FWHM computation.

Respectfully,

--Bob

--- In MaxImDL@yahoogroups.co

>

> I disagree with that characterization. Years ago there was a

similar argument

> over how to calculate FWHM, and we did end up changing our

implementation. I

> decided to look at how IRAF did the calculation, and use the same

method. It

> was of course a different implementation; we don't use FORTRAN. But

it worked

> the same way.

>

> From what you are saying, it sounds like the IRAF implementation

has been

> changed since that time.

>

> If you would like to submit an algorithm for consideration, we will

certainly

> evalulate it. The only constraint that I'll put on it, is that it

has to

> execute reasonably quickly. It has to be responsive when you're

waving the

> cursor around the image.

>

> Doug

----------------------------

#24672 Jun 16, 2006

Robert Vanderbei: > In MaximDL, the value for FWHM reported in the Information Window

> (Aperture mode) is highly dependent on the value set for the aperture

> radius. I've observed this on several images, but let's concentrate on

> just one simple image I took of Arcturus a week ago. [...]

Long discussion ensued... but what are you trying to accomplish? The

preceding is an engineering question, not a mathematical or science one.

I'm looking for the problem, not the particular solution you are trying to

get to.

-- Bob

----------------------------

#24674 Jun 16, 2006

I would like MaximDL to tell me how fat my stars are.

I don't much care what definition of fat it uses as long as the

definition is clearly articulated. The popular measure is

fwhm, which has a very clear definition---it is the width

of the psf at half of the maximum intensity. That is utterly

unambiguous. MaximDL claims to provide this number.

But, it doesn't give it. Worse yet, what it does report is

a number that varies rather significantly with the user specified

aperture radius. Hence, this pseudo-measure is of limited

use and certainly misleading.

Of course, I understand the need to compute very quickly

because one needs to be able to give real-time values as one

moves the mouse over the stars in the image. And, if that

precludes using a better measure, then that is fine. In that case,

however, I would ask that MaximDL not call it FWHM because,

as implemented, it is not.

Bob Denny wrote:

>Robert Vanderbei:

>

>

>>In MaximDL, the value for FWHM reported in the Information Window

>>(Aperture mode) is highly dependent on the value set for the aperture

>>radius. I've observed this on several images, but let's concentrate on

>>just one simple image I took of Arcturus a week ago. [...]

>>

>>

>

>Long discussion ensued... but what are you trying to accomplish? The

>preceding is an engineering question, not a mathematical or science one.

>I'm looking for the problem, not the particular solution you are trying to

>get to.

>

> -- Bob

>

>

>

>

>

>Yahoo! Groups Links

>

>

>

>

>

>

>

>

--

Robert J. Vanderbei

www.princeton.edu/~rvdb

"I sleep in the daytime, work in the nighttime,

I might not ever get home" -- Talking Heads

----------------------------

#24734 Jun 20, 2006

Ah... Ok, I understand. This is a difficult issue, as "all PSFs are not

similar". And the FWHM measure applies to a Gaussian PSF fit, and most

instruments don't produce precise Gaussian profiles. Hence the interminable

discussion. The value depends heavily on the shape, which varies with

optics, focus, and seeing!

My reason for asking the "what do you want to do?" question was to try to

get past the solution and focus on the problem. I think you want to know

how good your astro-photos will probably turn out, where sharper is better.

Is that right?

-- Bob

Robert Vanderbei: > I would like MaximDL to tell me how fat my stars are. I don't much care

> what definition of fat it uses as long as the definition is clearly

> articulated. The popular measure is fwhm, which has a very clear

> definition---it is the width of the psf at half of the maximum

> intensity. That is utterly unambiguous. MaximDL claims to provide this

> number. But, it doesn't give it. Worse yet, what it does report is a

> number that varies rather significantly with the user specified aperture

> radius. Hence, this pseudo-measure is of limited use and certainly

> misleading.

>

> Of course, I understand the need to compute very quickly because one

> needs to be able to give real-time values as one moves the mouse over

> the stars in the image. And, if that precludes using a better measure,

> then that is fine. In that case, however, I would ask that MaximDL not

> call it FWHM because, as implemented, it is not.

----------------------------

#24740 Jun 21, 2006

Paul Howell: > A work-around could be the half-flux diameter. It is well defined and

> takes no user parameters whatever. If I've done my math right this late,

> it is somewhat smaller than FWHM for gaussian like PSFs. One FWHM is

> about 2.35 sigma. For a Gaussian, HFD is around 1.4 sigma. But the

> important thing is that it is a simple, stable metric.

I would call it something better than a work-around :-)) Currently ACP uses

HFD as the metric for determining when to do an adaptive autofocus. The

problem is, however, for common astro-photo type images, the HFD calculated

by MaxIm is sometimes way off. It's probably fooled by the giant nebula

etc. in the image :-))

-- Bob

----------------------------

#24744 Jun 21, 2006

Hi Paul and Bob,

Paul's summary is very succinct and to the point. I also understand the

constraint that whatever is implemented must be computable in real time

so that mousing over will work. HFD does sound quite easy to compute

and therefore might be a reasonable choice. And multiplying the answer

by 2.35/1.4 to do a quasi-conversion to FWHM might also good. In any

case, the documentation for the code (the help files) should tell the

user what is done.

--Bob

Paul Howell wrote:

>I think Bob is asking for a reasonable thing - a measure of how big the

>PSF is without strong dependence on how the user tweaks parameters. This

>allows comparison between images by the same user, and it gives us a

>tool to compare across users that is reasonably robust.

>

>A work-around could be the half-flux diameter. It is well defined and

>takes no user parameters whatever. If I've done my math right this late,

>it is somewhat smaller than FWHM for gaussian like PSFs. One FWHM is

>about 2.35 sigma. For a Gaussian, HFD is around 1.4 sigma. But the

>important thing is that it is a simple, stable metric.

>

>-P

>

>

>

>>-----Original Message-----

>>From: MaxImDL@yahoogroups.co

>>Behalf Of Bob Denny

>>Sent: Tuesday, June 20, 2006 10:46 PM

>>To: MaxImDL@yahoogroups.co

>>Subject: Re: [MaxImDL] Question on FWHM...

>>

>>Ah... Ok, I understand. This is a difficult issue, as "all PSFs are

>>not

>>similar". And the FWHM measure applies to a Gaussian PSF fit, and most

>>instruments don't produce precise Gaussian profiles. Hence the

>>interminable

>>discussion. The value depends heavily on the shape, which varies with

>>optics, focus, and seeing!

>>

>>My reason for asking the "what do you want to do?" question was to try

>>to

>>get past the solution and focus on the problem. I think you want to

>>know

>>how good your astro-photos will probably turn out, where sharper is

>>better.

>>Is that right?

>>

>> -- Bob

>>

>>Robert Vanderbei:

>>

>>

>>>I would like MaximDL to tell me how fat my stars are. I don't much

>>>

>>>

>>care

>>

>>

>>>what definition of fat it uses as long as the definition is clearly

>>>articulated. The popular measure is fwhm, which has a very clear

>>>definition---it is the width of the psf at half of the maximum

>>>intensity. That is utterly unambiguous. MaximDL claims to provide

>>>

>>>

>>this

>>

>>

>>>number. But, it doesn't give it. Worse yet, what it does report is

>>>

>>>

>>a

>>

>>

>>>number that varies rather significantly with the user specified

>>>

>>>

>>aperture

>>

>>

>>>radius. Hence, this pseudo-measure is of limited use and certainly

>>>misleading.

>>>

>>>Of course, I understand the need to compute very quickly because one

>>>needs to be able to give real-time values as one moves the mouse

>>>

>>>

>>over

>>

>>

>>>the stars in the image. And, if that precludes using a better

>>>

>>>

>>measure,

>>

>>

>>>then that is fine. In that case, however, I would ask that MaximDL

>>>

>>>

>>not

>>

>>

>>>call it FWHM because, as implemented, it is not.

>>>

>>>

>>

---------------

>>

>>

>>Great things are happening at Yahoo! Groups. See the new email

>>design.

>>us.click.yahoo.com/r

---------------

>>

>>

>>Yahoo! Groups Links

>>

>>

>>

>>

>>

>>

>>

>

>

>

>

>

>

>

>Yahoo! Groups Links

>

>

>

>

>

>

>

>

--

Robert J. Vanderbei

www.princeton.edu/~rvdb

"If I only had a brain" -- S. Crow

----------------------------

#24751 Jun 21, 2006

One of the things that would affect estimations of both the

FWHM and HFD is determination of sky level. That's not as easy to

determine as you might think at first. Its easy to systematically

over or under-estimate the sky level, either of which would result

in estimates of FWHM or HFD which would vary as a function of psf

intensity. The more robust estimators that I recall used large

measurment annuli, wanted to know about the noise characteristics of

the chip being used (gain and readout noise) and derived statistical

quantities assuming you had already bias, overscan, and dark

subtracted (if not flat field-corrected) your image. After all of

that the peak of the 'cleaned' sky histogram would be fit with some

function, often a gaussian. Even if the program does a great job of

eliminating bright pixels from the sky measurment annulus (near by

stars, hot pixels, cosmic rays, etc.) the distribution is generally

skewed, usually toward the brighter side, so some sort of correction

is made, again based on statistical assumptions which might not be

correct for your image, particularly if it has yet to be processed.

For nice round, seeing-bloated psfs (which is what we're

usually dealing with), an iteratively fit and subtracted

gaussian+residual-map psf model was great for determining both the

sky and fwhm. For sharply focused images the gaussian was not

nearly as good (say for HST images); in which case either Lorentz

functions or, frequently, Moffat functions were used, again with a

scaled residual map, to model the psf, then iteratively fit and

subtract until the residual in the psf-subtracted image was

minimised. After all of that its not unusual to have some small psf-

width vs brightness dependence, particularly at the faint end.

Anyway, as is typical I've gotten off on a tangent, the point I

wanted to make is that sky estimation is not simple and does affect

the measured psf width in a systematic fashion, particularly in

uncalibrated images.

Mike

--- In MaxImDL@yahoogroups.co

>

> I think Bob is asking for a reasonable thing - a measure of how

big the

> PSF is without strong dependence on how the user tweaks

parameters. This

> allows comparison between images by the same user, and it gives us

a

> tool to compare across users that is reasonably robust.

>

> A work-around could be the half-flux diameter. It is well defined

and

> takes no user parameters whatever. If I've done my math right this

late,

> it is somewhat smaller than FWHM for gaussian like PSFs. One FWHM

is

> about 2.35 sigma. For a Gaussian, HFD is around 1.4 sigma. But the

> important thing is that it is a simple, stable metric.

>

> -P

>

> > -----Original Message-----

> > From: MaxImDL@yahoogroups.co

> > Behalf Of Bob Denny

> > Sent: Tuesday, June 20, 2006 10:46 PM

> > To: MaxImDL@yahoogroups.co

> > Subject: Re: [MaxImDL] Question on FWHM...

> >

> > Ah... Ok, I understand. This is a difficult issue, as "all PSFs

are

> > not

> > similar". And the FWHM measure applies to a Gaussian PSF fit,

and most

> > instruments don't produce precise Gaussian profiles. Hence the

> > interminable

> > discussion. The value depends heavily on the shape, which varies

with

> > optics, focus, and seeing!

> >

> > My reason for asking the "what do you want to do?" question was

to try

> > to

> > get past the solution and focus on the problem. I think you want

to

> > know

> > how good your astro-photos will probably turn out, where sharper

is

> > better.

> > Is that right?

> >

> > -- Bob

> >

> > Robert Vanderbei:

> > > I would like MaximDL to tell me how fat my stars are. I don't

much

> > care

> > > what definition of fat it uses as long as the definition is

clearly

> > > articulated. The popular measure is fwhm, which has a very

clear

> > > definition---it is the width of the psf at half of the maximum

> > > intensity. That is utterly unambiguous. MaximDL claims to

provide

> > this

> > > number. But, it doesn't give it. Worse yet, what it does

report is

> > a

> > > number that varies rather significantly with the user specified

> > aperture

> > > radius. Hence, this pseudo-measure is of limited use and

certainly

> > > misleading.

> > >

> > > Of course, I understand the need to compute very quickly

because one

> > > needs to be able to give real-time values as one moves the

mouse

> > over

> > > the stars in the image. And, if that precludes using a better

> > measure,

> > > then that is fine. In that case, however, I would ask that

MaximDL

> > not

> > > call it FWHM because, as implemented, it is not.

> >

> >

> >

---------------

--~--

> > >

> > Great things are happening at Yahoo! Groups. See the new email

> > design.

> > us.click.yahoo.com/rTZ

---------------

---~-

> > >

> >

> >

> > Yahoo! Groups Links

> >

> >

> >

> >

> >

>