Testing: Discrepancy in PyNutil /Nutil results (discrepancies in atlasmaps from QN/VN?).

[sharoncy]

@PolarBean Recording the results of testing, we can discuss more in person.

I've found discrepancies in "region_area" results from PyNutil and Nutil for nonlinear datasets, which I think originate from the atlasmaps (possibly a bug or methodological difference in QuickNII/VisuAlign... this needs more investigation).

• PyNutil has an in-build method for calculating "region_area" using the alignment.json.
• Nutil calculates the "region_area" using atlasmaps from QuickNII (linear) or VisuAlign (with nonlinear deformations).
• PyNutil and Nutil give identical "region_area" results for linear datasets.
• PyNutil and Nutil give different "region_area" results for nonlinear datasets.
• PyNutil results for nonlinear datasets do not match equivalent results for linear dataset (some deformation is happening).
• My testing suggests the atlasmaps from QuickNII and VisuAlign differ even with no nonlinear deformations applied. Nutil gives different results depending on the source of the atlasmaps. Is a different deformation method used in PyNutil and VisuAlign? This needs further investigation, I'm not sure if it's a bug in PyNutil or in VisuAlign (or something else).
• Conclusion: can use Nutil to validate PyNutil results for linear but not nonlinear datasets.

[PolarBean]

@Tevemadar any idea why atlasmaps might differ from QuickNII vs VisuAlign when no markers are applied?

[sharoncy]

A reminder to provide more info here @Tevemadar

[Tevemadar]

Differences presumably originate from rounding, limited numerical precision:

• VisuAlign always triangulates, even when there's only the original, linear alignment present, that's a rectangle and it gets cut into two triangles. That's one forward-backward transformation (into the Barycentric coordinate space of each triangle, and then back to image coordinates), that can introduce small differences, which then can be enough to round the result to a neighboring number compared to the original (say, original number was 1.49972, and then it somehow becomes 1.5001, the difference is 0.03%, yet the first number is rounded to 1, the second one is rounded to 2)
• There's the playground around the section, VisuAlign overlay has 10% extra space around the section which accepts control points for the deformation field, and when it's cut away, that's also a place where minor numerical differences are introduced.

[sharoncy]

@PolarBean @Tevemadar Recording the results of PyNutil testing.

I tested PyNutil for a nonlinear dataset using flat files. The results were identical to results achieved with Nutil using flat files. The discrepancy in "region_area" results from PyNutil (without flat files) and Nutil (with flat files) is likely related to the PyNutil calculations that replace reading from the flat files.

[sharoncy]

Recording the results of PyNutil testing

@PolarBean. I tested PyNutil by quantifying the background of the segmentations (instead of the objects) to test the "area_fraction" calculations. PyNutil counted 1 object and assigned it to one region only (despite it overlaying all of the regions in the section). This means it replicates Nutil with object_splitting switched "off". Have we implemented a method that replicates Nutil object_splitting switched "on"? This is where there is correct calculation of "area_fraction" for objects that overlap many regions (object pixels assigned to precise region for correct "area_fraction" calculation). This is a priority to implement as it is one of the most commonly used features in Nutil. Let's discuss tomorrow.