get_contour_fill_mask: truncating contour data

[clarkbab]

Hi there,

It seems perhaps that you're rounding the contour data too early in your code. The contour_data is changed to type 'int' here, before being converted to the pixel coordinates. I think you can just remove .astype(int) as it's converted to 'int32' further on.

This change can make a difference to the resulting mask, please see attached example where I forked the code and applied the change to the fork:

https://colab.research.google.com/drive/1anBcwIGgrGcPDbsyIDrNqgb0H9UZxJhC?usp=sharing

[asim-shrestha]

I forget why exactly we performed the conversion at that stage. Most likely we can just remove it but I'll bring this up with the rest of the team.

Would you mind attaching you result images directly in this issue just so that they are easier to reference?

[clarkbab]

Sure, here's a 'Parotid-Left' slice with the current codebase first, and the forked codebase second:

[clarkbab]

The other thing I would add, is that it might be an idea to round translated_contour_data before typecasting to avoid simply truncating floating point values.

[asim-shrestha]

@clarkbab I've testing the rounding change and it actually lead to some less accurate results within our basic mask accuracy tests like this one. In these tests we just compare the IOU over a new mask with that of the same mask just loaded from the RTStruct. What do you think?

[clarkbab]

@asim-shrestha is that the right link? Just took me to the original code we were discussing.

[clarkbab]

Not sure about your tests, but it seems the ITK library rounds the voxel index according to their docs.