Unsuccessful attempt to change eFilmWorkstation (working as the DICOM server) to Orthanc Server

Hi all.

Having task to change eFilm to Orthanc.

In entrance: computer with eFilmWorkstation working as DICOM server, AE_TITLE “AE_TITLE”, port 4006, computed tomography (CT) device Siemens with attached to it another computer with Syngo soft (this computer directly recieves data from CT device).

When I select patient or study in Syngo and choose “Send to”, data begins to flow into eFilm server. Operation ends successfully.

I’d made exchange: the same settings in newly installed Orthanc server instance, eFilm was completely shutted down. But when I tried to recieve data, I’ve got only patient and study json-formatted info without images in orthanc database (and Orthanc explorer displays this patient info without images data).

Moreover, no any traffic (monitored with WireShark) about images transfer.

What magic does eFilm use to obtain images from Syngo?? What I’m doing wrong?

Screen from Syngo soft with failed transfer, orthanc config and log file are attached.



log.TXT (29 KB)

orthanc.json (15.4 KB)


Seems you’ve configured stuff backwards in the Orthanc.json config file. Here is what I noticed:

// The DICOM Application Entity Title
“DicomAet” : “AE_TITLE”,

This first entry is the AE Title of the Orthanc server, not of the server it connects to as you seem to describe in your post.

// The DICOM port
“DicomPort” : 4006,

This second entry is the DICOM port the Orthanc server uses.

// The list of the known DICOM modalities
“DicomModalities” : {
* Uncommenting the following line would enable Orthanc to
* connect to an instance of the “storescp” open-source DICOM
* store (shipped in the DCMTK distribution) started by the
* command line “storescp 2000”.
// “sample” : [ “STORESCP”, “”, 2000 ]

This last entry is where you would put information about remote modalities (such as your eFilm server). Now, in the logs, I see that you’re requesting a C-MOVE from AE Title AN_CTAWP69941 and requesting info from AE Title EFILM1:

I0824 18:33:48.138891 main.cpp:187] Incoming connection from AET AN_CTAWP69941 on IP, calling AET EFILM1

Based on your config file, the AE Title you should be calling would be “AE TITLE” though you may want to reconfigure that since its the default AE Title for eFilm and you can’t use the same AE Title twice. The config lets you, but it doesn’t work, I tried.

In short, you need to:

  1. Modify your AE Title/port entry for your Orthanc server in the orthanc.json file.
  2. Add the remote servers to the list of known DICOM modalities in the orthanc.json file.
  3. Modify the information from your connecting modality (AN_CTAWP69941) to the correct AE Title and port of your Orthanc server.

Also, for the record, eFilm can’t handle JPEG-LS, Deflated or Jpip so you may want to disable those in Orthanc config. However, there is currently a bug that will be fixed in 1.4.2 regarding the disabling of the JPEG-LS Transfer Syntax in Orthanc that doesn’t stick:

// The transfer syntaxes that are accepted by Orthanc C-Store SCP
 **"DeflatedTransferSyntaxAccepted"     : true,**
  "JpegTransferSyntaxAccepted"         : true,
  "Jpeg2000TransferSyntaxAccepted"     : true,
 **"JpegLosslessTransferSyntaxAccepted" : true,**
 **"JpipTransferSyntaxAccepted"         : true,**
  "Mpeg2TransferSyntaxAccepted"        : true,
  "RleTransferSyntaxAccepted"          : true,

You can find details here → https://groups.google.com/forum/#!searchin/orthanc-users/efilm|sort:date/orthanc-users/NvEeNCbrvd8/EWQb-FQ2BwAJ

Hope this helps!

Mat M.

Thank you much, Mat!

I plan to use Orthanc server to completely replace eFilm server. So I’ve shutted down eFilm, but got its settings: AE title “AE_TITLE” and port 4006 and make the same in Orthanc. I swear you ) that there is no AE named “EFILM1” in our network (so it a rudimentary name, that computed tomography device AE using to connect with server and send data to it for many years); but data magically flows to eFilm through TCP connection to port 4006 (despite AE “EFILM1” is requested), and never comes to Orthanc (through the same TCP connection to 4006 port, as I can see while experimenting) when I’ve replaced eFilm with Orthanc.
Ok, I’ve replaced ae title to “EFILM1” in Orthanc, but have no success yet (.
Changing port to other value completely prevent assotiation creation (as I see in log).

Maybe you have any ideas, why no incoming network traffic with images data to Orthanc, although TCP connection is established? Maybe here take place some issue like repeating TCP connections rejection to the same Orthanc DICOM port?
Ok, I have no new logfile for now (I will send it later), but what I saw while playing with data transfer that there is no any error reporting.

Anyway I thank you for the answer one more time and will keep informing (if you allow) about further progress.


Hi Vyacheslav,

I’m not 100% I understand what you are trying to do but for the record, you can store but you can’t retrieve anything from Orthanc without having configured the querying device in the list of known DICOM modalities.

If you are trying to retrieve, have you added the AE Title (IP and port as well) in the “list of known modalities”?

If you are only trying to store, by default, all you need is the IP, port and AE Title of the Orthanc server being properly entered in the sending device’s remote DICOM list. Based on the config/log from your first post, that would be:

Orthanc info
IP Address = Whatever your Orthanc IP is
Port = 4006

Based on the first logs provided, the device on IP (AET AN_CTAWP69941) is trying to call the AE Title EFILM1 which is unknown by Orthanc hence why nothing is happening.

Also, any configuration change in the .json files requires restarting Orthanc. You may want to take a look at the Troubleshooting DICOM section of the Orthanc book:



For now I’m trying to send patient’s study data through standard DICOM network protocol from AE “AET AN_CTAWP69941”, IP to Orthanc (now it have AE “EFILM1”, IP Service has been restarted manually after config changed.

But there is only data about patient and study coming to Orthanc, no images transferred. I.e. data comes, but small part of whole study only.

So I ask if there are some known issues about TCP transfer, packet size, connection features, etc.?

Hi Vyacheslav,

I haven’t experienced this myself. Have you tried running Orthanc from the command line with the --verbose or --trace option enabled? The logs might have a clue. That’s how I’ve debugged most issues so far.

Hopefully you can figure it out or somebody more knowledgeable than I can assist you.

Best of luck and let us know how it goes,

Thanks, Mat.

Logs done with --trace… Mayby I’ll be lucky in future to compile sources of Orthanc in Visual Studio to debug transfer data process…



Problem was with image transfer format on source side (AET “AN_CTAWP69941”): there was “JPEG lossless”. Setting to two other options “JPEG lossy” and “Raw” produces correct transfer traffic and properly storing to Orthanc database.

Suggest that on association creation stage, while negotiation handshake, Orthanc answer with “false” on request’s JPEG-LS format property, and source AE obediently produces no traffic.

Now I have problem with repeatedly stored instances (images), when trying to send the same study to Orthanc several times, but suppose that it can be solved by Lua scripting.


Hi Vyacheslav,

Good to know! Maybe related to the bug that will be fixed in 1.4.2? It is weird though since Orthanc is supposed to handle JPEG-LS correctly. In fact, we were receiving JPEG-LS studies ourselves which we couldn’t open with eFilm afterwards and that’s how we encountered the previously-mentioned bug ourselves as disabling JPEG-LS in the orthanc.json config did not alter the behavior.

I had to confirm this using a DICOM tag viewer to inspect the images and look at the XML downloaded in the study with the Orthanc web viewer to confirm the transfer syntax was really JPEG-LS using the UID as there isn’t really any way I am aware of to know for sure otherwise. You might want to take a look at that.

Maybe Sebastien/Osimis can chime in and explain/confirm if this is related to that bug or not?


Hello Vyacheslav,

The fix related to JPEG-LS handling that is mentioned by Mat M is currently pending in the mainline, and will be part of forthcoming Orthanc 1.4.2:

Full details are available in this thread:

Before further investigation, you should give a try to this fix by recompiling Orthanc from source, then setting configuration option “JpegLosslessTransferSyntaxAccepted” to “false”.