Suggested tweaks/work-arounds to use `sfs` with an extended Sun?

[steo85it]

Hi!
The sfs function in ASP currently produces the "computed" intensities using a point-like Sun, which is ok in most cases.

Would you have a "suggested work-around" to use an extended Sun instead (e.g., assuming that I can provide a set of "Sun positions and fluxes" for each epoch/camera - or relative shifts from the point-like Sun position, with associated partial fluxes, to be used for all cameras)?

Would it be possible to associate multiple --sun-positions to the same camera, each with an associated flux?

Thank you for any suggestions!

[oleg-alexandrov]

Would it be possible to associate multiple --sun-positions to the same

camera, each with an associated flux? I am a little confused here. Each camera acquires a picture instantaneously, so the sun does not move. You can call the tool multiple times, each time providing one set of cameras, and one set of Sun positions, one per camera. I know that there is something called ShadowCam that produces an integrated photo with different pixels coming from different Sun positions at different times, but that would be hard to model.

…

On Sat, Aug 23, 2025, 3:58 AM Stefano Bertone ***@***.***> wrote: *steo85it* created an issue (NeoGeographyToolkit/StereoPipeline#463) <#463> Hi! The sfs function in ASP currently produces the "computed" intensities using a point-like Sun, which is ok in most cases. Would you have a "suggested work-around" to use an extended Sun instead (e.g., assuming that I can provide a set of "Sun positions and fluxes" for each epoch/camera - or relative shifts from the point-like Sun position, with associated partial fluxes, to be used for all cameras)? Would it be possible to associate multiple --sun-positions to the same camera, each with an associated flux? Thank you for any suggestions! — Reply to this email directly, view it on GitHub <#463>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKDU3FSMNGILNHZPDMHVRL3O7DCTAVCNFSM6AAAAACETNI6GSVHI2DSMVQWIX3LMV43ASLTON2WKOZTGM2DOMRWHAZDKNQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[steo85it]

Hi Oleg,
I am not thinking about ShadowCam here (although that same feature would be useful for it, too), but rater about light-shadow transitions that are "binary/steep" in the modeled cameras (because of the point Sun) and smoother in the real images (because there are areas with partial flux, since the Sun disk is actually extended). The discrepancy (and consequent artifact slopes/ridges) are not too impactful at the Moon (even if it is results in artifacts here and there), but closer to the Sun (I am reprocessing some regions at Mercury) it becomes quite relevant.
I don't think calling the tool multiple times would help for this. One option we thought of would be to "manually correct" the "measured" flux in the input images. That would be easy to do on mapprojected images, but I am not familiar enough with ISIS to apply the correction to the cameras.

[oleg-alexandrov]

Ah, I see. On Mercury a giant sun disk would make a difference. Here on vacation, and even when back, this would require a notable change in modeling and interface, so I can't promise anything soon. But it looks like a worthy idea. Not sure how to slot this in. In the meantime, maybe producing several DEMs and merging them may work, not sure.

…

On Sun, Aug 24, 2025, 8:16 PM Stefano Bertone ***@***.***> wrote: *steo85it* left a comment (NeoGeographyToolkit/StereoPipeline#463) <#463 (comment)> Hi Oleg, I am not thinking about ShadowCam here (although that same feature would be useful for it, too), but rater about light-shadow transitions that are "binary/steep" in the modeled cameras (because of the point Sun) and smoother in the real images (because there are areas with partial flux, since the Sun disk is actually extended). The discrepancy (and consequent artifact slopes/ridges) are not too impactful at the Moon (even if it is results in artifacts here and there), but closer to the Sun (I am reprocessing some regions at Mercury) it becomes quite relevant. I don't think calling the tool multiple times would help for this. One option we thought of would be to "manually correct" the "measured" flux in the input images. That would be easy to do on mapprojected images, but I am not familiar enough with ISIS to apply the correction to the cameras. — Reply to this email directly, view it on GitHub <#463 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKDU3GCO5PKZDX3JF4KFUT3PH6OJAVCNFSM6AAAAACETNI6GSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMJYGI4DEMJWGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[steo85it]

Thanks! I might be able to produce several DEMs with different Sun positions and fluxes (say one for the center and one for the upper/lower limb of the Sun), then NaN out the respective regions where they are not relevant, then blend them? It sounds sketchy, but maybe worth a try (if I interpreted your suggestion correctly). ^^

If there is an easy way to map2cam modified mapprojected images within ASP (where one would correct for partial Sun visibility and limb darkening in some external soft), then use them for sfs, that would maybe be an "easy-ish" way without changing the modeling too much? I could give it a try using ISIS tools, I am just afraid of incompatibilities...

Else it would be great to be able to model those "multiple rays" in a clean way within sfs itself, but I can imagine that being a significant update to the code. Happy to discuss this further, but for now, please enjoy your vacation! :)