Posts by mahnaz.x

    Hi


    I have searched the forum and have asked this question before, but haven't received any answer yet.


    When retrieving images from PACS, "kpacs.exe" (not "kpserver.exe") takes over the CPU until the transfer is completed. This happens in every version of K-PACS that I have used, and I don't understand it at all. I thought that "kpacs.exe" is the StoreSCU that sends the retrieve command and "kpserver.exe" the SCP that receives the image in another association. Why does my task manager show kpacs.exe fully loading the CPU during the transfer? Shouldn't it be just waiting to get a response or something? What is it doing during the transfer? Is it continuously polling on a socket?

    I will very much appreciate if someone clarifies this for me, because as is, there is very little that can be done while K-Pacs is retrieving a large image, and it's NOT because the receiving task (kpserver.exe) is using the CPU.


    With many thanks,
    Mani

    Quote from thatch


    However, I have installed ver 1.5 but am really not sure what changes have been made. I was hoping for more annotation functionality.


    The one thing I've noticed so far is that when I click the server admin button, CPU usage goes to 100% due to k-pacs.exe.


    I have the same experience with k-pacs.exe and CPU usage, and have searched and haven't found any explanation yet. In my case, both version 1.5 and 1.0.1 fully load the CPU when I click on server admin, as well as when I double click on an image to be retrieved from the PACS. The CPU doesn't get released until the whole image is retrieved. If anyone can explain this behavior I appreciate it.

    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


    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

    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

    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

    Thanks for your quick response. But when I go to the ServerAdmin Tool and stop the server, the "DIR" field is locked and I cannot change it. I can change AET and PORT fields, but not DIR. When I go to the INI file and change the imagebox, the changes are saved in the file, but when I restart KPACS it gets set back to the default again. The only way has been to uninstall KPACS and reinstall it with new imagebox directory. I am using v 1.0.1


    Thanks again...

    Hi


    I am new to Kpacs. I've configured 2 instances on two systems. On both systems I can upload images to our PACS database. On one system I can query and download them to imagebox. But on the other, I can upload and query, but when I click to view, a black screen shows up. I don't think I have configuration problems because I can send images.


    Another thing is that on the system that I can't download, the "Network" tab ONLY shows the first server. So I had to edit Kpacs.txt and move "Conquest" down, and my server up, in order to be able to access it. Kpacs.txt is updated when I add a server, but it doesn't show up on the list.


    Thanks for your help.