Posts by stridde

Sure, that's possible. In the main configuration file K-PACS.ini (to be found in the installation folder) there are settings available to change the font size of the text overlay, both for the viewer and for printing.

Close K-PACS. Open the K-PACS.ini in a text editor and search for the following parameters:

- for changes of text overlay in the viewer: "OverlayTextScaling=65" in section [CustomSettings]
- for changes of text overlay in the print manager: "OverlayTextScaling=65" in section [PrintSettings]

65 (percent) is the default value. The lower the value for text scaling, the bigger are the fonts on the layout. Make the necessary changes, save them and then restart K-PACS.

I'm not sure, though, that this will solve the images being cut-off at your printer. Maybe your printer uses some cropping mechanism, if the image received is too large to fit onto the selected film size. You may have to play around with some other settings, e.g. the parameter "PaperPrintMarginSize=" under [PrintSettings]. If images get cut off when printed, you may want to increase the margin width. The value stated is given in percent.

You can check the printing with the option "PrinterDummy" to be found where your printers are listed. Run a print job and then check the sub-folder "Spooler" in the K-PACS directory for a BMP file. That's the output which is sent to the printer. If the output is fine here, the issue may lie with your printer.

PS: Keep in mind that K-PACS is not a medical device and can, therefore, not be used in a diagnostic environment.

If you moved to a different location, probably the network specifics have changed. Check that K-PACS is still correctly configured in the DICOM settings of your ultrasound machine (AE title, port, IP address). And, the other way round, verify that the US machine's details are correct in the K-PACS DICOM settings (AE title, port, IP address). Specifically the IP addresses of the computers could have changed in the process of moving.

You can delete individual DICOM objects by opening a study down to image level in the study table (use the "+" icon). Then right-click an item you wish to delete. A sub-menu opens that contains an option to delete the selection from the imagebox. Select that option and the marked item will be deleted. You can do so individually for each item you wish to remove.

ATTENTION: Your images may be multi-frame objects, meaning that one object has not only one image but several images (= frames). The method above only allows the deletion of an entire object. There is no way to remove only individual frames from a multi-frame object.

I'm not sure what exactly you are looking for in terms of a "procedure".

You simply select the study, studies or series in the study table of K-PACS by marking the checkbox(es) and then click the "Transfer" button and select the archive you want to send the data to. The transfer starts after the selection. That's the procedure as far as K-PACS is concerned. If you have previous requirements of connecting via VPN and such, that's something you need to define as it's your network and only you know how it's set up.

Why shouldn't this work? It will probably work in the same way that you use it with the ONIS viewer. The VPN connection must be active; the user currently logged into the K-PACS computer must have permission to use the VPN connection to the server. You configure the DICOM server with which K-PACS shall communicate via VPN by defining the AE title, IP address/hostname and port in the K-PACS "DICOM settings". And you configure the K-PACS details (AE title, IP address/hostname and port) in the server as well. The port must be free and not blocked. Potential firewalls need to allow the communication.

Using VPN has less to do with the actual applications than with the network configuration.

Thank you for your feedback. I'm glad that the issue is solved and that you can now use K-PACS sucessfully.

And yes, restarting the server is always necessary when doing changes.

That's good news.

Generally, the Windows firewall will pop up by itself (at least I've experienced this many times with iQ-VIEW) and ask whether the server should be allowed to communicate or blocked. Afterwards, everything always worked fine.

If you set up exceptions in the firewall for all these executables, it should generally work. Make sure to do this as an inbound rule. But, judging from the screenshot, it's exactly what you did. It may also help to explicitly add the K-PACS server port (by default 104) to the exceptions list.

Are you in a domain network? In that case, special rules may apply. Contact your network administrator for additional advice.

Of course, the log bits make sense to me. That's part of my job.

This is the beginning of a C-ECHO command ... a DICOM connection verification. A station with the AE title "ONEPACSPOLLER" sends a C-FIND command to the IP address and port on which your K-PACS is listening. According to the log, your K-PACS should have the AE title "ONIS22" configured. However, if that's all you had in your log file, then the C-ECHO was not successful but stopped before the necessary information could be exchanged.

I am actually wondering now whether your K-PACS really has the AE title "ONIS22" or if you have the Onis viewer installed on the same system and have its DICOM receiver running at the same time as the KPServer. This could lead to confusion of the communication and explain why the images do not show up in K-PACS. Maybe they are stored in the Onis database instead?

You should familiarize yourself with your network. Which stations exist, where they are located (IP) and which ports they use, what the AE titles are for each station and who communicates with who. Also check that the DICOM settings of each station are properly set up. That the correct AE titles, IP addresses and ports are configured for all stations that a particular station is supposed to communicate with. That those ports are not blocked by a firewall or something and that there are not several programs trying to use the same port on one machine.

Database vs. Imagebox ... K-PACS actually has both. As you (may) know, K-PACS does not have a "real" database, such as MySQL or Postgres. It has a file-based database structure with the KPStudy.dir being the study level "database". The imagebox, however, is the location where the actual images are stored ... where you find the study folders. By default, the database file(s) are located in the same folder as the images. That makes the most sense. This is why the server administration tool gives two paths, though ... one to the database KPStudy.dir and one to the imagebox.

Yes, please. Let us know whether the suggestions worked for you. We do not actually provide technical support for our freeware options, but, of course, we still want our users to enjoy having and using them.

Some suggestions without guarantees:

- Check that the port, on which the K-PACS DICOM server component is supposed to run, is not in use by another application or service and that it is not blocked by a firewall.
- Check that both, "Database" and "Imagebox" path end with a backslash ("\") in the server administration tool.
- Set the KPServer.exe into "Compatibility mode" as well and set the executable to "run as administrator".
- Disable the system's UAC (user account control).

It means that you are receiving data. But is the log entry "DIMSE receiveFileData: 16378 bytes read <last: NO>" the last one that you see in the log? Nothing after that? No "DIMSE receiveFileData: 16378 bytes read <last: YES>" or an association termination or anything?

If the images do not physically arrive on the system, i.e. are not stored on the hard disk, they probably won't be registered in the K-PACS database either. And we are back to the network/connection issue. Check the logs of the sending stations (and crank up those logs to the highest level for getting the most details) and, if necessary, involve their vendor(s). It could also be a hardware issue on your computer, e.g. a defective memory or hard disk. You may run checks to ensure that the hardware is okay.

And yes, you have a corrupted database. The number of studies listed in the study table and the number of study folders in the "Database" folder does not match. Not sure how that happened, because yes, usually a study selected and deleted within K-PACS will also be physically removed from the system.

You could try to resolve the database corruption. My suggestion would be to start a completely new database and check with that. Create a folder directly under C:\ and point to it in the server administration tool (both paths ending with "\"). Don't forget to restart the server afterwards.

Two other ideas pop up in my mind:

- In case you do not receive ANY images anymore => maybe the hard disk is full
- If only some images do not arrive => maybe their storage path would be too long for a Windows system to handle as Windows limits the number of characters allowed for a file path. This could happen if your "Database" is already several levels deep in the Windows folder structure.

What exactly isn't running? The K-PACS executable or the KPServer.exe, i.e. the DICOM server component of K-PACS? Or both?

Keep in mind, though, that K-PACS was never developed for Windows 7. It's not impossible that there are incompatibility issues.

I don't really see a software bug at this point. You have socket errors pointing towards the network. And if image files actually arrive successfully (did you really check this?) but are not displayed in the study list, then this can have a variety of reasons, such as:

- you have set search filters that limit the number of studies displayed in the list => deactivate all filters and try again
- you have too many studies in your imagebox so that they can't all be displayed anymore => K-PACS will not show more than 10.000 studies => either use the search filters to look for the study in question or clean out your imagebox
- your database is corrupted => compare the number of study folders in the "Database" folder on the computer's file system with the number of studies declared in the study browser's status bar when NO filter is active

But yes, check out other applications to see whether they fit your needs better.

Quote from ctao

DIMSE receiveFileData: 16378 bytes read <last: NO>

This means that K-PACS is currently receiving data. The images are sent over the network in individual data packages of 16378 Bytes per package (= PDU size). The information "<last: NO>" means that the just received package is not the last one and that more data will follow. It will keep the association open.

With regards to iQ-VIEW, we cannot promise you that you won't have issues initially, especially if the reasons for the faulty communication is not our application but the network, hardware, sending station, or something else. However, in iQ-VIEW we have lots more options for trouble-shooting as well as much better logging options. A local reseller may be able to help you trouble-shoot in case of a purchase. As a manufacturer, we would support our local partner, if the necessity arises.

"Server is running" is just the status information. I was talking about activating the logging. Stop the server. Activate the "Verbose mode" checkbox and restart the server. A command line window will log the activity. It would be helpful to extend the number of lines that the command line box will display as logs can get rather long.

Please note that we do not grant full technical support for any freeware products. We can only give you some pointers here to help you help yourself. Full technical support is granted for our professional software products. Feel free to check out our radiological workstation iQ-VIEW, including many more features, Windows 7 support, technical assistance even by a reseller in your region.

Well, the issue with dynamic IP addresses is that they can change, as the name suggests. If you have configured your DICOM stations with the IP address, the communication will fail in case the IP has changed. If you use the hostname of the machine instead, changing IP addresses may take longer to resolve.

Please note that we cannot troubleshoot your network or internet connection. The only thing I can say is that you should check the network status (IP addresses, speed, etc.) at such a time when the transfer issues occur. This should give you hints for further troubleshooting. Maybe you've got issues with the VPN connection.

And, as I said in an earlier post, try activating the K-PACS server log in the server administration to see if there are indicators at K-PACS side (NOT the K-PACS process log).

Good luck!

A socket error occurs when you try to connect from one station to another but it is inaccessible over the network. It sounds like a network issue. Make sure that the network/internet connection is stable. Maybe there are instances where the internet connection gets too slow. A system will close the sockets if nothing happens for a specific amount of time. It will time out. Use static IP addresses or use the hostnames instead. However, in the latter case, you must ensure that the hostnames can be resolved properly.

And to answer your question, a multi-frame object is like a movie. You have one file, but it contains several/lots of images (=frames). It's like an MPEG or AVI, only in DICOM format.

I think what you are looking for is a PACS solution (an archive), not a DICOM viewing station. K-PACS is a viewer for DICOM images and not a PACS. Since it is a workstation software not a server software and cannot be queried by other stations, it seems not to be the best solution in your case.

If you are looking for a central storage unit, you should check out either our professional veterinary PACS solution VET-WEBX or look into the freeware ConQuest, that you can find in this forum.

Well, K-PACS 1.6.0 was published in 2009. The latest iQ-VIEW version (2.8.0.101) came out in summer last year. Four years can make a lot of difference in our field.

Thank you for trying out iQ-VIEW with your data. Looks like this solves some of the issues but not all. I know we had some difficulties with image sorting order due to specific UID structures. I assume that it's something in the images. Could you maybe provide us with a LWS sample study with which you could reproduce the issues? Like you, we would like to know what's the reason for the strange behavior. But I don't think that we will be able to do that without looking at the images ourselves. Feel free to anonymize them beforehand, but please check that the issue still occurs with the anonymized images. We had several events where an issue was solved by running images through the iQ-VIEW "Modify" option.

Something else you could try: iQ-VIEW offers different image sorting options, with instance number being the default. You find these options under the menu item "Additional settings" in the viewer. Is there an option that gives you the image order you are looking for?

To answer your question, no, you do not have to use the option "next multi-frame object". If a series contains several multi-frame objects, iQ-VIEW will let you browse through all frames of all objects from start to finish of the series. It's just a navigation option, so in case you have several objects within a series, you can quickly jump to the next one.

What exactly do you mean with "enhanced" and "normal" transfer? Are you referring to the SOP classes in which the MR images are encoded? That would be MR Image Storage vs. Enhanced MR Image Storage, meaning single-frame images vs. multi-frame images.

And are you saying that the images are displayed in the correct order as long as you use the "normal" way?

I would suspect that the issues lies somewhere in the DICOM information and/or encoding of the images. Something that is not handled correctly by K-PACS. Keep in mind that the last software version is a few years old already and may not be fully compliant with newer DICOM objects.

Do you have an opportunity to try the images with an iQ-VIEW? Would be interesting to see whether it works there. You would be able to download a trial version here.