Health Imaging & IT - October 2007 - (Page S6) Buyer’s Guide - Decision Making for 3D Vendor Selection for rendering, consuming CPU power, memory, and hard drive space for the working volumes. -How well do the tools work on these cases presented “cold”. No workstation is perfect, but they all seem to demo so well… but the important thing is not how well it does on a great case. How does it deal with really challenging cases? -Is there a limit to the number of slices a system can load at one time? -Make sure that the key features are demonstrated on full-size datasets with diagnostic-quality resolution to fully understand real-world performance. -Vendors sometime talk about remote control of a workstation. Check to see if that locks out the workstation for anyone else to use it on a different case concurrently. It usually does. What’s automatic preprocessing and how does it work? Automatic preprocessing should take care of most of the routine tasks related to 3D image management, such as removing bones, calculating color maps to encode timedependance, filtering for spherical objects (e.g. SPN), or removing the CT table from an examination. When these tasks are automated and performed off-line, results are delivered to a technologist or physician without them having to initiate the process and then wait for it to complete, and hence, valuable time is saved. In order for this to work well, ideally preprocessing tasks should be centralized to a dedicated preprocessing server, because if they are performed on a workstation or rendering server that is also serving active users, the interactive performance of that system will be impacted while the preprocessing is being performed. Preprocessing should never interfere with active interpretation sessions. Key questions to ask: Is automatic preprocessing available? Is the task separated to a dedicated system serving the enterprise? What features are supported (e.g., bone removal, sphericity filters, parametric mapping, CT table removal, centerline extraction)? Pitfalls: Beware the claim that preprocessing is supported when actually all that is being done is preparation of data for 3D rendering. Vendors that rely on commodity graphics cards or off-the-shelf computers for 3D rendering often have to perform extensive preparation of the image data before it can be rendered in 3D, which uses additional disk space, consumes CPU power and adds minutes of delay before even basic 3D rendering can begin. This is entirely different from the “added value” of advanced preprocessing as described above. What’s the difference between the technologies out there? The key differences between the 3D technologies in the market relate to the technology used for 3D rendering, and the general architecture of the system. When the CPU of a computer is used for 3D rendering, a generalpurpose processor designed for Microsoft applications performs a specialized medical imaging task, often with poor efficiency and performance, even when compromises are made in image quality. The same is true for GPU rendering, as “video cards” in most computers are mainly designed for computer games. These cards deal primarily with “polygon” graphics and typically do a poor job on anatomical data, with compromises in terms of performance and image quality. 6 As a result, such systems usually have to calculate additional information about every dataset that is received, just to prepare it for 3D rendering, which takes time, memory and CPU power, and the results must then be stored on the hard drive, consuming additional space. The alternative is to use a dedicated hardware processor specifically designed to perform medical visualization where the slice data can simply be downloaded to the board’s memory without any delay or additional processing, with real time 3D following. Such a system can have the power and scalability to manage a true client-server deployment powerful enough for an imaging enterprise. This fundamental technology question leads to the Buyer’s Guide w w w. t e r a re c o n . c o m http://www.terarecon.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.