Newbie seeking guidance floating albedo/estimating albedo using SfS

[Albert Kim]

Hello all,

I am a new user to ASP, and am attempting to generate an albedo map for a certain area on the moon, using the sfs tool. My general procedure is:

1. Generate initial low-res albedo map:
   sfs  --shadow-threshold 0.005 -i $dtm --reflectance-type 1 --estimate-exposure-haze-albedo --float-albedo -o $initial_estim_prefix --image-list $img_list --camera-list $img_list -n 1
2. Tile DTM and other things needed to correctly align images
3. Align images, for each tile (I have inspected this manually, and the alignment is nearly pixel-perfect. Assuming this is not the problem.)
4. Run sfs for each tile:
   sfs --float-albedo \
   -n 3 \
   --initial-dem-constraint-weight 0.01 \
   --smoothness-weight 0.04 \
   --crop-input-images \
   --reflectance-type 1 \
   --save-sparingly \
   --image-exposures-prefix $initial_estim_prefix \
   --input-albedo $initial_albedo_estim_tile \
   -i $dtm_tile \
   --image-list $sfs_img_list \
   --camera-list $sfs_cam_list \
   -o $sfs_prefix

However, the albedo map has quite extreme values, from around -0.05 to over 3. After inspecting, this problem seems to be inherited from the initial low-res albedo map (which has similar extreme values.) Thus, I have the following questions:

1. Is this behavior expected, and if not, what might be wrong with my method?
2. Is my understanding correct in that, when solving for albedo, it is just added as a parameter to the Ceres solver, and thus is affected by any error with the chosen reflectance model?

Best,

Albert

[Oleg Alexandrov]

Hello Albert,

Looks like your process is on track, with the mapprojected images being aligned to the underlying DEM and to each other. I hope that is true also before step 1, not just at step 3. Otherwise there will be issues later.

It is good to inspect if you see true albedo in the images, rather than variations due to lightning, and that the images have sufficiently different illumination for the albedo effect to be isolated.

It looks that the logic for estimating low-intensity albedo does not have any constraint on albedo. It worked well enough for me in the past, but I guess that may need changing.

For now, you can try avoiding the low-res albedo estimate step, and run sfs alone, on a tile that has notable albedo variation, without --input-albedo, but with --float-albedo. 

You should also try to use --albedo-constraint-weight. This is a bit hard to tune, but simply setting it to 1.0, for example, should at least drastically reduce the albedo range, if perhaps a little too much. Then, it can be reduced, maybe to 0.1.

Then, there is the --albedo-robust-threshold value, which I think should be set to maybe 0.25, given that we expect the albedo to be around 1.0, and any values that are more than 1.25 or less than 0.75 are likely excessive.

We did not study much the albedo for the Moon as at the South pole where we work it is illumination effect that dominates.

1. Is this behavior expected, and if not, what might be wrong with my method?

Hopefully the above clears this up somewhat. Let me know.

1. Is my understanding correct in that, when solving for albedo, it is just added as a parameter to the Ceres solver, and thus is affected by any error with the chosen reflectance model?

Yes. That is especially so when the low-res albedo computation is omitted, and the albedo gets solved for simultaneously with the reflectance and the terrain.

Also consider maybe increasing the smoothness weight from 0.04 to 0.08 at least to start with. The value of --initial-dem-constraint-weight 0.01 may be a little too high. 

But this is for later. For now we need to see if the albedo can be kept in check.

And to repeat, it is important to validate there is true albedo and there is enough difference in illumination, or else this won't work.

--
You received this message because you are subscribed to the Google Groups "Ames Stereo Pipeline Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ames-stereo-pipeline...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/3a096ae1-688d-4d7c-96cc-83119955b62cn%40googlegroups.com.

[Albert Kim]

Hello Oleg,

Thank you very much for your quick response. The images were misaligned (albeit, only slightly) prior to step 1; I will align them and try again and let you know my result. 

I forgot to mention, my area of focus is quite large, and no single image covers the entire area. (However, I made sure all areas were covered by at least 4 images of as varied illumination as I could find.) I am not familiar enough with ASP to know whether this is of significance, though.

I have previously tried floating albedo per-tile without --input-albedo as you mentioned, and (if I recall correctly) this yielded promising results, but when inspecting visually, each tile had slightly different 'brightness'. In other words, when I mosaic'd them together, tile borders were quite apparent as neighboring tiles tended to be slightly brighter or darker than their neighbors. This, I suspect, is an issue from different images covering different parts of the area.

I have also previously tried tuning --albedo-constraint-weight and --albedo-robust-threshold to little success, but this may well have been due to other issues with my method at the time. I will try this also, and let you know my results.

Thanks again,

Albert

[Oleg Alexandrov]

 The images were misaligned (albeit, only slightly) prior to step 1; I will align them and try again and let you know my result. 

Sounds good.

 

I forgot to mention, my area of focus is quite large, and no single image covers the entire area. (However, I made sure all areas were covered by at least 4 images of as varied illumination as I could find.) I am not familiar enough with ASP to know whether this is of significance, though.

I am guessing reliability will increase with the diversity. At least getting a decent result on some tile could be encouraging, then one can see what happens in other tiles.

 

I have previously tried floating albedo per-tile without --input-albedo as you mentioned, and (if I recall correctly) this yielded promising results, but when inspecting visually, each tile had slightly different 'brightness'. In other words, when I mosaic'd them together, tile borders were quite apparent as neighboring tiles tended to be slightly brighter or darker than their neighbors. This, I suspect, is an issue from different images covering different parts of the area.

Yeah, that's a problem, because the albedo is defined up to a multiplication factor. That's the reason the initial low-res albedo is needed, but for you it has some extreme areas. 

Maybe one can go back to that one low-res albedo, but with constraints on albedo as mentioned before.  So, it will then tie to the global low-res albedo, but will prevent it from moving so much towards it. Or, the low-res albedo could be preprocessed to remove some of its extremes. We have the image_calc tool for that.

I have also previously tried tuning --albedo-constraint-weight and --albedo-robust-threshold to little success, but this may well have been due to other issues with my method at the time. I will try this also, and let you know my results.

Sorry. Our approach is still somewhat sketchy with albedo modeling. Hopefully something semi-decent comes out. 

[Oleg Alexandrov]

I made the initial-low-resolution albedo estimation in SfS respect the options --albedo-constraint-weight and --albedo-robust-threshold. As I see it in testing, this prevents negative albedo. At some point need to have an option for albedo uncertainty, to guarantee it stays in desired bounds, so for now setting the weight requires some guesswork. 

This will be in tomorrow's build (https://github.com/NeoGeographyToolkit/StereoPipeline/releases).

As before, one should test these when there is a clear albedo signal and different-enough illumination.