Speed up LinearIntensityMap8BitFilter

[tpietzsch]

No description provided.

[trautmane]

I'll defer to @minnerbe to review the details of your changes.

Minimally, it looks like the changes broke the AdjustBlockTest:

Let me know if you need any help debugging/fixing the test.

[tpietzsch]

I'll look into it later today.

My hunch is that it is because of a898ce7,
a minor bug/inaccuracy in the existing LinearIntensityMap that is not in the new code.
What would be our preferred approach in such cases? Preserve existing behaviour, or make it more accurate?

[minnerbe]

Iirc, I asked Preibisch the same question at some point, but the decision was deferred and ultimately the issue got lost in other work. I never fixed it myself because of the failing test and the missing decision. If it was up to me, I would just improve it, though (since it is clearly wrong the way it is now, although the error is not large in our applications).

[tpietzsch]

Ok, tests are fixed now.

The reason was not (at least not only) the a898ce7 inaccuracy:

• In LinearIntensityMap8BitFilter I did not to the coefficient scaling for the [0, 255] range. That fixed the testAdjustBlockTest.constantFilterMakesPixelsConstant

• Then remained a few off-by-one errors in AdjustBlockTest.filtersYieldSameResults. This is explained by slightly different order of float operations for interpolating coefficients between old and new code. This leads to minimal differences which can result in +/-1 difference when rounding the float to unsigned 8 bit. I also fixed this test, but maybe the fix is a bit cheating... I made a fast version of QuadraticIntensityMap8BitFilter that uses the same interpolation as the fast LinearIntensityMap8BitFilter. (I think that is okay, though. There is no reason to mimic the old interpolation such that numerical rounding errors go in exactly the same direction.)