Adapting PHD2 for slit spectroscope guiding??

[kenm.h...@gmail.com]

We are a small but dedicated and active amateur group of astronomers who think adding scientific knowledge to the community by carrying out spectroscopy is not only challenging but fun!!

Many of us have been using PHD1 for guiding our target stars onto the slit gap (usually only 19 to 30micron wide!) and carrying out 5 to 10min subs...

We have discussed in the past with Craig possible enhancements to make our life easier....the nudge button was one of them, and incorporating a scalable moveable crosswire overlay (Al's Reticle)

Since the formal launch of PHD2 there has been lots of discussion on the astronomical spectroscopy group as to what "enhancements" would work for us.

http://groups.yahoo.com/neo/groups/a...ns/topics/9016

To paraphrase some of the comments:

The freeze frame feature sounds a nice idea. getting the star exactly
> on the slit PHD can be frustrating when guiding on field stars (when
> guiding on the slit I use a workround which allows the guide position
> to be fixed by clicking on the illuminated slit before starting
> guiding which hopefully will still work in PHD2)
>
>
> Perhaps even better would be the ability to couple a "guide where I
> click, not where the star is" feature with a "nudge" feature (at sub
> pixel steps) for the guide position. This would allow the star to be
> moved exactly onto the slit under guider control and held there.

Could be good for spectroscopy perhaps if someone (sadly not me) has the programming skills to add important features like "guide where I click, not where the star is" to locate the guide point on the slit and "treat a split star image as a single star" to stop the tendency to swing from side to side on the slit.

It has it's good and bad points compared to CCDSoft.
It is much more difficult to accurately position the star on the slit with PHD. I like to position the star on the slit accurately then select a guide star and start guiding on that star. This means not using continuous imaging but taking single exposures and freezing it when the star is accurately on the slit. I couldn't find an easy way to do this with PHD2. I can use single exposures with CCDSoft.
However, when I started guiding PHD uses the entire frame so I can see the slit and the guide star at the same time. This allows constant checking of the position of the target star. CCDSoft uses a small subframe around the guide star of ~20 pixels square. This is faster at downloading but means you don't have an image of the slit unless I'm guiding on the slit and target star. I only do this for bright star as dim ones dissappear on the slit. I also use CCDSoft to take the spectra so only need 1 programme running.

The end result is that both types of software work with advantages to both. CCDSoft is old software now and isn't being updated. If PHD2 can be modified to guide on the dumbell shape of a star on a slit it will have an advantage but until then I think I don't have any reason to swap.

The freeze frame feature sounds a nice idea. getting the star exactly on the slit PHD can be frustrating when guiding on field stars (when guiding on the slit I use a workround which allows the guide position to be fixed by clicking on the illuminated slit before starting guiding which hopefully will still work in PHD2)

 Perhaps even better would be the ability to couple a "guide where I click, not where the star is" feature with a "nudge" feature (at sub pixel steps) for the guide position. This would allow the star to be moved exactly onto the slit under guider control and held there. Add these and a guiding algorithm which can take care of the split star image to PHD and it would be a winner.

 I am currently using CCDOPS for guiding. It came free with the ST-i
camera I am using for guiding. It has the "guide where I click" and it
has a "nudge" feature although I do not know if it is at the sub pixel
level. I haven't tried the latter feature, yet, and so I don't know how
well it works.

Would the development group be prepared to assist in implementing these types of enhancements??

[Andy Galasso]

Hi,

Just wanted to make sure I understand your requirements before I add an enhancement request into the issue tracker.

1. "guide where I click" . In PHD2 we call the position where we want the star to stay put the "lock position".  Although it's a poor substitute, currently you can set the lock position by selecting Enter Manual Lock Position on the Tools menu. This can be combined with Sticky Lock Position to give the behavior you want.  That said, it would be relatively straightforward to add the ability to set the lock position by clicking.

2. nudge.  I think that is already covered by Manual Guide on the Tools menu. You can even specify the size of the nudge.

3. scalable, movable crosshair (like Al's Reticle). We do not exactly have that, but we do have bookmarks. Does that work for you?

4. guide on a dumbbell-shaped star.  That's the most tricky one. We would need to modify the star finder code. Could you post some sample images somewhere?

You also mentioned something about subframes vs full frames. PHD2 supports both. You can start with full frames to pick your guide star then switch to subframes for faster downloads and lower latency guiding.

Does that cover everything?

Andy Galasso

[robin.le...@gmail.com]

Hi Andy,

I have been using PHD for spectroscopy for many years. Your feedback sounds promising. A few comments;-

Unless I misunderstand, the manual nudge feature just nudges the mount rather than the lock position doesn't it?  What we would be looking for is to be able to nudge the lock position (a fraction of a pixel at a time if possible) to place it exactly on the centre of a slit which might only be 3-4 pixels wide

There is a good example of the appearance of the star on the slit in the video on Christian Buil's website

http://www.astrosurf.com/aras/slit/fente3.wmv

from this page

http://www.astrosurf.com/aras/slit/method.htm

(In French but it is worthwhile eg getting Google to translate as it talks about on slit guiding)  

Also the bookmark function sounds useful, particularly if there was a way of setting the lock position to the bookmark  (effectively "guide where I click")

Cheers

Robin

www.threehillsobservatory.co.uk

[Andy Galasso]

On Saturday, January 18, 2014 10:45:34 AM UTC-5, robin.le...@gmail.com wrote:

Unless I misunderstand, the manual nudge feature just nudges the mount rather than the lock position doesn't it?  What we would be looking for is to be able to nudge the lock position (a fraction of a pixel at a time if possible) to place it exactly on the centre of a slit which might only be 3-4 pixels wide

Ok, thanks for the clarification.

[kenm.h...@gmail.com]

Andy,

Robin is highlighting the issue of establishing EXACTLY where the centre of the slit gap (nominally only 19-30 micron = 3 pixel or so) in the guider FOV.

Once this slit position is established ( a little trial and error based on the disappearing target star....) then the next challenge is to be able to position the target star EXACTLY onto this slit X-Y position and establish guiding without any positional loss.

The ability to nudge the "slit position" and then the "target star" to get them coincident is what it's all about.

Once the target star is sitting on the slit gap there will probably still (we hope!) "wings" of light to guide on. ( Think about a circular disk of light cut through by a wide opaque band - it leaves the edge segments visible - the "wings")

It may be possible to consider each wing as a separate star image - two star guiding trick!?

The amateur spectroscopy community appreciates your time and the teams efforts in enhancing PHD, and understand our needs are different. But just think about it if PHD2(spec) became the "weapon of choice" for all spectroscope guiding!!

 

[kenm.h...@gmail.com]

Guys,

Is there any other info we can supply in support of an "enhancement" to provide effective slit guiding?

[Andy Galasso]

Hi Ken,

I entered two items into our issue tracker: Issue 248 for nudging the lock position, and Issue 249 for guiding on a dumbbell shaped star. Please let me know if I missed anything there in trying to capture the requirements.

Guiding on a dumbbell shaped star is technically by far the most challenging of the two issues. It will require a new version of the star finding algorithm. Given that none of the PHD developers has a spectroscope available, it is not likely that work will get done any time soon. If you can find a vendor or someone else willing to donate a spectroscope, that would make a huge difference to facilitate the work getting done.

Andy Galasso

[Somogyi Peter]

Hi,

I'm a programmer (C/C++ for 15 years) who is doing amateur spectroscopy with ~20 nights experience with locked position PHD2 guiding on faint star...
Is anybody improving starfind code these days?

If not, I would volunteer tweaking and testing the code:
   http://open-phd-guiding.googlecode.com/svn/trunk/star.cpp (Star::Find)

The improvements I could imagine:
- assume slit is (nearly) horizontal within searchRegion, then subtract a median of the row, only then do the thresholding
(note: a histogram-based one would be better than average-based)
- "dumbell-star": tweak the algorithm to search 2 peaks instead of 1. I suspect artifacts on actual code (= finding first absolute max), and experiencing oscillations... (maybe searchRegion being small affects the most... but when it's larger, very easy to misguide)
etc...
- have it an easy-to-develop plugin fashion (e.g. another plugin near the upcoming multistar guiding...)
- have the threshold hardcoded values (e.g. mass < 10.0, SNR<3) configurable

Note: I just downloaded Visual Studio Express, will take lot of free time to compile & run in "production".... so please CONFIRM that I can proceed with development without wasting efforts / avoiding double work, with a PROMISE it has a good chance goin in trunk.
Thanks.

[Andy Galasso]

Peter,    (is that your name?)

You are more than welcome to contribute. We have an open item in the issue tracker (#249) for adapting phd2 for spectroscopy. We generally avoid duplicating work by taking ownership of the issues we are working on. As you see there is nobody working on it, and you are welcome to take it.

As you get closer to a working implementation, feel free to share what you have, especially if you would like any feedback on how to integrate the adapted finder routine into the system or discuss ideas for the UI.

Andy

[Somogyi Peter]

Andy, sorry replied by accident in private mail (getting used to google interfaces...)

First want to get used to the build system, do some cross compile (of course not my dev system is outside - but that's 32 bit, using VNC to control everything).

I won't promise anything quick (freetime development), but the 1st solution assumes horizontal slit alignment (sorry, I'm not spending valuable nights to debug rotation artifacts....)

2 problems identified:
(1) star is easily lost for faint object, mainly due to background getting almost same lightness as field star... this is just because of wrong thresholding.
So a median of every row for 2-3x specified region must be subtracted (hope it works in many stars at f4 that I have...)
(2) double star: region can't be large (11 pixel in my case), otherwise easy to misguide (faint star = too many).
But then a few iteration needed to find the weighted center. (N=configurable?)
Maybe a slit pixel width information needed for the recenter algorithm (not sure at this moment: iterated recentering is straightforward.. actual doesn't seem to be iterated).
- have tunables (SNR=3, threshold 1/10, #iterations, ext. region to do the row median, ...) configurable

Ken or others may give an update on:
- any more sophisticated center find (comparing to an iterative region find) that's not too complicated to verify
- is an almost perfect horizontal alignment possible in practice? (sorry at this point I'd like to have something quickly)

Of course, some material of fine series of .fits files (with raw ADU values) of many possible positions would be appreciated, especially someone measuring the real centers.
(e.g. using shift of the other stars in field - comparing to a good centered case)

The very 1st version will be surely just a command line tool that tests the core starfind algorithm  on these example fits files (input: fits, guess center, search region; output: x, y), and nothing else.

Peter

[kenm.h...@gmail.com]

Peter,

Most of us orientate the slit gap either horizontal or vertically in the Guide camera view.

The common slit gaps used are around 20 - 30 micron (3-4 pixel).

The slit can be up to 6mm long, and we aim to position the star close to the centre.

With normal seeing the "target" slit gap should be about 80-90% of the target star FWHM....

At this setting you can see when the star drifts into the slit and you end up with a small halo at either side. I generally nudge the star a pixel or so to check that I'm getting maximum starlight through the slit gap to the spectroscope.....

If it were possible to determine the "centroid" based on shape and intensity of the halo on each side - if the halo brightens then the star has moved off the slit in that direction...

If you have any specific requirements let me know.

Ken

[Robin Leadbeater]

Hi Peter,

 

There are some videos on this page from Christian Buil’s website showing what the star on the slit typically looks like

http://www.astrosurf.com/aras/slit/method.htm

 

Cheers

Robin

--
You received this message because you are subscribed to a topic in the Google Groups "Open PHD Guiding" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/open-phd-guiding/rtns6q76BLI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to open-phd-guidi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Somogyi Peter]

Ken,

3 types of use cases racing in my mind here:
(1) the ability to guide faint stars [>12 mag] (to avoid manual errors of guiding on different star by misplacing it on slit; + do an accurate wavelength - if still possible)
(2) guide better mid faint stars [10-12mag in my case] (noisy halo, +few separate pixels have good SNR)
(3) guide better bright stars (large noiseless outer halo, + sec. mirror reflection?, kernel could have a cut at a high threshold)

For (1) and (2) the accurate thresholding needs here urgent fixing and the ability of tuning (noisy conditions).
In these cases, at f/4 the slit size is very much relevant and needs subtraction for me (hence the row median I suspect to correct it).
High precision thresholding is a must.

For (2) and (3), I can imagine tricky algorithms:
- like IsoLines in MetaGuide (already experienced it's less oscillating/overreacting), but maybe just have a good thresholding is enough for us
- do some edge detection and fix the noise, or other filtering
- eventually circle-shape approximation
etc...

After a really accurate thresholding is done (and cut to 0 everyhing below), for now I'd just continue with some parametric non-linear scaling (edge case: have 0 or 1 everything).
Other tricky algorithms may come later.

Peter

[Robin Leadbeater]

Note that losing lock with faint stars once on the slit is not a big issue as long as the program sits there waiting for it to re-emerge. (If there is no light for guiding, then it is going through the slit which is the aim of the guiding)  It may of course wander up and down the slit a bit in the meantime but this is not a big problem for spectroscopy. This does need a way of stopping PHD going off and latching onto some other adjacent star in the meantime though if the signal is lost on the slit. (perhaps you can already do this in PHD but I have not found the setting?)  I find this annoying currently when guiding on faint stars. 

 

Cheers

Robin

 

From: Somogyi Peter

Sent: Wednesday, November 19, 2014 1:36 PM

To: open-phd...@googlegroups.com

Subject: Re: Adapting PHD2 for slit spectroscope guiding??

 

[Somogyi Peter]

Robin,

Thanks for the hint, but in my case a 13 mag star won't reappear at 1 sec exposure or just below 10% chance (usually when too far away from the slit already).
But that means for other axis (Y-axis on spectrum) during that time PHD2 will never do any correction (experienced).
Result what I get then is that light gets scattered across 9-10 reappearing rows on detector instead of 1-2 pixels (with easy contamination of other stars). Not having to say, SNR is lost.

And also suspect by the star reappeared at 1 sec is too late with the actual PHD2 thresholding.
But maybe it's my own f/4 problem (background gets high).

The setting you need is somewhere in 2nd or 3rd tab, the star search region size.
I did have to reduce it to the minimum 11 pixels (at f/4 this happened to me at the very beginning...) which has other side effect (star gets lost much easier, at 1 sec 10% chance reappear it can show up very far...).

Cheers,
   Peter

[Somogyi Peter]

Progress:
- able to compile and run Debug version from trunk
- found a feature in Simulator camera playing every .fits files from within a special folder (when compiled with SIMMODE=1)
this means I can replay anyone else's saved .fits files (and flow through Star::Find algorithm) as if it would come from a cam. These can be saved simply by File->Save as... menu item, say 10-20 of them taken by 4-5 different instruments and uploaded somewhere would be useful.
(I've taken some examples on my own already. The wmv format is not useful because that's compressed and rescaled already for visible purposes only.)
- found an existing fast median algorithm in the code (histo_median) avoiding the qsort slowness, I've just put some wrapping around to make it easy to reuse

To avoid needless work, many params I'm planning to read only from a config file first. Then some dialog box (GUI) work will be necessary after having seen my approach is really working and better than original.
I also foresee the need for having the threshold leveling lines somehow visible, to have a feedback for average user whether params are optimal, but that looks much more work.

These parameters I imagine right now (may change):
- an inner search region (besides the outer existing searchRegion that would be used then for thresholding, or vice versa)
I'm thinking to have the inner region as a circle (or an ellipse: Lodestar X2) and not like a box (field stars on edge...) maybe for next version.
- nIter# to recenter within outer region when seeking the middle
- low (negative) threshold percentage % (to eliminate slit), % is given by occurence (not by the median value)
- mid threshold % (to reject above), nIter (iteration for rejecting high values, reapplying that threshold)
- thinking either a high threshold % (to cut high a mid/outer halo - maybe useless for low light) or a rescaling function (something like 1-1/x) as I guess these should be experimented for a given config
- switch on/off the elevating slit feature (I still see it useful for low light: slit direction position is still visible for me), but I admit hard to make it stable that does what I want

And maybe (if comes out really needed), it might be useful to have a flat... because my reflective area is full of defects (lots of areas missing full polish, not just dust) and working with star halos close to background makes it relevant.
While I like to shift the star on the slit to a fix position having no hotpixels on detector...

That's so far... please be patient, lot to work, 1st I'd just like to see how these ideas work.

Peter

[Somogyi Peter]

Progress in a few words: see attached picture.
(bluish are rejected pixels, yellowish are maxed to high threshold)

Replaying the first working algorithm on saved stars for both normal and faint case, does just what I expected.

[as...@kor.cotse.net]

Cool, Peter! 

Are you using the "Enable Slit" to switch from the OneStarGuider class to your custom class, or did you do it some other way?

I am working on multi-star guiding and have added a PolyStarGuider class.  If your "Star" tab ends up being the way you are selecting your guider class, perhaps I can just add a "Enable Muli-Star" (and maybe a couple of other parameters) to it.

[Andy Galasso]

Seeing as we already have star-related parameters on the guiding tab (star mass), it seems a bit overkill to add a whole new tab for "Star" with a single checkbox. Do you envision lots of star-related parameters for spectroscopic slit guiding? If not, perhaps move the checkbox to the Guiding tab and call it something like "Spectroscopic slit star detection" (non spectroscopy folks are unlikely to understand what "enable slit" means.) If you do envision lots of parameters (I hope not), then the tab should probably be called "Spectroscopy" or something like that.

Andy

[Somogyi Peter]

Hi "Astro" (sorry couldn't find your name - maybe my lack of googe knowledge),

I just quick prototyped the checkbox in my dev system (code-copypaste), I will remove that when you define a choose-list somewhere: "star, multistar, spectroscopy".
(Until that, I'm going to come up with my own patch - will send in public as soon as I have something final - doing it the shortest way.)

No I haven't defined yet any new class, just extended the Star:: by another method in the code.
We can polish implementation details later when I have something final.

Peter

[Somogyi Peter]

Andy,

Thank you for the feedback, was expecting these concerns.

I will have 4-5 params +1 profile choice (very bringht - normal - faint - ...) to easily switch between their combinations.
These params will be:
- background threshold% to cut off (using outer box)
- star profile low threshold (within elliptic region)
- star profile high threshold (within elliptic region)
- recenter iteration
- ellipse a, b (indeed it would be the search region, I'd need the big box-shaped outer one only for background detection)
(The reason it is ellipse is for having its histogram realistic, +less chance to include unwanted field stars - which has a high potential.)

Please note I also created a new window "Threshold View" (see on the image in prev. mail) - I guess this should be renamed to "Spectrocopic View".

The reason for having a separate tab is:
- keep this code separate (at GUI part too) as much as possible
- keep normal users away from seeing these params at all (should be greyed, or the whole may tab vanish when not in spectroscopic mode I think) - I understand new people coming in using PHD2 is to have it simple for the 1st few nights...
- much of the params (actually values yet hardcoded  / read from registry)

My idea is for having so many types of slit star profile view that every (we can assume advanced) users tune these params for themselves.
(Would be nice for this to enable .fits replay feature of the simulator camera for normal users too, but that's not my code, in order to save people from spending valuable observing time for just tuning these params combo. I'm serious, playing with them really need relaxed time and some understanding... The "Threshold View" that I implemented now gives the basic feedback for that.)

Please note I don't have yet any evidence that this feature set is benefical, it's yet still a theory (I will need a clear night).

Peter

[Somogyi Peter]

Andy,

Thank you for the feedback, was expecting these concerns.

I will have 4-5 params +1 profile choice (very bringht - normal - faint - ...) to easily switch between their combinations.
These params will be:
- background threshold% to cut off (using outer box)
- star profile low threshold (within elliptic region)
- star profile high threshold (within elliptic region)
- recenter iteration
- ellipse a, b (indeed it would be the search region, I'd need the big box-shaped outer one only for background detection)
(The reason it is ellipse is for having its histogram realistic, +less chance to include unwanted field stars - which has a high potential.)

Please note I also created a new window "Threshold View" (see on the image in prev. mail) - I guess this should be renamed to "Spectrocopic View".

The reason for having a separate tab is:
- keep this code separate (at GUI part too) as much as possible
- keep normal users away from seeing these params at all (should be greyed, or the whole may tab vanish when not in spectroscopic mode I think) - I understand new people coming in using PHD2 is to have it simple for the 1st few nights...
- much of the params (actually values yet hardcoded  / read from registry)

My idea is for having so many types of slit star profile view that every (we can assume advanced) users tune these params for themselves.
(Would be nice for this to enable .fits replay feature of the simulator camera for normal users too, but that's not my code, in order to save people from spending valuable observing time for just tuning these params combo. I'm serious, playing with them really need relaxed time and some understanding... The "Threshold View" that I implemented now gives the basic feedback for that.)

Please note I don't have yet any evidence that this feature set is benefical, it's yet still a theory (I will need a clear night).

Peter

2014. december 2., kedd 4:09:46 UTC+1 időpontban Andy Galasso a következőt írta:

[Somogyi Peter]

[re-send 3rd to Andy, maybe answering to myself won't vanish in public - spam filer??]

[Somogyi Peter]

Update: yesterday I've tried thresholding with several params, using oval mask with recenter, but gave not any better result than the original, or sometimes got even worse.
(+ tried some other own ad-hoc algorithms with no benefit)

Possibilities:
- I was unable to determine the accurate lock position, it was somewhere within +/- 0.15 pixel (8.3 micron in case of my Lodestar X2)
- tweaked the focus of Alpy 600 before experiments (spectral line to be the narrowest on the detector ccd), but I know the guide cam Lodestar X2 was a bit out of focus (= I didn't see any double star, or just very rarely)
- found that the driver I was using with the X2 (sxvr - offering no setup params) was possibly doing some filtration.... I realized with the other driver that raw data has *interline* readout features which certainly cause artifacts on Y-axis, the slit on that raw saved fits view was a mess...
It becomes obvious only when you uncheck all checkboxes for "Starlight Xpress Lodestar Guider (ASCOM)" and you "Save..." as fits - no other way to see this raw interline/interlace readout effect.

As a consequence, I must change the X2 setup to have the slit vertical. (actual is horizontal) because the interline effect.
I am also planning next to have a view showing {mass, distance from slit} 2D graph, to be able to estimate the lowest mass position on a longer run much better.

The only good news is that oval masking works for closing out field stars / reflected image + works better on very faint stars - however it's too few yet to speak about approaching PHD2 with any code commit.
Now I'm waiting for the next occasion + free time to test these findings (+few weeks), volunteers could speed up these tests.

[Somogyi Peter]

Developed a realtime (y: d, x: mass) diagram - where d is distance from slit, replaying last night 30 .fits is speaking.
See attachment.
This means slit position was inaccurate.
Waiting for next clear sky.

[Somogyi Peter]

Experimented further with:
- original algorithm, but use same visualization
- have just background threshold applied correctly
- experimental function on distance using the lock position when it's is known accurately ('gravity') that reduces oscillations a lot and looks like working... still optimizing it
See attachments.
This diagram is also sensitive to noise, which is more present above 10 mag.
No explicit proof yet which is method working better (that needs much preparations and a lot of real sky), just captured graphs and noticed I have flexture of 0.1-0.2 pixels sometimes.
At least the d-mass realtime graph is already something I couldn't live without.
Further tries planned.