Submission Process

Post-challenge submission

This challenge will remain open-ended, and we are planning to submit a challenge paper. Docker submissions made before 13 Oct 2025 will be considered for co-authorship in the challenge paper, based on performance. The same submission requirement applies to the post-challenge submission.

• Participants are encouraged to familiarize themselves with the fundamentals of building and running Docker images; however, advanced Docker expertise is not required. We have provided a basic Docker image to help you get started, which can predict DDFs on the validation/test dataset. The source code is also available in submission folder.
• The participants are expected to replace the content of predict_ddfs function with their own algorithm, which is used in test.py. The function is expected to take one entire scan as input, and output four DDFs. There is no requirement on how the algorithm is designed internally, for example, whether it is learning-based method; frame-, sequence- or scan-based processing; or, rigid-, affine- or nonrigid transformation assumptions.
• The requirement of the predict_ddfs function is described below:
  • Input:
    • frames: All frames in the scan; numpy array with a shape of [N,480,640], where N is the number of frames in this scan.
    • landmark: Location of 100 landmarks in the scan; numpy array with a shape of [100,3]. Each row denotes one landmark and the three columns denote the frame index (starting from 0) and the 2d-coordinates of landmarks in the image coordinate system (starting from 1, to maintain consistency with the calibration process). For example, a row like [10,200,100] indicates that there is a landmark in the 10th frame, located at the coordinates [200,100].
    • data_path_calib: Path to calibration matrix.
    • device: Device to run the model on, provided in this line.
  • Output:
    • GP: Global displacement vectors for all pixels. DDF from the current frame to the first frame, in mm. The first frame is regarded as the reference frame. The DDF should be in numpy array format with a shape of [N-1,3,307200] where N-1 is the number of frames in that scan (excluding the first frame), “3” denotes “x”, “y”, and “z” axes, respectively, and 307200 is the number of all pixels in a frame. The order of the flattened 307200 pixels can be found in function reference_image_points.
    • GL: Global displacement vectors for landmarks, in mm. The DDF should be in numpy array format with a shape of [3,100], where 100 is the number of landmarks in a scan.
    • LP: Local displacement vectors for all pixels. DDF from current frame to the previous frame, in mm. The previous frame is regarded as the reference frame. The DDF should be in numpy array format with a shape of [N-1,3,307200], where N-1 is the number of frames in that scan (excluding the first frame), “3” denotes “x”, “y”, and “z” axes, respectively, and 307200 is the number of all pixels in a frame. The order of the flattened 307200 pixels can be found in function reference_image_points.
    • LL: Local displacement vectors for landmarks, in mm. The DDF should be in numpy array format with a shape of [3,100], where 100 is the number of landmarks in a scan.

NOTE: 

• If you are not sure about data dimensions, coordinate system or transformation direction, etc., please refer to the example code in baseline_model folder.
• We have provided two functions, which can generate four DDFs from global and local transformations, in Transf2DDFs.py.
• Only modify the implementation of the predict_ddfs function. It’s okay to add files but please do not change existing files other than baseline_model folder.
• The order of the four DDFs and the order of 307200 pixels cannot be changed and they must all be numpy arrays. Please ensure your prediction does not have null values. Otherwise, the final score could not be generated.
• Your model is expected to run on a single GPU, with GPU memory usage not exceeding 32GB when running docker.
• Participants are required to dockerize their trained network/algorithm/method and submit them via a file-sharing link (e.g., OneDrive, Dropbox) to the organizers via this form.
• Participants are allowed to make multiple distinct submissions (but must ensure they are not merely simple variations in hyperparameter values), and the best result will be selected for competing. The number of submissions for each team is limited to 5 to preserve variations in hyperparameters.
• The test set in the TUS-REC2025 Challenge includes only the rotation scans, but you may use the datasets from the TUS-REC2024 Challenge as extra training data.

Please contact qi.li.21@ucl.ac.uk if you encounter any problem during submission.

Receipt of all submissions will be acknowledged via email within two working days of receipt, and evaluations will be posted on the leaderboard once completed.

The evaluation code, together with the baseline model, is publicly available here. Participating teams are encouraged, though not obligated, to share their code publicly. Links to any available source code will be provided.