Add path of already calcualted head movements (HPI fitting)

[LorenzE]

Plot the history of the subject's head movements in 3D. This gives the study conductor a better impression about the subject's status and overall data quality. @juangpc came up with the idea to plot the path as connected lines over time.

[RDoerfel]

Do you want to display this in an extra graph or in the 3D View?

[LorenzE]

Inside the existing 3D view. Maybe with an option to hide the path.

[RDoerfel]

Honestly I think this might get a bit messy to visualize this within the head. Also the movements are small compared to head and sensor size, at least in adaults. So you might need a big screen to actualy see more than a point. I actually think it is a nice idea to trace the movement somehow, I just wanted to share my concerns on this way ;)

[LorenzE]

If you see a point I guess that would be a sign that the subject did not move a lot. As soon as you start seeing lines you would immediatley know that there was a movement. I might be mistaking. We should maybe try to come up with a quick prototype to see if this approach is feasible.

An alternative would be to always show the inital position of the subject as @imsorryk proposed during our last meeting.

[juangpc]

I think that even if it gets messy, which it might, it is interesting to see. A checkbox would be enough I think, to ensure that even if it gets messy... that's what you wanted to see.

[imsorryk]

I think the method that @LorenzE described would accomplish demonstrating head movement from initial position. And adding a toggle to show the initial head POS would clarify if the head has rotated.

Another option. Could you trace the movement of the HPI coils? That will give you information of how the head is moving, both translation and rotation.

[RDoerfel]

@imsorryk I think tracing the coils would be even more messy. In MNE-Pthon you have a Dot and an arrow in Z direction of Head Space. So the arrow gets tilted when you rotate too. This will indicate some rotation.

[imsorryk]

@RDoerfel I think that arrows will work just fine then. I think that is enough information to show users the head has either rotated or tilted. Are you thinking have a toggle to show the original head POS as a dot with arrows pointing to each axis, and show the current?

[RDoerfel]

I think this might be the way to go. Showing the whole path is for sure interesting, but probably more important for offline analysis?

[imsorryk]

For live view, I think the solution you proposed will work best. Maybe show a dot for the initial head origin, with an arrow on the Z axis, then trace movement to current origin with updated arrow.

In post having the path of each HPI coil could be useful for quality analysis. I know some sites they place the HPI coils on the forehead of pediatric patients. And they get fitting errors because their scanner has trouble reading the coils. This could be useful to show optimum placement.

[chdinh]

Stale enhancement from the early backlog that was never scheduled and predates the v2.3.0 refactor. Closing as part of issue-tracker cleanup; please reopen with a fresh, current description if this is still wanted.

[chdinh]

Reopening — plotting the subject's head-movement path over time in 3D (credit @juangpc) is a genuinely useful data-quality feature. Keeping it open as a tracked enhancement; contributions welcome.

[chdinh]

Scoped this. The building blocks are all present, they are just not connected.

Data source. Hpi::onDevHeadTransAvailable(const FIFFLIB::FiffCoordTrans&) already receives a fresh device-to-head transform on every successful fit, and Hpi::devHeadTransAvailable is emitted for it. The head origin in device coordinates is the translation column of that transform, so the path is literally the sequence of those translations over time. Nothing new needs to be computed — the history just is not retained anywhere today; each transform overwrites the last.

Rendering. BrainView already owns a NetworkObject for connectivity visualisation, which draws connected line segments in 3D. That is the same primitive @juangpc suggested for the movement path, so a polyline renderer does not need to be written from scratch.

What is actually missing:

1. A bounded history buffer of head positions in Hpi (or better, on RealTimeHpiResult so it travels with the measurement rather than living in the plugin).
2. A BrainView entry point to set/update a polyline, either by reusing NetworkObject or by adding a small dedicated path object.
3. Wiring devHeadTransAvailable through to that entry point, plus a control to toggle the path and to clear it.
4. A decision on colour mapping — plain single colour, or graded over time so the study conductor can see direction of drift. The latter is more useful and NetworkObject already supports per-segment colour.

Point 1 is where the design decision sits: putting the history on RealTimeHpiResult means it is available to anything consuming HPI output, not just the 3D view, which seems clearly better.

Leaving open with the scope recorded rather than half building it.