-
-
Notifications
You must be signed in to change notification settings - Fork 573
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow setting spherical screen radius #7532
base: main
Are you sure you want to change the base?
Conversation
I think the planar screen wouldn't help, since it also (as implemented there) passes through the Sun, and my WISPR FOV goes from ~10 to 110 degrees of helioprojective longitude. So either the plane would be far away in the near-the-Sun side of the FOV but never actually touch the lines of sight on the far-from-the-Sun side, or it would be far away on the far-from-the-Sun side but much too close on the near-the-Sun side. Though that got me thinking more, and I can get a screen at infinity without this PR by placing the "observer" location (the sphere center) lightyears away and in the right position so that the sphere passes through the Sun, right behind PSP, and then out to infinity:
So I can fudge it without this PR, though it's not quite as clean as just having a really big sphere centered on my actual observer. |
Sorry this has been tied up for so long @svank. We would really like to have this in v6.0. |
With Helioprojective frames, you can use
assume_spherical_screen
to transform coordinates into another frame. The screen's center is configurable, but the radius is always such that the screen passes through the Sun. That's usually the right choice, but a user (i.e. me) might want to change the radius of the screen (with it then not passing through the Sun). This PR allows that. Delightfully, the spherical screen part ofHelioprojective.make_3d
is written in full generality, so all that's needed is an argument toassume_spherical_screen
allowing a radius to be passed in.It looks like there weren't any tests for
assume_spherical_screen
(though there was coverage through examples in the docs), so I added a one and exercise this option.My use case here is making videos with WISPR on PSP, which involves compositing two images from the two imagers, which are taken at slightly different times and locations. It's a wide FOV that doesn't include the Sun, but the FOV is ~fixed in helioprojective coordinates. A spherical screen passing through the Sun starts to be uncomfortably close to PSP (perihelia near 10 R_sun, while traveling ~10 R_sun/day). Projecting the images onto that kinda-close screen to composite them adds a bit of jittery parallax for the stars, which makes videos look a bit jumpy. As an experiment, I'm instead projecting onto a screen at infinity, which has the stars move very smoothly and evenly through the FOV---in trade, the coronal structures should have a bit of parallax, but since they're large, diffuse, and evolving, it's less noticeable. (My only goal in this is pretty videos.)