[1] Fixing the bug when reduction = 1 by redefining reduction_pyramid:
When you set reduction = 1, you will see that the published image has wrongly scaled marker position.
This is due to the division by "reduction" which should have been the division by 2.
So that's why the algorithm gives still good output as long as reduction = 2. But as soon as this is not the case, the published image is wrong.
To solve this, I redefined reduction_pyramid from being
[2^pl, 2^(pl-1), ..., 2] where pl = pyramid_levels
to
[2^(pl-1), 2^(pl-2), ..., 0]
and changed the relevant parts in SemiDenseTracking.cpp ()
[2] Slightly better visualization for the published image;
Right now the marker color looks just red. I edited it a little bit so that low-error pixels look green, and high-error pixels (mostly occlusion) look pink. Not a critical change.
[3] Commented out the unused part in "compute_error_ic" function
The second bilinear interpolation inside "compute_error_ic" is performed without being used in any way. I commented it out to avoid unnecessary computation (didn't delete it just in case.)
[4] Very minor cleanup
[5] Minor cleanup in join_maps function (removing redundancies)
[6] Fixed a huge mistake in "active_matching" in DenseMapping.cpp
[7] As a result of the previous hotfix, somehow retuning of superpixel parameters were necessary... This still needs further investigation.
[8]~[10] @alejocb After some investigation, the problem with the worsened Dense Mapping after the bug fix ([6] 79c893a) was because we cannot retrieve the correct "sizeof(superpixels_index)" inside the "active_matching" function because we're passing the address of superpixels_index. So changing it to "sizeof(superpixels_index)/sizeof(superpixels_index[0])" solved the invalid memory access issue, but it still gave the wrong value because of this. (it gave 2 instead of 5). Anyways, a665db5 really fixed this issue, and the mapping results are the same with the identical parameters in data.yml.
Please let me know if there is anything you don't agree with in my pull request.
[1] Fixing the bug when reduction = 1 by redefining reduction_pyramid:
When you set reduction = 1, you will see that the published image has wrongly scaled marker position. This is due to the division by "reduction" which should have been the division by 2. So that's why the algorithm gives still good output as long as reduction = 2. But as soon as this is not the case, the published image is wrong.
To solve this, I redefined reduction_pyramid from being
[2^pl, 2^(pl-1), ..., 2] where pl = pyramid_levelsto[2^(pl-1), 2^(pl-2), ..., 0]and changed the relevant parts in SemiDenseTracking.cpp ()[2] Slightly better visualization for the published image;
Right now the marker color looks just red. I edited it a little bit so that low-error pixels look green, and high-error pixels (mostly occlusion) look pink. Not a critical change.
[3] Commented out the unused part in "compute_error_ic" function
The second bilinear interpolation inside "compute_error_ic" is performed without being used in any way. I commented it out to avoid unnecessary computation (didn't delete it just in case.)
[4] Very minor cleanup [5] Minor cleanup in join_maps function (removing redundancies) [6] Fixed a huge mistake in "active_matching" in DenseMapping.cpp [7] As a result of the previous hotfix, somehow retuning of superpixel parameters were necessary... This still needs further investigation.
[8]~[10] @alejocb After some investigation, the problem with the worsened Dense Mapping after the bug fix ([6] 79c893a) was because we cannot retrieve the correct "sizeof(superpixels_index)" inside the "active_matching" function because we're passing the address of superpixels_index. So changing it to "sizeof(superpixels_index)/sizeof(superpixels_index[0])" solved the invalid memory access issue, but it still gave the wrong value because of this. (it gave 2 instead of 5). Anyways, a665db5 really fixed this issue, and the mapping results are the same with the identical parameters in data.yml.
Please let me know if there is anything you don't agree with in my pull request.