-
Notifications
You must be signed in to change notification settings - Fork 172
Depth loss #7
Comments
Thanks I will try to make an update sometime next week. |
Hi @ozansener @SimonVandenhende , The disparity data read from the Cityscapes dataset needs to be first processed to be converted to depth:
however, I cannot find this step anywhere in the code? And in this issue (#2 (comment)) it seems the depth is the metric output by the code? |
Hi @ozansener , I just found that in the table of the paper you reported "1 / Disparity_Error", so is it Disparity instead of Depth that you are reporting? I found that the numbers in your paper(Disparity Error before using 1 to divide it) very different from those reported by Kendall et al(http://openaccess.thecvf.com/content_cvpr_2018/papers/Kendall_Multi-Task_Learning_Using_CVPR_2018_paper.pdf) |
If I remember correctly, the disparity error is reported, and not the absolute depth. |
We are reporting disparity in the pixel space after normalization. I know it is not a standard metric and has no real practical meaning especially since it is normalized, but all algorithms are reported similarly. You can look at the disparity error in Table 4. Since this is L1 distance, you can convert all of them to the depth L1 error with the formula you posted. You also need to multiply with the DEPTH_STD value in the code to get metric depth error. The original issue (masking bug) still exists. This bug-fix is unfortunately getting continuously delayed. I have no ETA for it at the moment. But, you can contact me if this bug is impacting you in some-way. |
Thanks for the clarification! |
There is a bug in the depth loss.
All entries smaller than zero are masked. This causes most of the entries to be excluded in the loss, as the depth map has been normalized. The correct way would be to mask only the zero entries in the loss.
The text was updated successfully, but these errors were encountered: