Open mdoube opened 4 years ago
EF2 does at least conceptually the same steps as EF1.
Foreach z slice, the line listed above:
final List<QuickEllipsoid> localEllipsoids = ellipsoids.stream()
.filter(e -> Math.abs(e.getCentre()[2] - z) < e.getSortedRadii()[2]).collect(toList);
keeps only a list of those ellipsoids are possibly relevant for this z slice. The ellipsoids are already sorted at this point, so the same idea of finding the first contains() is used. Contains() uses ~the same way of excluding unlikely ellipsoids, IIRC.
I think ways of improving this are therefore refactoring the code (different way of parallelisation) or coming up with new ideas to the concept?
keeps only a list of those ellipsoids are possibly relevant for this z slice.
OK. But it is not strict enough, limiting only to a bounding sphere (there is no guarantee that the longest axis is in z) and also needs to filter in y. See the axis aligned bounding box, which allows filtering in z and y.
Contains() uses ~the same way of excluding unlikely ellipsoids
I see that QuickEllipsoid
has the same contains()
method as EF1, but it seems not to be used.
Will have a look at the AABB when I can make some time - thanks.
QuickEllipsoid::contains used on line 506 of EllipsoidFactorWrapper.java
Describe the bug Ellipsoid image creation takes about twice as long in EF2 as in EF1
Expected behavior EF2 should be faster than EF1
Additional context Each foreground pixel has to be given the EF value of the maximal ellipsoid that contains it.
In EF1 that was achieved by limiting search scope aggressively:
contains()
hit was guaranteed to be the biggest, no need to search the rest.contains()
method was optimised to exclude unlikely ellipsoids cheaply and early in its executionEF2 does this: