This is an issue with K-PACS and PresentationState Objects (PR). Currently they are not supported and will caused troubles. You could disable PR support in Conquest if you don't need them.
Next version will ignore PR files (iQ-View already does so)
Regards,
Andreas
glad you find K-PACS useful.
We never tried to run K-PACS under Windows Terminal Server but it might work. Although database is text file based, access to it is controlled by flags (e.g. ShareDenyWrite) that should prevent conflicts.
Regards,
Andreas
Quoteas Matt points out, I also would use K-Pacs for query and retrieve and transfer studies to other machines cause you can select by time range and modality, which is not possible with the conquest gui.
Well, the conquest GUI also supports time range and modality query, you only have to know how...
Time range query is possible at study level only with DICOM conformant format. eg. "20071010-20071011" for one day or "-20071011" for all studies until a date or "20071011-" for all studie from a date.
Querying for modalities in study is also possible at study level. Note, if you go down and want to query Series and Image level you allways have to specify the index fields (e.g. StudyUID on series level and StudyUID and SeriesUID on image level)
Regards,
Andreas
Ps.: but it is probably more convenient to use K-PACS anyway...
The problem with these images is the BigEndian transfer syntax. Although K-PACS can read BigEndian it fails with converting pixel data when they are 3*8bit encoded (24bit). 16bit and 8bit will display fine.
I will try to fix this bug in the next version.
Regards,
Andreas
We tried it with Vista Home Premium and did not find any problems so far.
Regards,
Andreas
If your application treats these images as different sets although StudyInstanceUID and SeriesInstanceUID were not change, then this is an illegal behaviour.
In the case of E-Film (1.9) I can not reproduce this with Conquest and Jpeg Lossless compression.
Try to query/retrieve these images with K-PACS (you have to enable JPegLossless TS in the Server Administration tool)
Regards,
Andreas
Although your observation about the header changes is correct, the problems you encounter are most likely not caused by changing attribute 0008,0008 (Image Type).
The neccessary tag for identifying image type (IOD) is 0008,0016 (SOPClassUID) which is not altered because it is still 1.2.840.10008.5.1.4.1.1.2 (CTImageStorage)
If EFilm and other Applications do not sort these images correctly into studies/series then have a look at the following attributes:
0020,000D (StudyInstanceUID)
0020,000E (SeriesInstanceUID)
have a look whether these attributes are altered (maybe because of the correction algorithm for illegally space padded UIDs). If not post a complete header of two images formerly belonging to a series and after compression and retrieval from conquest do not anymore.
Btw.: the lossess in JpegLossess compression only refers to the pixeldata, not the header.
Regards,
Andreas
QuoteOne issue we have found is that random images will not display after queueing Conquest and selecting to view them. Neither the thumbnails nor the images display. To correct this we simply regenerate the database.
How often does this happen? Actually it should not, because it means that receiving of the images was successful but registering in the database failed. Also, the automatic clean up usually works without problems. The cleanup takes place at K-PACS start up, this means that you have to close and restart K-PACS once every day in order to clean the database from studies older than one day.
Regards,
Andreas
The images are probably NKI compressed. The original ezDICOM source does not support NKI.
Regards,
Andreas
Hi radtraveller,
does this only happen when you query your archive? What about the local database? Are the table fields correctly filled out here?
You can send the screenshot and the communication.log via e-mail.
Regards,
Andreas
c-get might work in this situation because c-find does but as I said before, c-get is not implemented. The problem is that there are rarly any archives to test against that support c-get (except for the medical connection service)
Even the reference implementations like OFFIS DCMTK do not really support c-get.
Regards,
Andreas
Yes, basically as long as the computer that your K-PACS is running on has a intranet IP you will need to implement forwarding. If you have a computer with a unique internet IP then retrieving images would work without forwarding.
Example:
your PC has an IP provided by your routers DHCP, e.g. 192.168.1.2
your Router is known to the internet with an IP given to it by your internet provider.
Medical Connections server will only see the routers IP and tries to c-store to this IP at port 104.
The router receives the request but does not know that it has to route the request to 192.168.1.2
Regards,
Andreas
c-get is not implemented in will not in the future, because it is a very rarly used service. Most archives will not support a c-get request.
Anyway, I do not think that c-get would solve your problem because the k-pacs server accepts any c-store request at the port he is listening. The http://www.dicomserver.co.uk. answers a c-move request to an unkown target (every target is unknown for it) with a c-store to the callers IP and Port 104. If your network is behind a router it will see the routers IP. You will have to implement a sort of port forwarding to let the request go through to your K-PACS server.
Regards,
Andreas
Currently K-PACS only support study level query and treats a study as the highest entity. Due to the fact that there are quite a number of users asking for patient level query, I will consider to implement it, although this would require a redesign of my database classes.
About the second question:
I have heard of this problem before (http://www.image-systems.biz/p…t=361&highlight=physician) and fixed an issue with studies that do not have a study date entry. With the current version 1.0.1 I can not reproduce this bug.
Can you give me more detail? E.g. screenshot and query result log (activate the LogDICOMCommunication option in the k-PACS.ini file)
Regards,
Andreas
If your CR vendor is FUJI this posting might be useful.
Please send me an example image that I can check the DICOM header.
Usually image scale is correctly handled in K-PACS.
Regards,
Andreas
K-PACS does not (yet) act as a Q/R SCP, which means that you can not query a K-PACS workstation. To test th server / client behaviour simply install the free Conquest DICOM server and query this one.
To verify that the receiver (Store SCP) works correctly, try to send (push) an image from one K-PACS instance to antother.
if this all works fine but Kodak connection fails we could investigate further with network protocol logging.
Regards,
Andreas
Hi Stephane,
actually there should be no problem with 32Gb of data although K-PACS is not yet supposed to be an archive, because the database is only textfile based.
Please send me the kpstudy.dir file (in /kpserver/database/ folder).
Maybe there is a problem with this table file.
Regards,
Andreas
Hi jcisrisen,
QuoteHere are the logs for the two different options I tried:
http://rapidshare.com/files/11844276/Server_Experiments.zip
The +B (bit-preserving) option seems to work fine. Currently iQ-View does not support it, because dataset will not be read by the server but just dumped to disc and that's why the database dll will not get any information but I already updated the server. I could send you a Beta-Version of iQ-View 2.0.2 that supports bit-preserving if you are interested
Regards,
Andreas
Please send me an example image via e-mail (Andreas<at>K-PACS.de)
I will check if there is a transfer syntax incompliancy.
Regards,
Andreas
