DICOM @ OFFIS

Discussion Forum for OFFIS DICOM Tools - For registration, send email with desired user name to the OFFIS DICOM team
It is currently Sun, 2017-04-23, 06:32

All times are UTC + 1 hour




Post new topic Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Mon, 2011-07-11, 04:26 
Offline

Joined: Sun, 2010-05-02, 04:07
Posts: 5
i have a task: transfer 2000 CT dicom images in 8 secends in 1G network!

i have tried my best to do this.now the best resualt is 30 secends with multi dicom transfer .

now i have a new thinking : convert the series images of the 2000 dicoms to a dicom-mpeg2 file,so that can decrease the times of parse dicom. and can decrease the size of the total file with inter-frame compress.

do you have other method to do this. help me ,thank you very much.

i will mark and look this topic later~


Top
 Profile  
 
 Post subject:
PostPosted: Mon, 2011-07-11, 10:00 
Offline

Joined: Mon, 2007-09-03, 10:53
Posts: 99
Location: Trondheim, Norway
How big is each CT image? If you suppose each is 500k uncompressed (not unusual), then simply applying zip compression would reduce them sufficiently that bandwidth should not be a problem. JPEGLS compression would be even better.

However, you will need to avoid the DICOM transfer protocol, since it is grotesquely inefficient.


Top
 Profile  
 
 Post subject:
PostPosted: Mon, 2011-07-11, 15:37 
Offline
DCMTK Developer

Joined: Tue, 2011-05-03, 14:38
Posts: 1805
Location: Oldenburg, Germany
Quote:
However, you will need to avoid the DICOM transfer protocol, since it is grotesquely inefficient.

I'm sorry but I don't agree. It's mainly a question of the implementation / configuration. Many systems were not designed for transferring huge amounts of data / objects (sometimes because of historical reasons). E.g. asynchronous communication might be a good idea ...

The following blog posting might be interesting in this context: http://dclunie.blogspot.com/2011/06/fra ... oblem.html

Here's one of the key sentences: "The bottom line is probably that the protocol used is less important than the architecture and implementation details on both end, and in comparing performance claims for specific commercial implementations, one needs to be sure one is comparing apples with apples rather than oranges."


Top
 Profile  
 
 Post subject:
PostPosted: Tue, 2011-07-12, 02:33 
Offline

Joined: Sun, 2010-05-02, 04:07
Posts: 5
Quote:
The following blog posting might be interesting in this context: http://dclunie.blogspot.com/2011/06/fra ... oblem.html



sorry,i'm a chinese ,i can't access this website.
perhanps our govement has forbiden this website......

so ,please copy the content of this link to there,i want to look at it .

other,my test dicom images is like these: 512K,512*512, and they will be some huge series . now i got a best test resualt with jpeg-lossless compress and multi-thread-dicom-transfer. but only be in 30 secends. i want to konw how can i transfer these 2000 CT in 8 secends.


Top
 Profile  
 
 Post subject:
PostPosted: Tue, 2011-07-12, 08:00 
Offline
DCMTK Developer

Joined: Tue, 2011-05-03, 14:38
Posts: 1805
Location: Oldenburg, Germany
Quote:
so ,please copy the content of this link to there,i want to look at it .

You should ask the author of this blog post, David Clunie, whether he can send the text to you (email: dclunie/at/dclunie/dot/com). I will not copy the text to this forum because of copyright reasons.

Quote:
i want to konw how can i transfer these 2000 CT in 8 secends.

I never tried that, but using an asynchronous DICOM communication with an appropriate PDU size and TCP configuration as well as a short list of presentation contexts should be a good starting point. A transparent ZIP compression (Deflated Transfer Syntax) might also be helpful, unless the images are already compressed.


Top
 Profile  
 
 Post subject:
PostPosted: Tue, 2011-07-12, 13:59 
Offline

Joined: Mon, 2007-09-03, 10:53
Posts: 99
Location: Trondheim, Norway
J. Riesmeier wrote:
Quote:
However, you will need to avoid the DICOM transfer protocol, since it is grotesquely inefficient.

I'm sorry but I don't agree. It's mainly a question of the implementation / configuration. Many systems were not designed for transferring huge amounts of data / objects (sometimes because of historical reasons). E.g. asynchronous communication might be a good idea

The problem is that the DICOM transfer protocol was not designed in a way that allows you to implement it efficiently. Too many useless layers of abstraction getting in the way. On a modern OS, you will want to try very hard to utilize zero-copy semantics to avoid moving buffers around and stream everything in as few operations as possible. DICOM, however, really wants everything hacked into arbitrary pieces and encourages re-conversion rather than a streamlined workflow. (Who thought it was a good idea to add a packet interface on top of a stream-oriented protocol (TCP), when you want to interpret it as a stream again on receipt anyway?)

What does all the abstraction buy you in the end? There is no support for transactions, caching, redirection, authentication, or load balancing. Reporting and error handling is anywhere from weak to non-existent.

Sorry about the rant. I have been experimenting a bit with the protocol lately, and it has not been pleasant ;-)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: Bing [Bot] and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group