I added a parameter to the intensity matching process that allows to specify a different render scale for cross layer matches than for same layer matches. So far, the bottleneck were matches between tiles in the same position but on different layers, since they have a significantly larger overlap (the time was spent in outlier detection since there were a lot of matches).
extracted the formerly nested Matcher class into its own file and moved the average computation there as well;
removed unnecessary ImgLib2 calls (some RealInterval... for the bounding box of a tile and ListImage for the matching process).
For further clean up, we should probably think about making the actual rendering process into a class with state instead of a static Render.render method.
Verification
I tested the new parameter with 2 layers of c009_s310_v01_mfov_08 and --crossLayerRenderScale 0.02 (as opposed to the default scale 0.1). Here is a neuroglancer view of the two layers, which look good to me.
Improvement
At scale 0.1, matching two tiles that partially overlap takes about 150-300ms, while matching tiles that completely overlap takes roughly 1900ms. At scale 0.02, matching tiles that completely overlap only takes about 200-300ms.
This reduced the runtime from 9:38min (where matching took 6:45min) to 5:00min (where matching took 3:10min). The additional gain in runtime probably comes from the fact that there are fewer matching tile pairs, since the overlap of some tiles across layers is too small to produce matches at scale 0.02.
I added a parameter to the intensity matching process that allows to specify a different render scale for cross layer matches than for same layer matches. So far, the bottleneck were matches between tiles in the same position but on different layers, since they have a significantly larger overlap (the time was spent in outlier detection since there were a lot of matches).
Details
This might seem like a big change, but the only novelty was introducing and handling the additional scale parameter. All other changes were made while cleaning up. In particular, I:
Matcherclass into its own file and moved the average computation there as well;RealInterval...for the bounding box of a tile andListImagefor the matching process).For further clean up, we should probably think about making the actual rendering process into a class with state instead of a static
Render.rendermethod.Verification
I tested the new parameter with 2 layers of c009_s310_v01_mfov_08 and
--crossLayerRenderScale 0.02(as opposed to the default scale0.1). Here is a neuroglancer view of the two layers, which look good to me.Improvement
At scale
0.1, matching two tiles that partially overlap takes about 150-300ms, while matching tiles that completely overlap takes roughly 1900ms. At scale0.02, matching tiles that completely overlap only takes about 200-300ms. This reduced the runtime from 9:38min (where matching took 6:45min) to 5:00min (where matching took 3:10min). The additional gain in runtime probably comes from the fact that there are fewer matching tile pairs, since the overlap of some tiles across layers is too small to produce matches at scale0.02.