bug fix for anisotropy data processing

[takashi310]

Fixed an issue in SparkAffineFusion where OverlappingViews.findOverlappingViews failed to find views when preserveAnisotropy was enabled and a non-1 anisotropyFactor was provided.

[cgoina]

@StephanPreibisch I think this may take care of the problem that I was also expperiencing when I created the ome-zarr container with '--preserveAnisotropy' and the fused result was all black. We need this fix too.

[takashi310]

I have merged my changes into the current code. This fixes the issue where using --preserveAnisotropy with an anisotropyFactor not equal to 1 caused the output to turn completely black.

[StephanPreibisch]

Thanks @takashi310 , I'll check it out Saturday morning!

[takashi310]

Thank you, Stephan.
I realized the fixed version wrongly duplicates the last channel. I am still investigating this issue.

[StephanPreibisch]

@takashi310 thanks for trying to solve this. You found the cause for the issue correctly, but the solution unfortunately went in the wrong direction. The key was to change

final OverlappingBlocks overlappingBlocks = OverlappingBlocks.find( dataLocal, overlappingViews, fusedBlock );
to
final OverlappingBlocks overlappingBlocks = OverlappingBlocks.find( dataLocal, registrations, overlappingViews, fusedBlock );

Just commenting this block actually fixed the problem - because it wrongly reported that nothing was to do because it used the transformations stored in the SpimData2 object, and not the ones updated with the anisotropyFactor. So what I did was to extend that method to support the updated registrations. And I used that opportunity to remove all convenience methods that do not explicitly take a HashMap< ViewId, AffineTransform3D >.

Thanks so much for looking into this @takashi310!