1 / 18

Mixed-Mode Storage of Whole Slide Pathology Images

Mixed-Mode Storage of Whole Slide Pathology Images. Proposal for DICOM WG-26 & WG-6 Kemp Watson Objective Pathology Services Ltd. Toronto, Canada (905) 770-7802 www.objectivepathology.com. Whole Slide Image scans are HUGE and SLOW !!!. Image Size Comparison (to scale).

stotts
Télécharger la présentation

Mixed-Mode Storage of Whole Slide Pathology Images

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Mixed-Mode Storage ofWhole Slide Pathology Images Proposal for DICOM WG-26 & WG-6 Kemp Watson Objective Pathology Services Ltd. Toronto, Canada (905) 770-7802 www.objectivepathology.com

  2. Whole Slide Imagescans areHUGEandSLOW!!!

  3. Image Size Comparison(to scale) • Typical DICOM image is ~3 megapixels • DICOM image maximum is 64K x 64K = 4096 megapixels • WSI scan is 500K x 250K = 125 gigapixels • 30 – 40,000 times larger, with current technology 50mm x 25mm WSI scanned at 100x = 500,000 x 250,000 pixels = 125 Gigapixels Largest DICOM Image

  4. Download Time Comparison(to scale) • Based on a 10 mbps Ethernet connection, 20:1 compression • a 3 megapixel typical DICOM image takes ~0.3 seconds • a 64K x 64K DICOM image would take ~8 minutes • our example WSI scan would take over 4 hours • Bandwidth equivalent of over 40,000 radiology images WSI scan D C M

  5. Multi-resolution Representation • Because these images are so huge, we require: • regional navigation (pan) feature • scalability in size and resolution (zoom and progressive quality) • Many (if not all) vendors using some form of multi-resolutiontiled image pyramid: • mathematically a “Gaussian Pyramid” • spatial + frequency localization • JPEG 2000 actually uses similar conceptsin its codec, but implementationdetails are less visible

  6. Limits of JPEG 2000 in DICOM • JPEG 2000 itself is very capable of representing huge, multidimensional images • But neither Supplement 61 (JPEG 2000 Transfer Syntaxes) nor Supplement 106 (JPEG 2000 Interactive Protocol) extend image size beyond 64K x 64K pixels • Compression times are on the order of ~10x slower than JPEG • Decompression times are ~6x slower than JPEG • The quality:compression ratio is somewhat better, though

  7. Current Image IOD size IEs • Image X & Y dimensions are stored as Rows (0028,0010)& Columns (0028,0011) • VR of US (unsigned short integer) • maximum value 64K pixels in each direction • Image length (file size) is stored within Pixel Data (7FE0,0010) • VR of UL (unsigned long integer) • maximum file size of 4 GB • WSI scans can be hundreds or thousands of times larger • Access to full image only • no panning to subregions • no zooming to subresolutions • except on client – very inefficient for WSI scans

  8. Fixing Image Dimensions • Want to be backward-compatible where possible • Add optional UL VR elements • maximum value 4G pixels in each direction • don’t replace current US VR elements • However, an image must be reconstructable from the original US VR elements for backwards compatibility

  9. Fixing Image Length • Current standard is actually OK re length if you read the details • the Pixel Data Element (7FE0,0010) is stored with either an OB or an OW Value Representation • OB/OW VR’s normally have a Value Length of up to 4 GB of data with and Explicit VR representation • but the Value Length field of OB/OW VRs can be set to FFFFFFFF to indicate arbitrarily long data, which then must be terminated by a Sequence Delimitation Item, which is Data Element (FFFE,E0DD) • So size is OK, but interactive navigation may still be a problem

  10. What About the Image Data? • Store a “base image” exactly as it already is defined • fairly compatible; little work for vendors to implement • existing compressions and transport syntaxes • Add an optional “extended image” • several vendors suggest tiles for performance • most vendors want JPEG (not 2000) for performance andInternet browser compatibility • others want JPEG 2000 since it’s already in the standard • OK! Let’s do both • and who knows what’s next?

  11. Why Two Images? • Doesn’t have to be, but can be two images • Not recommending any new transfer syntax thatwould obstruct base image compatibility • Large image is optional; it may have a new transfer syntax • Can specify the “line” between large and small image resolutions • by choice of X & Y US and UL VR’s (matching the data of course) • Base image may be a thumbnail, or may be as large as desired

  12. Case 1: Extended Image as 2nd Image • Any currently supported format, including JPEG 2000 • but may have problems with interactivity unless it’s JPEG 2000,tiled, or other pan/zoom capable multi-resolution format • note that base image may have this problem too,though technically deliverable through DICOM now

  13. Case 2: Extended Image as Tiles • Pixel Data stored as nested Sequence Items (FFFE,E000) • not Series-level container • Requires an index to map resolutions and locations to images • Each resolution level as a nested Sequence within the main Sequence • Tiles are standard DICOM pixel data

  14. Case 3: Extended Image isActually a Part of the Base Image • For example, one large JPEG 2000 file • But must be accessible to all current DICOM implementations • Both versions of X & Y length must refer to same image • Could be problems with existing implementations of JPEG 2000 • Not addressed here

  15. Base and Extended Image Modules • Create new Extended Image Pixel module • Pathology Image IOD would contain modules: • General Image (mandatory) • Image Pixel (mandatory – exactly as now) • Extended Image Pixel (optional) • and others… • DICOM implementations could easily see base image • and see extended image with more work • Option: extended image could not just be a larger version of the base image, but could be a differential image • saves 25-33% space, but more computation

  16. Extended Image Module • Larger dimensions • Sequence option for tiled images • Data Elements required: • Pixel Data Provider URL 1C • Rows 1 UL (larger than before) • Columns 1 UL (larger than before) • Tile Image Directory 1C SQ (new) • Extended Pixel Data 1 (SQ or single OB/OW Data Element) • and others similar to Image Pixel module… • Tile Image Directory will contain sizes and tile counts of each resolution layer • If present, SQ will contain a sequence of tiled Pixel Data attributes structured as a folder (DICOM terminology – see spec) holding the tiled image pyramid • Needs more detail, hope you see the general structure 

  17. Streaming and Navigation • Image streaming is absolutely crucial for real-time navigation • DICOM has methods for retrieving Sequence Items • JPIP for JPEG 2000 • So we’re probably OK • If not, we need new streaming syntax

  18. Further Issues • Should extended image format be available as a base image in DICOM? • then available to other modalities • impact on existing implementations? • JPEG 2000 accessible as base size as well as extended size • Image container must be flexible for future transfer syntax enhancement to support multi-spectral, high dynamic range(16-bit +), z-axis focusable, and other imaging formats, as well as adoption of other compression codecs • Image annotation • File format for media representation

More Related