Skip to content

first draft of layer-as-tile code#235

Open
trautmane wants to merge 4 commits into
newsolverfrom
feature/layer-as-tile
Open

first draft of layer-as-tile code#235
trautmane wants to merge 4 commits into
newsolverfrom
feature/layer-as-tile

Conversation

@trautmane

@trautmane trautmane commented Jul 16, 2026

Copy link
Copy Markdown
Collaborator

This code is intended to "roughly-3D-align" the 2D-stitch-only solve results to reduce the amount of work needed to run the results through SOFIMA. It copies/reuses many of the components developed for our MFOV-as-tile process.

The process works with and creates a set of stacks like this:

w61_s109_r00_gc_par_crc_aso :             starting 2D-stitch-only SFOV tile stack
w61_s109_r00_gc_par_crc_aso_lat :         layer-as-tile stack with dynamically rendered layer images
w61_s109_r00_gc_par_crc_aso_latr :        layer-as-tile stack with persisted layer images
w61_s109_r00_gc_par_crc_aso_latr_align :  aligned layer-as-tile stack with persisted layer images
w61_s109_r00_gc_par_crc_aso_3d :          rough 3D aligned SFOV tile stack

The process also creates a layer-as-tile match collection that is used for the layer-as-tile solve.

Our hope is that the ..._aso_3d result stacks are good enough that we can skip cross-layer SFOV match data generation and that the SOFIMA setup work will be reduced/simplified.

A few final notes ...

  • We originally thought the layer-as-tile stacks might be useful for storing layer-based histogram intensity correction information, but that process has changed. We currently do not need to store histogram data.
  • The layer-as-tile stacks might be useful if we want to orient the slabs similarly before we try to connect them into a single volume.

@trautmane
trautmane requested a review from minnerbe July 17, 2026 19:26

@minnerbe minnerbe left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @trautmane! Except for some small comments (and an optional offline conversation), this looks good to me.

Comment on lines +62 to +63
final int scaledImageWidth = (int) Math.floor(renderParameters.width * renderScale);
final int scaledImageHeight = (int) Math.floor(renderParameters.height * renderScale);

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These variables could be doubles. The only usage is a few lines below, where they're explicitly cast to double again.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have very minor and abstract concerns about the extensibility and robustness of the x-as-tile abstraction that I find hard to articulate. @trautmane if you have the same feeling, I'm happy to discuss this offline. Otherwise, I'd view this as an instance of the WET-principle and revisit this abstraction when (and if) we need to extend this a third time.

setup.blockOptimizer.lambdasTranslation = MFOVAsTileParameters.SolveType.AFFINE.getLambdasTranslation();
setup.blockOptimizer.lambdasRegularization = List.of(0.0, 0.0, 0.0, 0.0, 0.0);

setup.blockOptimizer.iterations = List.of(1000, 1000, 500, 250, 250);

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are the first two rounds of optimization exactly the same (1000 iterations of 100% rigid with plateau width 250)? In this case, we could simply concatenate them (i.e., 2000 iterations of 100% rigid with plateau width 250).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants