Skip to content
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

homo_warping vs inverse_warping #22

Closed
TWang1017 opened this issue Nov 29, 2022 · 6 comments
Closed

homo_warping vs inverse_warping #22

TWang1017 opened this issue Nov 29, 2022 · 6 comments

Comments

@TWang1017
Copy link

TWang1017 commented Nov 29, 2022

Hi, thanks a lot for the amazing work. I am learning the MVS and would like to ask the difference between homo_warping and inverse_warping in your code.

I understand homo_warping warp the feature from a point in one camera to another using homography
H 𝑖 (𝑑) = 𝑑K 𝑖 T 𝑖 T 1 −1 K−1

Could you plz explain the inverse_warping a bit and the function of it in your code?

If the inverse_warping is just the reverse of homography from my understanding, in what situation you use the homo_warping and inverse_warping.

Thanks in advance.

@ToughStoneX
Copy link
Owner

ToughStoneX commented Nov 29, 2022 via email

@TWang1017
Copy link
Author

TWang1017 commented Dec 6, 2022

“Then we can implement the bilinear interpolation on the source view and map these pixels to the reference view based on aforementioned correspondence relationship: p_ref -- p_src.”

Hi, thanks a lot for the explanation. For the last statement, if I understand correctly: we firstly found the corresponding pixel coordinate p_src in source view, which is continuous and in float. But we want the integer coordinates on images. So, we use bilinear interpolation to find the integer coordinate by considering 4 corners on src view. Then the src view's integer coordinate's RGB information is warped into ref's view to synthesise a new ref image for photo loss cals?

The entire process includes 1. find the corresponding pixel coordinate p_src in source in float. 2. transform the float into integer using bilinear interpolation on src view and map the src integer coordinate's RGB on ref view to facilitate photo loss cals. Two steps combined are considered inverse warping?

Correct me if I am wrong and thanks a lot for your kind explanation.

@ToughStoneX
Copy link
Owner

ToughStoneX commented Dec 6, 2022 via email

@TWang1017
Copy link
Author

Hi, thanks a lot for your swift response and your reminder helps a lot.

One more thing, I train on the DTU dataset with augmentation and co-seg deactivated. The training loss looks like below, the SSIM loss dominates the standard unsupervised loss based on the default weight [12xself.reconstr_loss (photo_loss) + 6xself.ssim_loss + 0.05xself.smooth_loss]. In this case, is it sensible to change the weight, like reduce the 6xself.ssim_loss to 1xself.ssim_loss such that it is in the similar range with reconstr_loss?

Also, the training seems not steady, it fluctuates a lot. Any clues why this happens? Thanks in advance for your help.

image

@TWang1017
Copy link
Author

Yes, it is correct. There is one more thing to note, the mask of the synthesized ref image is indispensible. Ortherwise the self-supervised training may collapse. The reason is that only the common regions among different views are useful, which can be calculated during inverse warping. You may find that the output of the function _bilinear_sample has 2 variables: output, mask. The mask here is used to filter the invalid regions.

Sorry to bother you again. Just wanna confirm that the first step estimating the projected p_src coordinates and second step inversely warp the bilinear interpolated pixel's RGB information onto the ref view, both use the same equation you mentioned early. Just the first one cares coordinates and the second one warp the RGB information. They both employs the camera intrinsic and extrinsic matrix and estimated depth. Is it correct they both use the same principle and equation?

D_src (p_src) p_src = K_src T_src T_ref^{-1} K_ref^{-1} D_ref(p_ref) p_ref

Much appreciate your time. thanks

@ToughStoneX
Copy link
Owner

ToughStoneX commented Dec 7, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants