Performance in Medical Image Computing

1. Performance in Medical Image Computing Dr Daniel Rueckert Department of Computing Imperial College London

2. Introduction IXI project is about application of e-science to medical imaging research • Distributed image acquisition Distributed data storage Distributed image analysis Workflow

3. Aims • To build a grid infrastructure for medical image analysis • Apply it to exemplars relevant to: • biomedical research • drug discovery • healthcare • Use e-science as a driver for novel algorithm development

4. IXI System: Overview • How does IXI work? • What sort of images? • How big are images? • How long do the algorithms take? • What are the end-user applications?

5. IXI System: Aims • Make large remote compute resources available via Grid Services • Dedicated service for each algorithm • Be able to compose one service with another to form a workflow • Hide the complexity from the user • Seamless integration with interface • Invisible and secure transfer of files • Make the results easily available • Store in a database

6. IXI System: Architecture • Local network • Web portal • Relational database (image and meta data are directly imported from DICOM) • XML database (stored workflows) • File system (image files) • Locally hosted grid service (reinsertion) • Remotely • Registry Service (index) • Workflow Service (workflow execution) • IXI Core Service (delegation)

7. Reinsertion Service Relational Database File transfer via Grid FTP Workflow Service Insert derived data and copy to file system Initiate reinsertion Retrieve workflow and local file locations Matching subjects located Query File transfer via Grid FTP Co-ordinate and delegate Web Portal Submit workflow Retrieve workflow & parse XML E-mail user IXI Core Service Workbench XML Database Select workflow template Clicks link in e-mail Review results User enters search criteria Instantiate workflow and submit Select files to keep User Condor GT3 GRAM Execute locally How it works Finished

8. IXI: Dynamic brain atlas demonstrator Age 16-35 rigid/non-rigid registration Age 35-65 Age 65+ classification Database of medical images Statistical or probabilistic atlas

9. Relational Database Workflow Service Submit workflow Web Portal Workbench XML Database E-mail user User How it works: Problems ?

10. What sorts of images? 2D images (ie x-ray) 3D images (ie CT, MR, PET) 4D images (ie CT, MR)

11. How big are images? • Current clinical routine: • MRI examination: 200 – 300 slices of 256 x 256 pixels x 2 bytes per pixel ~ 30Mbytes • CT examination: 10 – 30 slices of 512 x 512 pixels, 2 bytes per pixel ~10Mbytes • Digital x-ray: 512 x 512 pixels x 2 bytes x 8 -25fps x 100 – 500 seconds ~1.5Gbytes • but only small fraction of this used for measurement or archive

12. How big will images be soon? • Latest technology: • MRI examination: 300 – 500 slices of 512 x 512 at 2 bytes per pixel ~150Mbytes • CT examination: 100 – 300 slices at 512 x 512 at 2 bytes per pixel: ~100Mbytes • And can be dynamic, eg: 10 – 50 cardiac phases • The raw data problem: • Latest techniques manipulate raw data eg: 32 complex channels, which is 128x larger than reconstructed data ~20Gbytes

13. How long do the algorithms take to run? • Segmentation • tissue segmentation: between 30 secs and 10 minutes • anatomical segmentation: between several minutes and hours • Registration • rigid and affine: between 30 secs and 5 minutes • non-rigid: between 10 minutes and 24 hours • Visualisation: • rendering: near real-time even on standard PCs

14. Accessing, Collecting and Mining Image Data: Genomics, proteomics, Gene expression Drug discovery Clinical Trials Large Scale Simulation and Analysis Simulation of cardiac blood flow using CFD Large image based databases Interpretation, training Support of multidisciplinary and collaborative environments requiring complex planning and guidance tasks Diagnosis Treatment planning Treatment verification Broad categories of IXI applications Biomedical Research Healthcare

15. Why does performance matter? • Performance is mainly dependent on: • Computing time • Data transfer time • Reliability and availability of services • Performance has different priority for different applications: • Drug discovery study with 100 subjects • Computer assisted surgery

16. Biomedical Research: Drug discovery • Image mining: • Statistical parametric maps of volume change in patients with schizophrenia undergoing drug treatment population time t = 1 population time t = 2 intrasubject registration intersubject registration TBM reference

17. Why does performance matter? • Drug discovery study with 100 subjects • End user: Researcher • Computing time for each job: ca. 8 hours • Total computing time: 100 x 8 hours, but jobs can run in parallel • Data transfer time for each job: ca. 1-2 minutes • Total transfer time: 100 x 2 minutes, however transfers can’t run in parallel (complications: firewalls slow data transfer down significantly) • Reliability is more important than run-time

18. Healthcare: Computer-assisted interventions Use non-rigid registration to update pre- operative plan Ideally real-time, however 10-20 minutes are acceptable

19. Why does performance matter? • Computer-assisted surgery • End user: Clinicians & Surgeons • Computing time: ca. 1 – 8 hours on a workstation • Total computing time: Depending on available machine between 10 mins (cluster) and several hours (single workstation) • Data transfer time: Can be neglected • Reliability is important, but performance prediction is far more important: • Which machine should I run the job? • How long will it take on that machine?

20. Performance modelling for image registration source Rueckert et al IEEE TMI 1999 target

21. Performance modelling for image registration

22. Non-linear optimization Performance modelling for image registration Initial trans- formation T Calculate cost function C for transformation T Generate new estimate of T by minimizing C Update trans- formation T Final trans- formation T Is new transformation an improvement ?

23. Analytical performance modelling: Seems impossible Not desirable since as it often takes more time than developing the algorithms Experimental performance modelling: Run algorithms with different parameters and datasets Performance modelling Work by Stephen Jarvis, Dan Spooner, Brian Foley University of Warwick

24. Highly variable runtime - a factor of 16 between fastest and slowest at the same image size Two classes of registration. Depends on destination image. Self registration is fast. Significant speedup using MPI cluster implementation Prediction based on timing of subsampled images Performance modelling Work by Stephen Jarvis, Dan Spooner, Brian Foley University of Warwick

25. Highly variable runtime - a factor of 16 between fastest and slowest at the same image size Two classes of registration. Depends on destination image. Self registration is fast. Prediction based on timing of subsampled images Significant speedup using MPI cluster implementation Performance modelling Work by Stephen Jarvis, Dan Spooner, Brian Foley University of Warwick

26. Highly variable runtime - a factor of 16 between fastest and slowest at the same image size Two classes of registration. Depends on destination image. Self registration is fast. Significant speedup using MPI cluster implementation Prediction based on timing of subsampled images Performance modelling Work by Stephen Jarvis, Dan Spooner, Brian Foley University of Warwick

27. Highly variable runtime - a factor of 16 between fastest and slowest at the same image size Two classes of registration. Depends on destination image. Self registration is fast. Prediction based on timing of subsampled images Significant speedup using MPI cluster implementation Performance modelling Work by Stephen Jarvis, Dan Spooner, Brian Foley University of Warwick

28. Highly variable runtime - a factor of 16 between fastest and slowest at the same image size Two classes of registration. Depends on destination image. Self registration is fast. Prediction based on timing of subsampled images Significant speedup using MPI cluster implementation Modelling systems and applications

29. What next? • Incorporate performance modelling and predication into the IXI workflow (with help from S. Jarvis, Warwick): • to enable the user to tune parameters of the workflow with respect to the predicted performance • to enable the user to specify performance constraints • to inform the user about progress of workflow and provide updated measures of predicted performance • to implement different policies for scheduling for different IXI applications and end users

30. What next: Challenges • Data transfer can affect performance significantly: • Model data transfer times • Model bottlenecks such as firewalls or database servers • Performance modelling for different algorithms is a time-consuming tedious task: • Large number of different algorithms and different implementations • Can this be automated? • Reliability and availability is generally more important than performance, however this will change as the grid middleware and infrastructure becomes more mature • Future projects require near real-time performance • Analyze data while patient is inside the scanner (Neurogrid)

31. Acknowledgements • IXI team • Imperial College: Jo Hajnal, Andrew Rowland, Raj Chandrashekara, Michael Burns, Dimitrios Perperidis • University College: Derek Hill, Kelvin Leung, Bea Sneller • University of Oxford: Steve Smith, John Vickers • Stephen Jarvis, Dan Spooner, Brian FoleyHigh Performance Systems GroupDepartment of Computer ScienceUniversity of Warwick