Christopher Wilcox

@Eric Thanks for the suggestions! I'll work array size options in. The Zernike cell, I have kept because it can be useful to have this function return them to reconstruct the wavefront without having to calculate them a second time in another script. Mainly was just for me.
Also, thats a great suggestion for the non-square case, I hadn't really decided what to do about that case, but your suggestion sounds like a good idea.

Chris

I believe the julian date might be coming out wrong in this script. It appears to be 3 days off.

This is a very good function. Some comments:

1. The cell array "Zernike" seems unnecessary. The for loop on lines 51-54 can be wrapped into the later loop for i=1:M. This saves some memory and a for loop.

2. You should mention somewhere in the documentation that the Zernike polynomials are only calculated on a 256x256 grid, regardless of the size of the input wavefront. I understand this will speed calculations when larger wavefronts are decomposed, but some users may see errors associated with this. It might be worthwhile to have this as an option (i.e., calculate Zernike polynomials over the entire array when accuracy is critical or use the 256x256 option when speed is critical).

3. You might modify the function to more elegantly handle non-square wavefront data. You could pad the smaller dimensions with zeros to make it square, for instance. Or you could solve the equation using a different technique that does not impose this constraint. You may need to force the user to supply (x,y) position data for that to make sense.