Variable initial-dem-constraint-weight

[mkbarker]

Hello,

Is it possible to have a variable initial-dem-constraint-weight for sfs? Some pixels of the initial dem may be known better than others. It seems like it could be useful to "anchor" (though not necessarily fix) sfs at those pixels while allowing it more freedom in between. The user could provide a map of initial-dem-constraint-weight.

Thanks,
Mike

[oleg-alexandrov]

Hello Mike, First, thanks for the very nice LOLA maps you make. We've been using them a lot and they are a real improvement. I am a bit reluctant to add the option of this weight to be a matrix (weight map), as I am not sure there is a good use case. This weight is usually very low, and it is assumed that one starts close to the final DEM anyway, and SfS at most provides a refinement, and the cost function should be dominated by the intensity term. Likely a wide range of this weight should do the job, or else, if the solution refuses to behave unless this term is manipulated a lot, then maybe there's something else which is problematic. So I'd need a bit of persuasion that there are scenarios used for real work where this is thought to make a difference. Implementation-wise, this is rather tractable. Oleg

…

On Tue, Apr 4, 2023 at 5:39 PM mkbarker ***@***.***> wrote: Hello, Is it possible to have a variable initial-dem-constraint-weight for sfs? Some pixels of the initial dem may be known better than others. It seems like it could be useful to "anchor" (though not necessarily fix) sfs at those pixels while allowing it more freedom in between. The user could provide a map of initial-dem-constraint-weight. Thanks, Mike — Reply to this email directly, view it on GitHub <#394>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKDU3BRLH4IMZ44VZCVZ2DW7S5KXANCNFSM6AAAAAAWTMWHIQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mkbarker]

Hi Oleg,

I'm glad the new LOLA maps have been useful. It has certainly been a primary motivation in making them to feed into ASP (which we are big fans of, so thank you for all your hard work!). Actually, it is those maps that motivated my question. The height values of filled pixels (those with LOLA spots in them) are known very well, much better than those of interpolated pixels in large gaps. Currently, the uniform weighting treats them all equally, but the uncertainty of the interpolated pixels increases the farther they are from the filled pixels. Therefore, it seems that, ideally, sfs should follow the filled pixels more closely. We were wondering if sfs could be made to account for this by allowing the user to input a map of weights. I am not sure how this would affect the sfs solution; perhaps it would introduce some instability or artifacts. Anyway, this could apply more generally to any lidar-based DEM.

Mike

[oleg-alexandrov]

Mike, Thank you for the clarifications. I understand that the LOLA-based product is infilled, so some heights are known with much higher certainty than others. In theory, yes, any product that uses the LOLA DEM as initial guess must use the uncertainty at each DEM pixel as an input. So, the constraint that SfS uses, to tie the SfS DEM to the initial LOLA DEM should incorporate that knowledge. In practice, SfS is able to handle very noisy LOLA DEMs and even spikes (which you thankfully remove). SfS wipes those if found. In fact, SfS orks with no problem without that initial DEM constraint altogether, because the SfS solution is doing the minimum necessary local work to adjust its heights to better reflect the input image intensities. So, it kind of constraints itself anyway (which can be both a good and a bad thing). So, SfS is driven by the input images, and not by the DEM and stays close to that DEM. In fact, it handles quite well the fact that some areas can be covered by, say, 20 images, while some by only 1, and the coverage is very haphazard as it depends on how lucky one is with image acquisition in various areas of a given large site. It shows degradation only when the illumination is poor, and it does better with images with orthogonal illuminations than when all input images provide the same info. Before adding this per-pixel weight for a DEM, which I know you produce, I'd have to have some confidence it is actually useful, and have some understanding into how the input DEM weight (whether variable or not) affects the final solution, and I think the effect will be negligible. That way I could write in the documentation at least some heuristic as to what is advisable. Hopefully I'll get to it at some point, then I will also study how the uncertainty maps you make affect the result, and what multiplier should those be used with. Oleg

…

On Fri, Apr 7, 2023 at 5:05 AM mkbarker ***@***.***> wrote: Hi Oleg, I'm glad the new LOLA maps have been useful. It has certainly been a primary motivation in making them to feed into ASP (which we are big fans of, so thank you for all your hard work!). Actually, it is those maps that motivated my question. The height values of filled pixels (those with LOLA spots in them) are known very well, much better than those of interpolated pixels in large gaps. Currently, the uniform weighting treats them all equally, but the uncertainty of the interpolated pixels increases the farther they are from the filled pixels. Therefore, it seems that, ideally, sfs should follow the filled pixels more closely. We were wondering if sfs could be made to account for this by allowing the user to input a map of weights. I am not sure how this would affect the sfs solution; perhaps it would introduce some instability or artifacts. Anyway, this could apply more generally to any lidar-based DEM. Mike — Reply to this email directly, view it on GitHub <#394 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKDU3HYGGQAF5H76LTIBD3W777HNANCNFSM6AAAAAAWTMWHIQ> . You are receiving this because you commented.Message ID: <NeoGeographyToolkit/StereoPipeline/repo-discussions/394/comments/5552945@ github.com>

[mkbarker]

OK, thank you very much for your time and attention. Even if it makes no difference, that would still be useful to know.