-
Notifications
You must be signed in to change notification settings - Fork 98
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
Distances on GT boundaries #8
Comments
The rationale, when I implemented it, was that we compute the distance to the boundary. By this logic, the distance of the boundary wrt the boundary should be 0. Since this not the behavior of the SciPy function distance_transform_edt. I did that manually by shifting the distance by 1 on the distance to the positive mask. To be fair, I do not think it would change (much) the results, since it is only shifting the distance values inside the object. But I did not had time to compare the impact of this implementation detail. |
Hi @maxmanko , would it be possible for you to share your keras implementation of surface loss? |
Hi, I have a question about the -1 shift here. If the distance of boundary wrt the boundary is 0, then the boundary would not contribute to loss and thus is not supervised. Will it affect the performance of small objects? |
Hello,
Now that you mention it, it could be a possiblity on very small objects (such as very thin blood vessels). In that case, it could be worth your time to compare the two; with and without that shift. But I think as long as you have an area with a negative distance map, you should be good. (That could actually be a new assertion to be included into the function ; that some negative area exists.) Best, Hoel |
Thank you for your loss function, it exceeded all my expectations. I applied it to solving the problem of pulmonary nodules segmentation, implementing this loss function in Keras framework.
You reset the distances for pixels that are on the edges of GT:
res [c] = distance (negmask) * negmask - (distance (posmask) - 1) * posmask
Thus, these pixels are not included in the loss function. Would it be better to take these pixels into account in the loss function?
res [c] = distance (negmask) * negmask - distance (posmask) * posmask
The text was updated successfully, but these errors were encountered: