Open androst opened 3 years ago
I see what you mean, quite a serious bug, but I wonder why have we not seen this before then? Have we just worked with isotropic data until now?
I noticed it when the pixel spacing was significantly different between directions. Seems quite hard to spot otherwise, and perhaps most tasks have involved isotropic (or close to isotropic) data.
The cardiac task has a fix for this: https://github.com/smistad/annotationweb/blob/master/exporters/cardiac_segmentation_exporter.py#L180 But I think it might be better to draw in isotropic space, which is what the user saw, and then resample the segmentation to the original anistropic space afterwards. Otherwise the splines might not be drawn in the exact same way the user saw it.
Yep, agree! Also good that cardiac exporter has a fix for this.
I fixed this issue (see https://github.com/jpdefrutos/annotationweb/commit/13795d14bbb0993cb725ba488562449c7f8ca971). I can PR the solution. The fix included what you mentioned on the cardiac_segmentation_exporter, and also exposing the attribute 'Offset' on the MetaImage object to correctly align the segmentation and the image
Spline segmentation exporter does not work as intended (?).
When using anisotropic data the data is converted to isotropic for display, and the annotated points are saved in that space to the database. During spline segmentation export, the images are copied from disk (as anisotropic) and the segmentation mask is created with the anisotropic image shape while the point coordinates are isotropic. This will cause a shift that badly effects the segmentation mask.
Some potential solutions: