Data Compression in the PACS Environment

Abstract

A compression server in a PACS environment has to deal with images of different types and sizes. The images will flow into compression at different rates, ranging from 1-2 Mbytes/sec to 9.6 Kbytes/sec. Additionally, the pattern of the flow can vary. Some images will enter compression in one block. Other images, especially large images (i.e., digitized film images) will enter compression as a series of blocks. Interleaving of blocks can also occur. For example, the first two blocks from a digitized X-ray film may enter compression followed by a block from a CT image followed by more blocks from the X-ray film. In order to process incoming images rapidly, the compression service must compress blocks as they arrive. The compression of a CT image should not have to wait for the final arrival of a slowly transmitted large digital X-ray image. On the other hand, temporarily buffering large images or adding extra compression hardware may make the compression service too expensive. These PACS network considerations argue for compression that operates on images locally. That is, the compression algorithm should not have to know the statistics of the entire image to be effective. Any transforms should operate on local blocks within the image independent of the results on antecedent or subsequent blocks. In addition, since the network may present relatively small blocks to compression (as small as 64 Kbytes), the compression technique should not add a large amount of overhead to the compressed data in the form of tables, descriptors, and so forth. In this paper, the effects of breaking data into fragments was tested using a simulation tool dubbed PAW (Performance Analysis Workstation.) Two cases were considered. In the first case, large images were compressed in their entirety. In the second case, large images were broken into fragments and the fragments were compressed separately. The results show that processing the data in fragments is desirable.