K-pacs error on retrieving large files from remote PACS

  • Hi. I am using K-Pacs 1.0.1 and generally it works well. Up to now all the transactions were over fast local LAN. Now I am trying to retrieve files from remote CONQUEST (with cable modem approximately 2.5 Mbits speed). Small files are OK, but for bigger files (> 100MB) it seems K-Pacs times out, but I don't know where and how to set the timeout. I don't see it in the ini file. The strange thing is that after about 5 minutes K-Pacs gives an "Error: retrieve failed" and stops (I assume it closes the association). But the remote CONQUEST keeps sending the data, and sometimes the file eventually ends up in the K-Pacs local database (several minutes after K-Pacs stops). Of course the viewer screen is dead by then, but I can go to the database and view the file. I don't know what is happening. Sometimes I get the file, even after K-Pacs seems to give up, and sometimes I don't. Could someone help me understand how K-Pacs retrieve works?


    Also, I don't know why K-Pacs uses close to 100% CPU while retrieving. What is it doing? Does it continuously poll on the socket for data?


    Thanks for any help
    Mani

  • K-PACS Store SCU ask the remote server to Move the selected study to K-PACS Store SCP (in another association), after that it waits for the Move operation to finish.
    But if it takes more than five minutes and there is no activity in the SCU association, the socket timeout will kill the association. And no, the socket timeout is not user-configurable.


    Maybe you can set K-PACS Store SCP to use jpeg lossless for this big images, are they US multi-frame? You can try jpeg lossy.
    By default K-PACS will un-compress them on receiving, but this will take a lot of CPU usage, best will be to save them compressed.


    Regards, Rafael.

  • Quote from RafaelS

    K-PACS Store SCU ask the remote server to Move the selected study to K-PACS Store SCP (in another association), after that it waits for the Move operation to finish.
    But if it takes more than five minutes and there is no activity in the SCU association, the socket timeout will kill the association. And no, the socket timeout is not user-configurable.


    Maybe you can set K-PACS Store SCP to use jpeg lossless for this big images, are they US multi-frame? You can try jpeg lossy.
    By default K-PACS will un-compress them on receiving, but this will take a lot of CPU usage, best will be to save them compressed.


    Regards, Rafael.


    Thanks for the response. Now I have more questions! First, yes, these are multiframe images (over 250 slices).


    It seems to me that there is activity in the SCU association but the transfer rate is slow, so it takes longer than 5 minutes. Does this mean that any transfer that takes more than 5 minutes will be interrupted? It doesn't make sense. I should be able to receive images as long as it takes, if there is no inactivity, right? I still don't understand why *sometimes* even after 5 minutes, when K-PACS stops and gives error, the transfer continues for few more minutes and eventually the image shows up in the imagebox, but not in the viewer screen that's opened. Also I don't understand why K-PACS takes over the processor while the transfer is happening.


    As for compression, I am totally unfamiliar with how it works. How do I set Store SCP to use Jpeg? Don't the images have to be compressed at the source? My remote CONQUEST has them as uncompressed.


    Thanks for your help

  • Yes, there is activity but in the SCP association, not in the SCU association, they are completely independent. That is why even if the SCU association fails, the SCP association keeps going. We will have to check the timeout for this cases.


    Can't tell you for certain why the processor gets loaded, maybe you should try K-PACS 1.5 instead. Conquest uses DMCTK dcmcjpeg for jpeg compression, In K-PACS you need to select: prefer JPEG lossy or JPEG lossless in the Server Configuration. and add -nd (no decompression) to the Additional Parameters.


    JPEG lossless compression can reduce size 3:1 and JPEG lossy can reduce it 10:1 with some loss in image quality.


    Regards, Rafael


  • Thanks, Rafael. Great help. I am beginning to understand the process. I will try compression after I figure out how to resolve the more trivial problems that I'm having! I downloaded the 1.5 version and still have the following questions.


    1) I understand the SCU vs. SCP. It seems that SCU (k-pacs.exe, not kpserver.exe) totally holds the processor until the image is fully retrieved (for smaller images) or it stops after the 5 minute timeout. From your response I understand that when I double click on a study, and while waiting for it to be retrieved, k-pacs.exe shouldn't be utilizing the CPU that much, right? I have several machines with K-PACS running and all behave the same way. I am very puzzled. If anyone else has the same experience maybe they can explain what is going on.


    2) In the "local setting" window I tried to select "just retrieve (don't show" option, but it doesn't accept it. I can select the other two options but when I select the don't show one it doesn't allow me to save. I would like to avoid bringing up the viewer automatically when I retrieve an image. Is that option locked or for some reason not selectable?


    Thanks again for your help.

  • Quote from RafaelS

    Conquest uses DMCTK dcmcjpeg for jpeg compression, In K-PACS you need to select: prefer JPEG lossy or JPEG lossless in the Server Configuration. and add -nd (no decompression) to the Additional Parameters.


    Regards, Rafael


    I tried setting JPEG lossless and lossy in K-PACS, but it seems like it didn't affect the tansfer syntax . In both cases it remaind 1.2.840.10008.1.2. Do I have to do something on the CONQUEST side to accept JPEG? I don's see any configuration setup for it in CONQUEST UI. If I set prefer JPEG on K-PACS shouldn't it be enough?


    Thanks

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!