The temporalpipeline
A drop-in temporal block — so any gain is provably from modelling time, not from swapping the backbone.
The guiding principle of the design was restraint. The RETFound-Green backbone and the existing classification head were kept exactly as they were — a new temporal block was inserted between them.
That constraint is what makes the result trustworthy: if performance changes, it is attributable to temporal modelling — not to a swapped backbone or a retuned classifier.
A drop-in temporal block.
RETFound-Green backbone
Each frame is encoded into a 384-dimensional embedding.
Temporal stack
Bin-then-select, then a two-layer GRU summarises the progression into a single vector.
Classification head
The existing linear head maps that vector to five HyperF-Type classes.
From up to 200 frames down to a 12-step sequence.
A full exam can reach 200 frames — too many to feed a recurrent model within memory. The resolution: keep the three data-driven phases, pick four representative frames per phase, and feed an ordered sequence of twelve embeddings to a two-layer GRU. A recurrent model was chosen over a Transformer because the binned sequence is short; the design specified an LSTM and the implementation switched to a lighter GRU.
Built into the group’s framework — not bolted on.
An exploratory script proved the idea end to end; the final pipeline was integrated into MedNet, the group’s framework, with responsibilities cleanly separated and every run producing an auditable output folder. A two-layer unit-test suite — one for the model, one for the data — guards it against silent regressions.
Working code is not automatically good professional software. Moving from a one-file script to a tested, framework-integrated pipeline is what makes the work reusable by the researcher who picks it up next.