New version with comparision with Dijkstra3D - fixes #1

[ReubenDo]

New version using the following path length definition:

Includes comparison with forked version of dijkstra3d

[masadcv]

New version using the following path length definition:

Thank you for correcting the equation and for implementing a nice comparison method!!

One question regarding the equation: Is there a reason for keeping \lambda separate for the two terms? I prefer using a single \lambda and doing (1-\lambda) for the second term - this is in favour of keeping equation simpler and having one less hyper parameter to worry about. And we can still have purely euclidean or gradient or a linear combination of both. If this sounds good, then perhaps this equation can be updated to the following (unless if I am missing something important here):

Apart from this, all looks good to me.

[ReubenDo]

Hi,

I agree that we could technically get rid of one parameter.

The main reason why I proposed to use two hyper-parameters instead of one is that for me the two parameters should be adapted for each new image based on different policies for l_grad and l_eucl.

For example, l_grad could be determined with a policy based on the image gradient (e.g., max, mean), while l_eucl could be determined using the size of the image, spacing etc. I agree that we could still rewrite the problem with one hyper-parameter but I just think that it's more likely that the two parameters are adapted independently.

[masadcv]

Hi @ReubenDo ,

I am not sure if I properly understand the use case for that. What would be the range of l_grad, l_euc in that case? Isnt the aim of lambda to be used as "mixing" parameter which defines a linear combination of both? I dont know if I understand the case where these are independently weighing in the contributions.

[ReubenDo]

There is no natural link between the two quantities, one is in mm while the second one is an image intensity difference. Given that images in a dataset may have different intensity distributions (due to different scanners, sequences, etc) and different image spacing, I think that the weighting process should be image-specific.

If the weighting process is image-specific, what could be a typical weighting policy per image? I would think that this weighting strategy should be for each quantity, as done here. Of course we can imagine many policies, but I think that most of them would try to "scale" each quantity.

[masadcv]

Thanks for sharing the paper and further insights, it is an excellent use case. I skimmed through it and I believe you are referring to equation 2 with specific gamma parameters. It does feel appropriate for this equation to have separate scaling parameters as you are combining geodesic distance with network probabilities (hence scaling between 0 to 1).

(I did this quickly so I may be wrong on this) The image-specific case may still be addressable by a single lambda for mixing and an additional normalisation step to convert resulting image into probabilities. Lambda in this case would be:

Considering everything, I am happy to keep the separate lambdas as they allow your use case implementation to be straightforward. They can also be simplified into a single lambda through a simple python wrapper.