Visibility recentering for wgridder - #53
Conversation
| double nm1 = (tmp>=0) ? (-xsq-ysq)/(sqrt(tmp)+1) : -sqrt(-tmp)-1; | ||
| double phs = w*(nm1+nshift); | ||
| // re-centering | ||
| phs += bl.r_l*x + bl.r_m*y; |
There was a problem hiding this comment.
The shift applies to n, not n*w (it is especially 0 at w=0!).
There was a problem hiding this comment.
| phs += bl.r_l*x + bl.r_m*y; | |
| nm1 += bl.r_l*x + bl.r_m*y; | |
| double phs = w*(nm1+nshift); |
| if (tmp>=0) | ||
| { | ||
| // accurate form of sqrt(1-xsq-ysq)-1 for nm1 close to zero | ||
| auto nm1 = (-xsq-ysq)/(sqrt(tmp)+1); |
There was a problem hiding this comment.
You will need to apply the transformation with grid correction as well
| nm1 += bl.r_l*(x0+i*pixsize_x) + bl.r_m*(y0+j*pixsize_y); |
| if (divide_by_n) | ||
| fct /= nm1+1; | ||
| } | ||
| else // beyond the horizon, don't really know what to do here |
There was a problem hiding this comment.
NB - this actually makes figuring out what to do beyond the horizon harder, at least for my code. The reason is that I'm only checking the four corners, and when "extending" n like this beyond the horizon (which I think is generally a good idea to prevent "jumps"), there's situations where the re-centering "overpowers" the extension so that the maximum or minimum happens right at the horizon line instead of the image corners, causing the grid correction function to go out of its useful range at those points, tanking accuracy.
Not entirely sure whether that would happen here, just be warned that this is one of the small gotchas of the optimisation.
There was a problem hiding this comment.
Thank you very much for having a look at this! I'll try to apply the changes as soon as I get a chance.
Yes, I can imagine that this will make the "over-the-horizon" mode even nastier, and I'm really glad to have got that working somehow in the current version. If I get the recentering to work in the more normal scenarios, I'll already be very happy, and whenever I detect n dropping below 0, I'll just disable the optimization until there is an implementation I'm really confident in.
There was a problem hiding this comment.
Just to be clear - I think you are relatively immune to the particular problem I ran into because you check every pixel in the image when determining nm1min/nm1max. Arguably I am just getting bitten by my own attempt to micro-optimise this by only checking the corners. It is just really tempting because once you choose r_l and r_m as proposed you always end up with the maximum in the facet centre and the minima in the corners... except when the horizon is in the picture, which is a bit unsatisfying.
|
I applied your suggestions, but the unit tests are still unhappy when |
2 participants
No description provided.