PHD2 Dither method

[jkc...@yahoo.com]

There has been much discussion in a thread on Cloudy Nights about how PHD2 does dithering.   https://www.cloudynights.com/topic/752220-dithering-how-many-pixels/

The  assumption is that PHD2 does a "random walk" dither( the next random position is started from the last lock position as opposed to starting from a center position each time.

  

If the random walk assumption is correct, can you explain with this method was chosen.

 

 

Thank you

Jack

[Brian Valente]

Hi Jack

Looking at that thread, i want to point out that the original question regarding how much to dither etc. is a function of the imaging program, not PHD.

I think there's a misperception that PHD controls the dither. it does not. The imaging app controls the dither amount and then the settling criteria.

PHD does have some options for how the dither is done i.e., random or spiral, and RA only. These are covered in some detail in the PHD documentation https://openphdguiding.org/documentation/

The docs also include explanations of why you would want to choose certain dither patterns based on your mount's behavior. usually it's about DEC backlash.

But again, the amount of dither is controlled by the imaging app

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/e6e82eab-ce4d-46fc-a359-abb70085fad5n%40googlegroups.com.

--

Brian 

Brian Valente

portfolio brianvalentephotography.com 

[jkc...@yahoo.com]

Brian

I understand the amount of dither is controlled by the imaging program.

My question is specifically about PHD2 random dither and the method used for random dither.

Is it as I suggested a random walk where the next random point is determined by the last lock position?

If it is, I am just curious why this method was chosen.  I could well be the best method.

Thanks

Jack

[bw_msgboard]

Hi Jack.  To cut to the chase on your questions:

1)       A dither is accomplished by resetting the lock-point and then letting PHD2 move the guide star to that new lock-point.  

2)       The new lock-point is computed by adding the desired RA and Dec offsets to the current lock position.  If that would move the guide star out of the frame, a different dither vector is chosen.

3)       For the “random” mode of dithering, the RA and Dec offsets are computed using a pseudo-random number generator (rand in C++) bounded by whatever maximum range the imaging application has specified

4)       For spiral dithering, PHD2 resets the lock-point in order to create an expanding pattern of rectangular movements.  This involves keeping track of the last dither vector but not previous lock-points.

 

This approach was chosen because it is the clearest to understand and doesn’t require managing a history of previous lock-points or a need to know “the why” for a change in lock-point.  To explain further, I need to expand on Brian’s explanation that dithering falls in the domain of the imaging applications, not PHD2.  The role of PHD2 is to provide the necessary services for an imaging app to achieve its dithering goals with a minimum amount of extra programming work.  At the same time, we don’t want to restrict what an imaging app can do with respect to dithering.  Apps can currently reset the lock-point however they want, they don’t have to rely just on the dither command.  The same is true for an end-user who just wants to work in a simple scripting environment, you could dither/trace whatever weird pattern you want.  The reason we added the ‘spiral’ mode is that we could see it was commonly done in some of the automation apps and we could make it easier to do.  I haven’t looked at the Cloudy Nights thread, that’s a place I try to stay away from.  But if it’s a discussion of “best” dithering, I don’t know why it would have much to do with PHD2.  The “best” outcome for the end-user is going to depend on a bunch of things PHD2 doesn’t know about – the imaging goals, the physical properties of the main camera, the tolerance of the end-user for settling delays, backlash events, loss of data on the imaging margins – on and on…

 

I don’t think we would revisit how any of this is done unless we get specific requests from the imaging app clients along the lines of “this is what we need to do and we can’t do it or it’s too hard to do.”  So far, we haven’t heard any of that.

 

Cheers,

Bruce

 

---

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/5a354f54-9f67-4e23-9810-0e16139a61a8n%40googlegroups.com.