Hi,
We have encountered what seems to be a bug in Heterogeneous reconstruction.
When we perform a heterogeneous reconstruction starting from a 5-class Class3D run, heterogeneous reconstruction produces 10 volumes (unexpected!).
Looking at the low level slots of the particle output of the preceding class3D run, we have the following:
And looking at the low level slots of the particle input, once this particle stack is input to heterogeneous reconstruction:
So it seems like heterogeneous reconstruction is taking the passthrough alignments from another, previous Class3D run in the job chain, rather than the one that is being directly input to het reconstruct - this is bad for obvious reasons, as the reconstructions will not reflect the input classes. Here we could easily detect it because of the unexpected number of classes, but if the number of slots where the same for the passthrough as for the direct inputs, this could be very confusing.
But it gets messier - the only 10 class 3D job is 5 generations back in the job chain. So where are these passthrough alignments coming from, and how do we keep track of which slot is coming from which originating job?
Cheers
Oli
EDIT:
Upon further examination, these passthrough alignments only seem to be generated in a job chain with a mixture of heterogeneous refinement and Class3D jobs. So for example:
10-class-Class3D → het refine → 5-class-Class3D—> het reconstruct:
→ 10 passthrough alignment slots, 10 (wrong!) classes in het reconstruct
Whereas:
10-class-Class3D → 5-class-Class3D—> het reconstruct:
→ no passthrough alignment slots, normal 5 classes in het reconstruct
Hey @olibclarke,
Thanks for reporting! We’ve noted this – I think the core of the issue is that 3D classification should not passthrough any alignments_class3D_ slots. As it stands now, if you use the particles_all_classes group from job A as an input to job B, job B will overwrite the slots it needs and then passthrough the rest.
I think the only way to avoid this for now is to manually delete the slots that were passed through in the Hetero reconstruct job.
However – what doesn’t make sense to me is the following:
10-class-Class3D → 5-class-Class3D—> het reconstruct:
→ no passthrough alignment slots, normal 5 classes in het reconstruct
What I expect to happen here is that there are 10 classes in hetero reconstruct, with the first five coming from the 5-class job. Can you confirm that no slots were manually deleted here prior to running hetero reconstruct?
Thanks!
Valentin
Correct, no slots were deleted here - it behaves normally if the only jobs in the chain are class3D (and we don’t see any passthrough slots generated in this case), we have only seen the issue when heterogeneous refinement is in there
Ok, thanks – very strange. I can’t seem to reproduce this behaviour on our end – with / without an intermediate hetero_refine I still get a 10-class reconstruction at the end.
A few follow ups. Given the following notation:
(A) 10-class-Class3D → (B) 5-class-Class3D—> (C) het reconstruct
- Job B: How many passthrough / non-passthrough
alignments_class3D_ output slots are there?
- Job C: What do the input slots look like? Do they include
alignments_class3D_X for X in [0, 4] and no other alignments_class3D_?
Hi,
Job B outputs:
Job C input slots:
Jobs A and B were run prior to the release of 4.4, could that be the difference?
Cheers
Oli
Ok, thanks! No luck understanding what’s going on unfortunately. I looked through some older job chains I have (dating back to v4.0) and found at least one example where a 5-class class3D job downstream of a 10-class job has alignment_class3D_5-9 slots passed through.
In any case, I’ve noted this and we’ll make sure to not pass through any alignment_class3D slots in future version of class3D to avoid this confusion. For now, you’ll have to manually ensure that any passed-through slots are deleted in the input to hetero reconstruct.
Valentin
1 Like
