2dseq transposition appears to be applied twice: RECO_transposition records what reconstruction already did

[gdevenyi]

Schema2dseq gained _apply_transposition, which transposes the XY axes of
every frame whose RECO_transposition / VisuCoreTransposition flag is set.

I believe the reconstruction has already applied that transposition when it
wrote the 2dseq, so applying it on read transposes the image. Two independent
lines of evidence, neither of which relies on any converter's output.

1. It contradicts the geometry parameters in the same file

Any flagged non-square reconstruction shows this. One I have to hand, PV6.0.1,
3D:

VisuCoreSize    [178, 200, 100]
VisuCoreExtent  [16.02, 18.00, 9.00]

The field of view divides by the matrix, in VisuCoreSize order, into isotropic
0.090 mm voxels — which is what the acquisition was. Pair that same extent with
the transposed array (200, 178, 100) and the voxels come out 0.080 x 0.101 mm.

So VisuCoreExtent describes the untransposed array, and by construction so do
VisuCorePosition and VisuCoreOrientation. Transposing data alone puts it at
odds with the whole geometry block a consumer uses to build an affine — and the
affine is unchanged by this code, so the image and its geometry now disagree.

2. Two acquisitions of the same object stop agreeing

I have an orientation phantom study containing pairs that differ only in
readout direction — the variable that flips this flag. Same phantom, same
session, same slice orientation, same voxel size, identical direction cosines.
Two images of the same object in the same plane must hold the same array.

Correlating each pair as-is, and with one member's in-plane axes swapped:

pair		as-is	one transposed
PV6.0.1 coronal 2D	flag left alone	+0.951	+0.283
	0.4, flag applied	+0.283	+0.951
PV6.0.1 axial 3D	flag left alone	+0.992	+0.532
	0.4, flag applied	+0.532	+0.992
PV5.1 axial 3D	flag left alone	+0.928	+0.426
	0.4, flag applied	+0.426	+0.928

The pairs already agree when the flag is left alone. Applying it is what makes
two images of the same object disagree, and the prediction inverts exactly
between library versions.

Consistent with the ParaVision docs

ATB_SetRecoTranspositionFromLoops is documented as the method program
"calculating the values of the RECO_transposition array depending on the image
orientation" — the sequence telling the reconstruction what to do, which the
reconstruction then does. The parameter reads as a record, not an instruction.

Scope

The flag is set on 1,142 of 1,561 reconstructions (73%) in the corpus I test
against, spanning PV5.1, 6.0.1, 7.0.0 and PV360 — so this changes the pixel data
of most datasets, silently.

What I have not established

• Only PV5.1 and PV6.0.1 are covered by the pair experiment. Not 7.0.0 or
  PV360 — and the flag's source differs (RECO_transposition for 1,052 of those
  reconstructions, VisuCoreTransposition for 90), so they need not behave alike.
• All three pairs are axis-aligned; oblique acquisitions are untested.
• The phantom study's redistributability is unestablished, so I can't attach it.
  The geometry argument in (1) needs no data from me — it reproduces on any
  flagged non-square reconstruction you have.

Happy to be wrong about this if there's a dataset where the transposition is
genuinely pending on read; that would be very useful to see.

See also #(the shape issue), which is a separate defect in the same code path.

🤖 Generated with Claude Code

https://claude.ai/code/session_019P9Qp72Xymjic1eT9sMB5Q

[gdevenyi]

Stronger version of the same evidence, purely from parameters — no image
comparison, no derived products.

In an internal phantom study the sample is placed identically throughout and only
console settings vary, so a readout-direction pair differs in exactly one thing.
For the PV6.0.1 axial 3D pair:

	scan 13 (read L_R)	scan 19 (read A_P)
PVM_SPackArrSliceOrient	axial	axial
PVM_SPackArrGradOrient — acquisition frame	[[1,0,0],[0,1,0],[0,0,1]]	[[0,1,0],[1,0,0],[0,0,1]]
VisuCoreOrientation — image frame	identity	identity
VisuCorePosition / VisuCoreSize / VisuCoreExtent	—	identical
transposition flag	clear	set

The acquisition frames differ by exactly a read/phase transposition. The image
frames are identical. The flag is set on precisely the member where the two
frames differ.

That is what it means for the parameter to record a transposition already
applied — to bring the acquired frame into the image frame.

And it rules the other reading out directly: VisuCoreOrientation describes the
stored 2dseq, and it is identical for both members, so the two stored arrays
must be in the same layout. If the flag were pending on read, scan 19's array
would still be in the acquisition frame while its own VisuCoreOrientation
claimed the image frame — the parameter would be misdescribing the data sitting
next to it.

The correlations in the issue body then just confirm what the parameters
already say.

🤖 Generated with Claude Code

https://claude.ai/code/session_019P9Qp72Xymjic1eT9sMB5Q

[gdevenyi]

Correction to this report, prompted by #161.

My evidence was three readout-direction pairs from an orientation phantom, and
every frame in them is square — 96×96 and 128×128. #161's rule skips the
exchange when the two dimensions have equal length, so my measurements only ever
covered the case where both of us agree there is nothing to do. The claim in the
title — that the transposition is simply applied twice — is therefore right for
square frames and too general as stated.

For a non-square frame carrying a nonzero VisuCoreTransposition, #161 is
measuring something I could not: the frame really is stored with its dimensions
exchanged, and reshaping it with VisuCoreSize interleaves its rows. Removing
_apply_transposition outright in 0.4.1 — which is what this report led to —
leaves those frames under-read. #161 restoring the swap, gated on unequal
lengths, looks like the correct resolution rather than a partial revert of this.

I tried to test that case independently and could not: my instrument was
adjacent-row correlation within a frame, which for the one non-square
mixed-transposition dataset in my corpus
(samri_paravision/…/20180730_053743_6587_1_1/5/pdata/1, 110×120, frames 5-14
flagged) cannot separate the two readings — 0.95 as-VisuCoreSize against 0.96
stored-then-swapped. #161's cross-frame profile comparison is the better
instrument and I would defer to it.

Two things worth recording for whoever revisits this:

• RECO_transposition and VisuCoreTransposition are not interchangeable here.
  The dataset I used for the geometry argument in this report
  (mch_dev_022/2/pdata/1, 178×200×100) carries RECO_transposition = 1 with
  no VisuCoreTransposition — and FILE_FORMAT.md 7.2 now says that
  parameter is optional, written only when frames differ, its absence meaning no
  frame needs one. Reshaping that one with VisuCoreSize is correct, and
  applying a swap destroys it.
• The spec was ahead of both of us. FILE_FORMAT.md 6.9 already said "the D3
  class parameters are written after transposition to describe the final on-disk
  layout", and lists transposition inside the reconstruction pipeline before
  2dseq is written. I reached that by experiment instead of reading it, and it
  should have been this report's primary citation.

🤖 Generated with Claude Code

https://claude.ai/code/session_019P9Qp72Xymjic1eT9sMB5Q