| Skip navigation |
||||||||
| |
||||||||
|
Image Storage and Transmission Optimization ProjectPrincipal Investigator: Rodney Long
The ISTO project is proposed as an R&D effort in communications and compression techniques and technology to improve Internet access to, and Internet delivery of, biomedical images. Such images, usually highly data intensive, challenge conventional methods of organization, storage, retrieval and transmission. A current example of such data intensive images is the Visible Human image dataset consisting of images of a male and a female cadaver. In each dataset, there are four imaging modalities: digitized color cryosection images taken by a CCD scanner, color cryosection 70mm photographs, CT and MRI. With the exception of the photographs, the other data is currently available in electronic form. In the male dataset, for each modality, there are 1871 cross-sectional images, the most data-intensive by far being the CCD-captured color cryosection images, amounting to about 15 gigabytes (GB). The female dataset, consisting of cross-sectional images taken at one-third the interval of the male, amounts to about 40 GB. When the photographs are digitized inhouse at a resolution (4096 x 2700 pixels) exceeding that of the CCD scanner, the additional data will amount to about 60 GB for the male and 190 GB for the female. The total data in the Visible Human dataset therefore is considerable. In view of the need to organize, store, retrieve and transmit this dataset, an investigation is proposed under the ISTO project of both compression and communications techniques to make the storage, Internet delivery and possible distribution on electronic media more efficient. Specific objectives are: 1. Study both lossy and lossless compression approaches to reduce redundancy in the Visible Human color cryosection slice images, and select the most promising combination of parameters for each. 2. Develop two compression methods, one lossy and the other lossless, using a combination of approaches. The development will include both compression and expansion software. 3. Study alternative means to improve transmission speed on the Internet, namely the multisocket technique developed inhouse and advanced TCP approaches developed elsewhere. 4. Develop a transmission module for client and server for implementation. 2. Project Significance
These large sizes preclude rapid transfer over the Internet as well as convenient distribution by CDROM or other optical media (the CCD-captured set of 55 GB will require 110 CDROMs, for example). We are therefore proposing an investigation focusing both on compression techniques as well as communications methods in an attempt to alleviate the problem. The next two sections of this report are organized around the two proposed efforts (compression and communications). First, the background, methods and procedures for the compression work is given in Section 3; next, the same is done for the communications work in Section 4. 3. Compression Relevant Background A key consideration in compressing the dataset is the retention of image quality in the reconstructed images for a wide range of anticipated applications. Conventional lossless compression, which achieves this goal, has the disadvantage of very modest compression ratio (CR), no more than 2 or 3 [Pennebaker]. This will not make much of a dent in the ease of distribution of 250 GB of Visible Human image data. A variety of lossy compression techniques are available, some of them standardized: e.g., JPEG and MPEG. JPEG (Joint Photographic Experts Group), widely used for commercial imagery, has the advantage of being available as commercial products, but also has the disadvantage of creating blocky (or, blocking) artifacts at respectable compression ratios, i.e., over 10. This is a consequence of its 8 x 8 discrete cosine transform (DCT) coding scheme, originally introduced for two reasons: first, because of hardware limitations at the time of its development and standardization, and secondly, because applying DCT to the whole image ignores the often significant differences in frequency content in various regions of the image, leading to performance loss. A major reason for the JPEG committee to select DCT as the data decorrelation technique over ten competing candidates was the seminal work in 1974 by Ahmed, Natarajan and Rao showing that this transform was very close to the Karhunen-Loeve-Hotelling transform, one that produces uncorrelated coefficients [Ahmed]. Decorrelation of the coefficients is very important for compression because each coefficient can then be treated independently without loss of compression efficiency. The full-frame DCT (FDCT) has been employed in at least one non-JPEG scheme and implemented in hardware for speed [Ho]. This system has been used in studies of the detection of a variety of diseases, e.g., subperiosteal resorption, interstitial lung disease, pulmonary nodules [Sayre, Lee]. In the case of detection of subtle pulmonary nodules, for example, observer performance was reported to be equivalent for compressed and uncompressed images for CR up to 44 [Cox]. The FDCT scheme apparently does not exhibit the blocking artifacts associated with JPEG because the transformation is done on the full frame rather than on small repeated square regions in the frame. However, computational intensity does not allow practical software implementation, the technique here relying on special-purpose hardware, as a consequence of which widespread activity in this area does not seem to exist. Most current research efforts in lossy compression that appear promising involve the discrete wavelet transform (DWT), after the pioneering work by Ingrid Daubechies in 1987 [Daubechies]. The reasons for this are that the DWT operates on the whole image as a single block thereby avoiding blocking artifacts typical in JPEG, while dynamically adjusting its spatial/frequency resolution to the appropriate level in various regions of the image. While the Daubechies family of wavelets are the basis functions of choice in current application to compression, the selection of other wavelets based on optimizing time-frequency localization properties is an active research area [Morris, Dorize]. A recent Harvard Medical School/Massachusetts General Hospital study using a range of medical xray image types including chest, bone and abdomen found DWT to provide reasonably high CRs with minimal degradation [Goldberg]. In this study, seven board-certified radiologists found no clinically relevant degradation in reconstructed images up to a CR of 40 with one exception. This was the case in one subtle case of subperiosteal bone resorption in which one of the seven observers thought that the perceptible image degradation at CR of 30 could be of diagnostic significance. No other instance was cited below CR of 40. While not focusing specifically on medical images, an important study evaluated several lossy techniques including JPEG and wavelet transform. This study, done by Kodak for the National Image Transfer Format standards committee, used a standard, educated observer method to compare sets of images for relative quality. The images included a CT image, military recon images and the Lena test image. Wavelet transform was ranked first in every case, while JPEG was consistently ranked much lower [Cohen, Brower]. The wavelet transform-based data compression system used in this study was a commercially available sofware for grayscale imagery from Aware, Inc., Cambridge, MA. The Aware software is not optimized for medical images and the algorithm is quite basic in other respects, e.g., it uses the basis functions designated as Daubechies 3 (D3) rather than the higher order D4 or D12 which implement filters approaching the mathematically ideal filter. Despite these limitations, the Kodak study strongly suggests that the wavelet transform is a promising approach. Methods and Procedures In the compression area, the objective is to design and develop two systems, employing different approaches to redundancy reduction. Each will have multiple stages that themselves represent different compression techniques. Common to both systems is the first stage which is motivated by the observation that for many of the slices, the field of view (2048 x 1216 pixels) substantially exceeds the region of interest, the remaining area being uniform background. Cropping the images to result in a rectangle encompassing the region of interest will yield some file size reduction. The approach therefore is to start with the removal of the uniform blue background that surrounds the anatomic slices in each frame, and the representation of the remaining (significant) region as rectangle-encompassed slice data together with 44 bits of rectangle coordinate information. Beyond this common first stage, the two approaches are very different, one being lossless and the other lossy. In the lossless approach, the second stage is based on the recognition that a considerable degree of redundancy appears to exist on adjacent 2D slices. This allows the labeling of a relatively small percentage, say 10%, of the total number of slices as "reference" slices and the intervening ones as "difference" slices containing the pixel differences between adjacent frames. The third stage is to reduce the redundancy in the difference slices by runlength coding or other lossless technique. The advantage of this lossless or "information-preserving" approach is that it requires no expert evaluation of quality, since the quality of the compressed data will be identical to that of the original. The disadvantage is that compressibility is likely to be limited, the precise degree to be determined by experiment. Although conventional lossless methods yield CR of no more than 3, special purpose methods employing preprocessing stages yielding CR up to 9 have been reported. An example is a technique applied to mammograms involving segmenting the breast and background, compressing the former with a predictive (lossless) coding method, and discarding the latter [Wang]. This is an approach relying on a preprocessing step similar to our image segmentation stage where the blue background in the slice images is removed. The second (lossy) approach also starts with removal of the background resulting in rectangle- encompassed slice data. These slices are then subjected to data decorrelation by either JPEG or wavelet transform. As mentioned above, JPEG, an industry standard technique, has the advantage of commercial products that may be incorporated into the compression system, but has the disadvantage of blocky artifacts in the reconstructed images arising from the representation of each image as a collection of 8 x 8 pixel blocks prior to the application of discrete cosine transform (DCT) for data decorrelation. This block representation is fundamental to the JPEG standard and was considered essential for practical implementation due to hardware limitations when the standard was promulgated. Preliminary investigation in our lab reveals that blocky artifacts do exist in the reconstructed Visible Human images and are increasingly visible at higher CRs. This was one of the findings of a first-level study that we undertook to provide motivation for this proposal. Our objectives in this preliminary study were to: (1) Compare the quality of the reconstructed images resulting from JPEG and wavelet compression applied to a sample of the Visible Human color image dataset; (2) Compare the quality of the reconstructed images resulting from applying wavelet compression at increasing CRs. Our investigation proceeded as follows. We selected about 30 slices from different regions of the male dataset. For the wavelet transform compression, we used EPIC, an experimental public- domain software package developed by Simoncelli and Adelson at MIT [Adelson]. For the JPEG compression, we used Alchemy, a commercial product suitable for color images. In its present form, EPIC cannot be applied directly to color images or images greater than 512 x 512 pixels. So, we wrote software to split the 24 b/pixel images into 8 b/pixel planes and to reconstruct the decompressed color image from the three decompressed 8 b/pixel planes. We also took 512 x 512 sections of the original images. These then became our "originals" for the experiment, and were compressed at CRs ranging from 20 to 60. An example of one slice compressed using wavelet transform at three different CRs is shown in Figure 1. The original appears in Fig. 1(a); reconstructed images at CR of 20, 40 and 60 appear in Figs. 1(b), 1(c) and 1(d) respectively. From these figures, it does not appear that the reconstructed images differ appreciably from the original when displayed at the scan resolution. In Figure 2 we show a comparison between wavelet and JPEG. A slice section is compressed at CR of 40 by wavelet transform in Fig. 2(a) and by JPEG in Fig. 2(b). A different slice section is shown compressed at CR of 20 by wavelet transform in Fig. 2(c) and by JPEG in Fig. 2(d). At the resolution displayed, it is difficult to see much difference. However, in Figure 3 we see that when specific regions in the compressed and reconstructed sections are magnified (by a factor of 4), visible structural differences are evident in images compressed by both techniques. While all four images show pixellation, blocking is clearly visible in the JPEG-compressed images, especially in Fig. 3(b), while in the same regions, the wavelet-compressed images are smoother. Our preliminary results and current research activity suggest that it is possible that further investigation will eliminate JPEG as a suitable technique for data decorrelation, and that the wavelet transform will be a strong candidate for our design of a lossy compression scheme. DWT appears to allow relatively high CRs without the same degree or type of artifactual creation. Since relatively high CRs would be necessary for a practical and effective system to substantially improve the efficiency of storage and transmission of the Visible Human images, the investigation of wavelet transform applied to these images will continue. This technique applied to compression is still in an early stage of research, and has not yet been optimized for most image classes and definitely not for the Visible Human data, unique as this is in terms of texture complexity, color mapping and large size. An important initial objective is to select suitable filter coefficients, e.g., Daubechies 12, for the wavelet transformation. The transformation code employing these coefficients and suitable for 2048 x 1216 for each of the three color planes needs to be developed. Prior to applying this transformation, the 24 bit/pixel color images need to be separated in a preprocessing stage to 8 bit/pixel planes. Once the images are decorrelated and energy-compacted by the wavelet transform, they need to be quantized, the stage yielding the greatest degree of redundancy reduction. While uniform scalar quantization is simple to implement, vector quantization has been shown to outperform scalar quantization in terms of quantitative quality/distortion measures such as mean square error and peak signal-to-noise ratio. This is especially true when data is not completely decorrelated as in the three high frequency subbands resulting from each wavelet decomposition stage. There are several options in the selection of vector quantization technique though the LBG algorithm appears to be frequently used [Cosman, Da Silva, Linde, Mitra, Mohsenian, Pemmaraju, Wu]. Finally, following the quantization stage, further redundancy removal may be achieved by Huffman or runlength coding, both of which are information-preserving. In summary, the goal of this compression work is to investigate two approaches: one, a lossless approach reducing the interframe redundancy, and the other, a lossy approach employing a transform technique for data decorrelation and vector quantization for redundancy reduction. The advantage of the first is that expert evaluation of image quality is not necessary since the reconstructed image is the same as the original. The disadvantage is that CR will be low. To achieve substantial CR, we need to develop a lossy approach relying on a transform technique (DWT being the leading candidate). This approach starts with background removal followed by the application of the transform in which the raw data is transformed into a decorrelated form, a step which yields some compaction. The next stage, quantization, yields the largest amount of compression; and the final stage, runlength and Huffman coding utilizing repetition of numbers and statistics of the quantized data removes redundancy even further. 4. Communications Relevant Background We propose a research and development effort to investigate methods for faster delivery of medical image data, by means of both bulk file delivery methods and client/server applications, both on today's Internet and on technology likely to become available in the near future. The proposed effort is concerned with making more effective use of the TCP protocol, as explained in the following. Wide-area network delivery of large amounts of data is a topic of increasing interest in telecommunications. Technology being investigated for alleviating throughput bottlenecks created by the attempts to transmit massive amounts of data include (1) improvements in physical infrastructure of communications links, such as the implementation of optical fiber and high-speed satellite links with physical transmission capacity of hundreds of megabits per second (Mbps); examples include the ATDNet infrastructure being put in place in the Washington, D.C. metropolitan area with a optical fiber backbone capacity of 2.5 Gbps [ATDNet], and the NASA ACTS satellite High Data Rate communication links with initial capacity of 155 Mbps [Schertler]; (2) the development of novel methods for exploiting existing physical capacity; some of these methods involve the development of auxiliary devices for using the physical link in new ways: an example is the widespread work at the current time to design and deploy modems to allow the transmission of digital data over cable TV lines; another emerging method is the use of asymmetric transmission schemes: a low-bandwidth path, such as an ordinary telephone modem, is typically used to transmit requests for data, and the data is returned to the user over a high- speed link, for example, a direct satellite transmission [Friedman]; a similar scheme is the proposal to use Asymmetrical Digital Subscriber Line (ADSL) modems to allow the one-way delivery of data to the home at a rate of several Mbps over standard telephone lines; (3) the development of cell switching technology, pre-eminently ATM, with fast cell switching devices designed specifically for use with the cell transmission protocol; and (4) enhancements to transmission protocols, especially transport protocols, to allow for more efficient exploitation of the underlying physical link capacity. For the ISTO project we plan to focus on the transport protocol and its relationship to link performance. While much attention has been given to the emplacement of links with high physical capacity in building the National Information Infrastructure, the role of the transport protocol is also critical: this protocol defines the rules for reliably transmitting data packets, including the specifics of how packets are addressed, encapsulated in lower-level protocols, and prioritized; how transmission failure is detected and rectified with retransmitted data; how data flow is controlled; how data sequence numbering occurs; and how received data is acknowledged. The most widely-used transport protocol for Internet communication is TCP. The Transmission Control Protocol (TCP) originated in work sponsored by DARPA in about 1977-1979 and in 1980 became the transport protocol for ARPANET, which in turn became the backbone of the Internet. TCP was implemented on ARPANET using Internet Protocol (IP) as the delivery protocol, hence the common reference to TCP/IP as the method of data transmission on the Internet. In 1986 the National Science Foundation funded NSFNET, a new wide-area network backbone, which tied together the six NSF supercomputing centers and linked them to ARPANET. NSFNET also adopted TCP/IP protocols. By 1990 the Internet supported by this NSFNET/ARPANET backbone connected over 3,000 networks and over 200,000 computers. [Comer] By 1996 the number of connected computers had grown to 9.5 million. [Infoworld] It is safe to assume that most of these computers are using TCP communications. Transport protocols such as TCP are distinguished from packet delivery protocols, such as Internet Protocol (IP); delivery protocols perform simple packet delivery services; transport protocols add reliability to the delivery. Because the transport protocol is the protocol with which the user application typically interacts, it is conventionally represented as higher in the protocol stack. (Even though we are focussing on more efficient use of the transport protocol, the evolution of IP should be noted: the proposed "Internet Protocol Next Generation" (IPng), documented in RFC 1752 [Bradner] contains specifications for expanded addressability, including support for multicast - send to all addresses on a list - and "anycast" - send to the nearest address on a list; provisions for privacy and authentication; and quality-of-service features, including capability to assign delivery priority on a packet level; this feature is designed for multimedia or real-time support. It is estimated that the address space of IPng is large enough to assign, at a minimum, depending on how the addressing hierarchy is implemented, 1564 addresses for each square meter on the surface of the earth [Hinden]. To understand the role of transport protocols in packet-switched digital communications, the characteristics of the packet stream must be understood: data packets are routed from sender to receiver along a path which may traverse many intermediate routing computers, heterogeneous networks, and communications links. The potential for some degree of packet loss and corruption is great; some packets may be delayed en route and arrive out-of-order; even packet duplication may occur. Packet delivery protocols such as IP follow a simple best-effort philosophy in getting the packets to their destination; there is no verification that the data has been sent correctly or thatit has been delivered at all. IP maintains a header for the data packets which includes the Internet addresses of the sender and receiver, performs a checksum validity test on this header information, controls the time that the packet is allowed to "live" on the Internet, and controls fragmentation and reassembly of the packet if that is needed as the packet crosses different physical networks; but IP performs no validity tests on the data that is being sent. Validation of the transmitted data, and any necessary action to correct problems, is performed by the transport protocol: TCP implements data validation by performing a checksum operation on the transmitted data itself; any corrupted packets are discarded by the receiver; it corrects transmission problems by incorporating a scheme of positive acknowledgment with retransmission: as a packet is sent, a copy of the packet is placed on a retransmission queue, and a timer is started for the packet; if the timer expires without an acknowledgment for the packet being received, the packet is retransmitted. TCP tracks the transmitted data by assigning consecutive sequence numbers to each byte in the data stream; the sequence number of the first byte of data within a TCP packet is also referred to as the sequence number of the packet. TCP acknowledges received data by transmitting the sequence number of the last byte received plus one; that is, TCP sends the sequence number of the next expected byte. The acknowledgments are cumulative: if packets have been received out- of-order, the acknowledgments will only reflect the packets which have been received in a cumulative, ordered sequence with no gaps; if gaps occur in the sequence numbers of received packets, packets lying beyond the gaps will not be acknowledged until other packets arrive to fill the gaps. TCP also implements data flow control. This has two aspects: first, the data should be transmitted no faster than the receiver can accept it; second, an attempt should be made to detect network congestion; when congestion is sensed, data flow should be decreased; when congestion is absent, data flow should be increased. To effect data flow control, TCP uses "windows" on the sequence number spaces corresponding to the byte streams being sent and received. Sequence numbers to the left of the send window correspond to bytes that have been transmitted, for which acknowledgments have been received; sequence numbers within the send window are for bytes ready to transmit: they will be sent as fast as the host computer can send them, without waiting for any acknowledgments; sequence numbers to the right of the window may not be transmitted until the window slides to the right to include them. The send window slides to the right when acknowledgments are received for sequence numbers within the window. The TCP send window is illustrated in Figure 4(a). Note that TCP sends data in units of packets, but acknowledges data by using the sequence numbers of bytes in the data stream being sent. For example, in Figure 4(a), the receipt of the packet containing bytes 51-53 would be acknowledged by transmitting a 54 (next expected byte) back to the sender. On the receive end, sequence numbers to the left of the receive window correspond to bytes which have been received and acknowledged; sequence numbers within the receive window are for bytes the receiver is ready to accept; and sequence numbers to the right of the receive window are for sequence numbers the receiver is not yet ready to accept, until the receive window slides to the right to include them. The receive window size is a measure of the amount of buffer space that the receiver has currently available to receive data. The receive window slides to the right as data is received into and emptied from this buffer space. The TCP receiver transmits its current window size to the sender in the TCP header. The sender uses this receive window size as one of its key parameters in controlling data flow. The second aspect of TCP data flow control is congestion-related. The sending TCP maintains a limit called the congestion window which, absent any packet loss, is the same size as the receive window. When the sender's timer expires for a transmitted packet without that packet being acknowledged by thereceiver, the sending TCP reduces the size of the congestion window by one-half, down to a minimum of one packet. The assumption is that failure to receive a packet acknowledgment is due to network congestion, hence to avoid contributing to further congestion, the rate of data transmission should be decreased. TCP maintains a dynamically-computed estimate of the round-trip time (RTT) for data transfer; when the RTT decreases, it assumes less congestion on the network, and will increase the congestion window. At any time, the send window behaves as if its size S is given by [Comer]: S = minimum(receive window, congestion window) The larger the send window, the more data can be sent to the network, hence the greater throughput potential. There are two cases of interest: (1) the contention-free environment, corresponding to a simple two-point network (i.e., dedicated transmission link); and (2) the contentious environment, corresponding to complex networked communications, such as the Internet. Contention-free environment. In this case, we assume there is no issue of congestion. The congestion window will be sized the same as the receive window. Hence, the limiting factor for S becomes only the receive window size. In order to maintain use of a TCP channel at a specified bandwidth (throughput), the following relationship must hold: receive window >= bandwidth * delay where delay is the round-trip time mentioned above. For example, in order to achieve a throughput of 50,000 bytes/second over a link with a 200 millisecond delay, the receive window must be at least 10,000bytes in size. In current TCP, the receive window size is limited to 216-1. This limitation, commonly called the "64K window limit", results from the fact that the receive window size is passed to the sender in the TCP header, where the data field allocated to hold the window size is only two bytes in length. This has serious implications for network transmissions where the transmission distance, and hence the delay is great (long), and the desired bandwidth is high (fat). These so-called long, fat networks (LFNs) are directly impacted by the receive window limitation in current TCP [Jacobson]. The achievable bandwidth in current TCP may be calculated by bandwidth <= (216-1)/ delay. For example a transmission with a network delay of 50 milliseconds will achieve a throughput limited by about 1.3 million bytes/second, regardless of the underlying physical capacity of the link. Institutions such as NLM desire to transmit many megabytes of data rapidly across long distances; these are precisely the class of users suited to LFNs, and also those for which the TCP window limitation becomes a potential problem. This problem has been known for years in the Internet research community and was addressed in a set of proposals which were incorporated into RFC 1323, "TCP Extensions for High Performance" [Jacobson]. This RFC includes specifications for allowing TCP to operate with a receive window up to size 230. The new receive window limit is specified by implementing a new TCP option: Window Scale. This option, which may be invoked only when the connection is established, allows the application of a scale factor to the receive window size transmitted in the TCP header. The length of the window size field in the TCP header remains unchanged in the new specifications; just as in conventional TCP, it is two bytes. The RFC 1323 specifications were incorporated into an experimental TCP which was tested on a DS-3 (44.7 Mbps) wide area network with delay comparable to a transmission across the continental United States; researchers reported achieving 89% of link capacity, using a window size of 512 kilobytes [Villamizar]. Recently, these specifications have been incorporated into commercially-available TCP software, in particular a Sun Microsystems product called TCPLFN [Sun Microsystems]. Use of this software has already been carried out by one researcher, who has reported obtaining 90% of theoretical link throughput using a 100 kilobyte receive window when transmitting 20 megabyte digital mammography images over a T-1 geosynchronous satellite link [Barnett]. The NLM Communication Engineering Branch (CEB) has conducted experiments on a contention-free satellite link using our multisocket transmission method developed inhouse. Visible Human digital color images (7 megabyte file size) have been transmitted between NLM and the Laboratory for Radiological Informatics at the University of California at San Francisco. Figure 5 shows the transmission times observed for a 100-transmission run in 1996. For comparison, a line showing the approximate observed FTP rate across this link has been added. Due to the long transmission times required for FTP on this link, only 10 runs were made. The mean for these runs is plotted as "approximate FTP time" in the figure. For the multisocket data collection, 12 TCP channels or socket-pairs were used. (Initial testing was done to determine throughput versus number of channels; 12 channels were determined to provide maximum throughput on this link.) For data collected to date, the NLM tests indicate achieving approximately 80% of the T-1 link capacity. This multisocket approach has been independently implemented by researchers at Ohio University, who have modified SunOS FTP source code to build multisocket capability directly into FTP. They have reported achieving 91% of T-1 link capacity over a geosynchronous satellite link [Allman]. Contentious environment: The contentious environment is not as susceptible to simple analysis as the above. Empirical data collections on the Internet show that throughput very often falls well below the barrier imposed by the 64K window limit. The question of whether this degraded throughput is correlated to TCP congestion control algorithms remains unanswered: this would require observing TCP dynamically-changing internal parameter values, such as the setting of the congestion window. What we have ascertained is that the NLM multisocket transmission method outperforms conventional TCP transfer methods, in particular FTP, on several Internet links, in three series of tests. This data was taken on transmissions between NLM and the University of Arizona (Tucson), Texas Tech University (Lubbock), and the NASA Lewis Research Center (Cleveland). Data collections of durations ranging from 24 hours to 29 days were made. For Test Series 1-2 a 5 megabyte digitized cervical x-ray was transmitted; for Test Series 3, a 7 megabyte Visible Human digital color slice image was transmitted. For each collection, the image file was repeatedly transmitted from the remote site to NLM at small (10-15 minute) time intervals, using the multisocket method. Also, at the same time intervals, but offset from the multisocket transmission times, the same image file was transmitted using FTP or a similar 1-socket-pair transfer. Conventional TCP transmission uses one pair of communication end-points--"sockets"--to establish one TCP channel. Transmission times were logged, and statistics of the results were computed, including mean, median, and standard deviation. In every case, the average transmission time using the multisocket method was significantly shorter than for FTP. The speed-up ratios of multisocket transmission as compared to FTP for the first test series ranged from 1.7 to 3.5, depending on the particular link and data collection interval [Long 1994]. For the second test series, the speed-ups ranged from 1.6 to 2.7 [Long 1995]; and in the single 1996 Internet data collection, the speed-up ratio was 2.1. For Test Series 1, which included the longest-duration collection, confidence intervals for the mean transmission time values were computed, and the multisocket intervals showed clear separation from the FTP intervals at a 95% level of confidence. For example, the first data collection from Tucson had a multisocket confidence interval of 6 seconds, centered on a mean of 107; for comparison, the single-socket confidence interval was 12 seconds, centered on a mean of 280. Figure 6 shows the results of Test Series 3, a 24-hour data collection from the University of Arizona to NLM. For each hour of the day, the mean transmission time (for the transmissions at 0,15,30, and 45 minutes after the hour) is plotted for the multisocket method and for FTP. Figures 7(a-b) summarize the results for Test Series 1. Figure 7(a) is a summary of comparative mean transmission times, and Figure 7(b) is a summary of corresponding data rates. The reference "Tucson-1" in the figures refers to a Sun Sparc 2 workstation running SunOS 4.1.3, while "Tucson-2" refers to a Sun Sparc 20 workstation running Sun Solaris 2.3. As a reference point, the physical capacity of a T-1 link (such as this was) is 192 kilobytes/second. For the results shown here, five channels were used for the multisocket data collection. (Data collections were also made at 10 and 15 channels, which in some tests yielded a small incremental improvement in throughput.) Figures 8(a-f) show detailed results for Test Series 2, in terms of histogram plots and mean transmission times versus hour of day. Summary comparisons of multisocket and FTP for Test Series 2 are shown in Figures 9(a-b). Although the multisocket method has been empirically justified as a faster method to transmit files, the mechanism by which it achieving the performance improvement remains an area for investigation. It may be the case that TCP is shrinking the congestion window inefficiently: when it detects a lost packet, it cuts the congestion window in half, resulting in a drastic decrease in throughput. This may result in under-utilized network bandwidth, which would then be usable by the multisocket method. Figure 4(b) illustrates the multisocket capability to exploit multiple TCP channels for data transmission; as shown in the figure, the multisocket method may continue transmitting on one of its TCP channels, while another of its TCP channels may have transmissions stopped while waiting for that channel's send window to move. Also, the effects of multisocket transmission on other users sharing common routers is not well understood. In the early ARPANET, it was observed that host computers can dominate routers to the exclusion of other users [Nagle]. Internet routers attempt to control congestion by transmitting Internet Control Message Protocol (ICMP) source quench messages to hosts that are sending data at a faster rate than the router can handle; hosts are expected to respond by lowering data rates; if they do not, congestion continues at the router. Router congestion issues have been the subject of considerable discussion and analysis in the Internet community and are documented in Internet RFCs [Braden, Mankin]. The effect of multisocket transmission on the rest of the network, including whether any overcongestion caused by multisocket transmission would be properly handled by ICMP control, is a matter for investigation. Methods and Procedures Two available methods have been identified as candidates for achieving better throughput than is available with current TCP: (1) the NLM multisocket method and (2) the Sun TCPLFN implementation of TCP for high performance. We propose an investigation to assess the relative merits and performance of these two methods for bulk transfer of medical image data and for client/server medical applications which transfer medical images. The investigation will include a performance assessment across Internet links, across the inhouse local area network, and across any wide-area links of opportunity. We also propose an investigation of TCP bulk file transfers and client/server applications across an inhouse ATM link. We have divided our proposal into four logical parts, as given in the following: (a) For the bulk file transfers, we propose to compare:(1) multisocket using conventional TCP
versus FTP with conventional TCP; The complete range of image sizes in the Visible Human data set will be used, with emphasis on efficiently transferring the larger images. A remote transfer site located at significant distance (nominally, California) from NLM will be used for the transfers. We have previously established a collaboration in transmission tests with the University of California at San Francisco and Texas Tech University in Lubbock and consider these as candidate sites for the transmissions. (b) For the client/server testing, we will collect data on the performance of the NLM-developed
Medical Information Retrieval System (MIRS). MIRS is a Motif/X-window client/server system
which incorporates capability to use either the multisocket method or conventional (1-socket-pair)
TCP transfers for image transfers. This makes MIRS a good candidate for comparison of
client/server performance when the underlying transmission method is varied. We propose to run
MIRS using (c) As an evaluation of future network technology, we further propose to assess the performance of multisocket transfers versus FTP over an in-house ATM network. For this testing two CEB Sun workstations equipped with Sun ATM cards will transfer medical images using a Cisco Lightstream 100 ATM switch. MIRS will again be run over this ATM link as a first-level assessment of client-server performance technology over ATM. (d) If the research into the multisocket method conducted in this investigation warrants, we then propose to develop an operational multisocket client/server file transfer system. To evolve this method from an engineering/data collection system to the operational level, several steps are necessary: the server must be designed to support multiple clients; the client and server must work together to support interactive clients, each of which may be requesting files or directory listings, or configuring the number of channels to use; the server must control the loading it is placing on the server machine, so as not to overconsume system resources, such as entries in the system process table; robust error recovery must be incorporated into both the client and server. The client must exist in the form of a code library with a C callable Application Program Interface (API); and both the client and server must be coded for portability to any standard Unix platform. 5. Evaluation Considerations Compression The development of a suitable compression scheme relies on how well the system performs with a specific image set. Common evaluation criteria include: compression ratio performance, image quality, scaleability. While CR is a quantitative figure, it is difficult to quantify image quality. Among objective measures of image quality are: L1 error (average of the absolute value of pixel to pixel error), L2 error (average of the root of the square of the pixel to pixel error), RMSE (root of the mean square of the error), PSNR (peak signal to noise ratio, which is the RMSE divided by the dynamic range of the data expressed in decibels), and maximum error. Other than the last one, all the other error measurements measure global image accuracy at the expense of local accuracy. Maximum error is sensitive to local error (small but important features) and has been reported to correspond to an observer's intuitive assessment of image quality [Cohen]. In the final analysis, however, there is no substitute for observer tests. Quantitative measures can only serve as guidelines for quality checks. No such measure has yet been able to consistently predict image quality as determined by sophisticated observers, i.e., subject matter experts. Nevertheless, as a precursor to such expert evaluation, we will minimize the maximum error measurement as a consistency check on the lower bound of image quality and as a relative assessment technique toward the selection of the system parameters in the lossy compression scheme. Communications Evaluation considerations for parts (a-c) of the work proposed in Section 4.2 are given below. Since part (d) is development work only, evaluation is not included. (a) The bulk file transfer methods will be compared for achievable throughput, ease of use, stability, and side effects on other users on the host machines and the network. For the multisocket method, effect on other network users will be assessed by a first-level test done inhouse to investigate the effects of the multisocket method on other users who are routing traffic through a router shared with the multisocket traffic. We will also conduct Internet multisocket tests where we establish the Internet route of our transmissions and observe network traffic for the presence of messages from Internet routers requesting decrease in our data transmission rate. For the inhouse test, we will use the Cisco operating system (i.e. the router operating system) capabilities to record performance data for the router, including input and output queue sizes and buffer utilization within the router. Of particular interest is whether buffers are dropped due to the router becoming overloaded during the test. We will vary both the number of connections used by the multisocket method and the receive window size used for each connection; we will thus attempt to evaluate the impact on the router of the number of multisocket connections independently of the throughput size on each connection. We will use network sniffer hardware to record performance of other users of the router by tracking the number of retransmissions required by those users, both in the presence of multisocket traffic on the router, and without such traffic. We will also record the effect of other user traffic in generating retransmissions on the multisocket channels. For the Internet test, we will use the Unix traceroute capability to determine the routers along which our multisocket test data is transferred. We will then use network sniffer hardware to filter out any packets being transmitted back from these routers which contain ICMP source quench messages. If such messages are detected we will perform an analysis to determine whether our sending TCP channels properly scale down data flow, using internal TCP algorithms, to adapt to the congested environment, or whether multisocket application code must be adapted to deal with the congestion. (b) For the client/server performance evaluation we will exercise the MIRS program to make typical database queries and collect performance data on user response and key internal processing steps, such as the retrieval and display of image files, the retrieval and display of text information from the data base, and internal transactions of the X-windows system. We will capture the required performance data by incorporating our own timing code into MIRS and by using the Unix truss function ("trace system calls and signals") to isolate X-windows transactions. (c) For the ATM tests, we will evaluate TCP/IP over ATM versus TCP/IP over Ethernet by measuring achievable throughput for the bulk file transfers, and by repeating the evaluation for step (b) for the client/server evaluation. All statistical performance data collected will include mean, median and standard deviation measurements. 6. Project Schedule Compression Year 1: (1) Develop prototype system for lossless technique (2) Develop prototype system for lossy technique Year 2: Develop final (target) system for lossy technique Communications Year 1: For the step (a) work, we propose to set up the required experimental infrastructure and conduct all the planned performance comparisons. This will include establishing an Internet collaborator, acquiring and installing TCPLFN at each end of the Internet link to that collaborator; and planning, executing, and analyzing the required suite of tests. This will also include carrying out the inhouse and Internet tests on the impact of the multisocket algorithm on router congestion. We also propose to carry out the step (b) work in evaluating client/server performance over TCP and TCPLFN. Finally, we propose to conduct the step (c) work in the evaluation of bulk file transfers and client/server applications over ATM. At the end of year 1, we plan an overall evaluation of the multisocket method as a viable means of transferring data in the Internet environment, as compared to TCPLFN. This will include the evaluation for bulk file transfers and also for interactive, client/server applications. For the client/server work, we expect to learn techniques for more optimal program coding for performance, including possible performance bottlenecks created in use of X-window library calls. We further plan an overall evaluation of TCP over our inhouse ATM. Year 2: For the step (a) work, if the year 1 evaluation warrants, we propose to develop the multisocket method into an operational, robust system for Internet file transfer. For the step (b) work, we will incorporate any new design or coding techniques into the MIRS application and repeat Year 1 tests for evaluation of the modified application. For the step (c) work, we will attempt to extend the evaluation of TCP over ATM to include experiments on a regional (such as ATDNet) or wide-area network as access becomes available. 7.Summary This project is proposed as a timely effort to address the problem of storing, transmitting or distributing the Visible Human dataset. One part of the project deals with image compression, the goal being to develop two systems, one a lossless technique and the other a lossy technique, optimized for the image characteristics of the dataset. The lossless technique relies on the correlation of pixels in adjacent slice images. In the case of the lossy system which promises relatively high compression ratios, what we propose is a scheme that partly fits into the conventional general model: the three stages of signal decomposition, quantization and lossless coding. However, to exploit the unique characteristics of the Visible Human image dataset, our proposal adds an additional preprocessing stage to both techniques, viz., to remove the uniform background in the individual slices. The second part of the project is to investigate communications techniques to increase the data transmission rates over the Internet by addressing the limitations of the TCP protocol. This involves investigating advanced TCP approaches currently being researched elsewhere, as well as a multisocket transmission technique developed inhouse. 8. References Adelson EH, Simoncelli E, Hingorani R. Orthogonal pyramid transforms for image coding. Proc. SPIE Visual Communications and Image Processing (1987); 845: 50-8. Ahmed N, Natarajan T, Rao KR. Discrete cosine transform. IEEE Trans. Computers. C-23:90-3 (Jan. 1974). Allman M, Ostermann S, Kruse H. Data transfer efficiency over satellite circuits using a multi- socket extension to the File Transfer Protocol (FTP). Proceeedings of ACTS Results Conference; NASA Lewis Research Center, Cleveland, OH, September 11-13, 1995, Network section. ATDNet. ATDNet World Wide Web home page. http://www.atd.net/atdnet.html, undated. Barnett BG, Dudding KE, Abdel-Malek A, Mitchell RJ. Satellite teleradiology testbed for digital mammography. Proc. SPIE Medical Imaging '96, Newport Beach, California, February 10-15, 1996. Braden R, Postel J. Requirements for Internet gateways. Internet RFC 1009, June 1987. Bradner S, Mankin A. The recommendation for the IP next generation protocol. Internet RFC 1752, January 1995. Brower B. NITF BWC Study Phase I Final Report. Eastman Kodak Co., May 1990. Brower B. Low-bit rate image compression evaluations. Proc. SPIE, Orlando FL, April 1994. Cohen AM, Resnikoff HL. Image compression for radiology and telemedicine. Proc. SPIE 2298 (1994): 304-15. Comer DE. Internetworking with TCP/IP, Volume I, Principles, Protocols, and Architecture. Prentice-Hall, Englewood Cliffs, New Jersey, 1991. Cosman PC, Gray RM, Vetterli M. Vector quantization of image subbands: A survey. IEEE Trans. Image Processing 1996; vol. 5; no. 2: 202-25. Cox GG, et al. The effects of lossy compression on the detection of subtle pulmonary nodules. Med. Phys. 23 (1), January 1996, pp. 127-32. Da Silva EAB, Sampson DG, Ghanbari M. A successive approximation vector quantizer for wavelet transform image coding. IEEE Trans. Image Processing 1996; vol. 5; no. 2: 299-310. Daubechies I. Orthonormal bases of compactly supported wavelets. Comm. Pure Appl. Math. (1988); 41: 909-96. Dorize C, Villemos LF. Optimizing time-frequency resolution of orthonormal wavelets. Proc. IEEE Int. Conf. ASSP (1991); 2029-32. Friedman D, Gupta S, Zhang C, Ephremides A. The ACTS experiments program at the Center for Satellite and Hybrid Communication Networks. Proceeedings of ACTS Results Conference; NASA Lewis Research Center, Cleveland, OH, September 11-13, 1995, VSAT section. Goldberg MA, et al. Application of wavelet compression to digitized radiographs. AJR 1994; 163: 463-468. Hinden RM. IP next generation overview. http://playground.sun.com/pub/ipng/html/INET-IPng-Paper.html#CH1, May 14, 1995. Ho BKT, Chao J, Zhu P, Huang HK. Design and implementation of full-frame, bit-allocation image-compression hardware module. Radiology 1991; 179: 563-7. Infoworld. Enormous growth in Internet hosts. Mar. 25, 1996, 74. Jacobson V, Braden R, Borman D. TCP extensions for high performance. Internet RFC 1323, May 1992. Lee H, et al. Subjective evaluation of compressed image quality. Proc. SPIE, Image Capture, Formatting and Display; 1992; Vol. 1653: 241-51. Linde Y, Buzo A, Gray RM. An algorithm for vector quantization design. IEEE Trans. Comm, Jan. 1980; COM-28: 84-95. Long LR, Berman LE, Thoma GR. Client/Server design for fast retrieval of large images on the Internet. Proc. 8th IEEE Symposium of Computer-Based Medical Systems (CBMS'95), Lubbock TX, June 9-10, 1995; pp.284-291. Long LR, Berman LE, Neve L, Roy G, Thoma GR. An application-level technique for faster transmission of large images on the Internet. Proc. SPIE Multimedia Computing and Networking 1995, Vol. 2417, pp. 116-129, San Jose, CA, February 6-8, 1995. Mankin A, Ramakrishnan K. Gateway congestion control survey. Internet RFC 1254, August 1991. Mitra S, Pemmaraju S. Adaptive vector quantization using an ART-based neuro-fuzzy clustering algorithm. Invited paper at ICNN'96, June 1996, Washington, DC [to appear]. Mohsenian N, Shahri H, Nasrabadi NM. Scalar-vector quantization of medical images. IEEE Trans. Image Processing 1996; vol. 5; no. 2: 387-92. Morris JM, Akunuri V, Xie H. More results on orthogonal wavelets with optimum time-frequency resolution. Proc. SPIE Conference on Wavelets, Orlando FL, April 1995. Nagle J. Congestion control in IP/TCP internetworks. Internet RFC 896, January 6, 1984. Pemmaraju S, Mitra S, Shieh Y, Roberson G. Adaptive vector quantization with fuzzy distortion measure for image coding. Proc. SPIE Medical Imaging '96 Conference (1996); Vol. 2707. Pennebaker WB, Mitchell JL. JPEG: Still image data compression standard. New York: Van Nostrand Reinhold, 1993; 314. Pugh W, Boyer G. Broadband access: comparing alternatives. IEEE Communications, Vol. 33, No. 8, August 1995, 34-46. Sayre J, et al. Effect of data compression on diagnostic accuracy in digital hand and chest radiography. Proc. SPIE, Image Capture, Formatting and Display; 1992; Vol. 1653: 232-40. Sayre J, et al. Subperiosteal resorption: effect of full frame image compression of hand radiographs on diagnostic accuracy. Radiology 1992; 185: 599-603. Schertler RJ. ACTS experiments program. Proceeedings of ACTS Results Conference; NASA Lewis Research Center, Cleveland, OH, September 11-13, 1995, General Session section. Sun Microsystems. CONSULT-TCPLFN data sheet. Sun Consulting, Mountain View, California, February 1996. Villamizar C, Song C. High performance TCP in ANSNET. Computer Communications Review, Vol. 24, No. 5, October 1994, 45-60. Wang J, Huang HK. In-line structure lossless digital mammographic image compression. Proc. SPIE Medical Imaging '96 Conference (1996); Vol. 2707, Paper 48. Wu X. YIQ vector quantization in a new color palette architecture. IEEE Trans. Image Processing 1996; vol. 5; no. 2: 321-9. |
|||||||
CEB Home | CEB Projects | Related Work | Publications |
Repositories | NHANES | Site Index
URL: http://archive.nlm.nih.gov/proj/isto.php
|
||||||||