fix(multisem): slab indexing wafer53

templiert commented 3 months ago

@StephanPreibisch This PR should fix the current indexing, which I believe is wrong.

StephanPreibisch commented 2 months ago

Hi, somehow my comment from Friday went missing. Why do you think this is wrong @templiert ? I tried it on I think 5 random and not random slabs and it was working ... do you have a case where it fails for testing?

templiert commented 2 months ago

Conclusion: your reverse index lookup must work and I mistakenly thought your slab was 1-indexed, sorry for the false alarm

do you have a case where it fails for testing?

I do not.

Why do you think this is wrong

Because at first sight your logic was not following my recommendation on how to use these lists. With a closer look, I now see that you are doing a reverse index lookup instead of using the direct lookup, which actually should work just as well. E.g.:

direct = use the stage_to_serial column to convert from stage to serial
reverse = use the serial_to_stage column to convert from stage to serial

My other confusion was that I understood that your slab was 1-indexed. But a random example with slab=4 works if slab is 0-indexed for your current findStageIdPlus1 method, see below. So I assume now that your slab is actually 0-indexed. And you write that it worked for a few slabs, so it probably then all works.

slab=4

your way Assume slab is 0-indexed. What is the line index of 4 in stage_to_serial? Your line counting is 1-indexed -> line = 10 -> idStagePlus1 = 10
my way What is the 4th element (0-indexed) of serial_to_stage -> idStage = 9 -> idStagePlus1 = 10

minnerbe commented 2 months ago

Hi @templiert, after having an in-depth look at the code myself, I agree that the two approaches are equivalent. Thanks for going through both in that detail!

Right now, I'm trying to wrap my head around a problem that arises further down the process: We're using the results from the lookup to reconstruct Ken's alignment, which apparently is indexed by stageIdPlus1. I.e., for your example, if we want to reconstruct the alignment for slab 4 (serial order), we have to use transformations and images that for slab 10 (stage id + 1). This seems to work quite well: we get an error of about 1px (or even less) in the reconstructed stacks compared to Ken's original alignment.

However, if we apply this process to slab 401 (serial order), the lookup process tells us that stageIdPlus1 is 403, for which no transformations or images exist. It seems like there's still a mismatch of my mental model and reality. Could you maybe help me understand what's going wrong, here?

Never mind, I think I found the issue: there are only 400 stacks in Ken's original alignment, so it seems that the final two (serialId 401 and 402) are actually just missing.

minnerbe commented 1 month ago

Since all issues seem to have been resolved and the task for which this code was intended was completed, I'm going to close this PR.

saalfeldlab / render

fix(multisem): slab indexing wafer53 #193