DICOM @ OFFIS

DCMTK build correctly, but now my programs returns this: ld: error: undefined symbol: locale_charset >>> referenced by ofchrenc.cc >>> ofchrenc.cc.o:(OFCharacterEncoding::getLocaleEncoding()) in archive /home/informemedico/dcmtk/dcmtk-3.6.2/lib/libofstd.a >>> referenced by ofchrenc.cc >>> ofchrenc.c...

Now I'm building dcmtk with:
Let's see what happens.

Hi, I'm trying to build a program that uses dcmnet on FreeBSD12.2 To build dcmtk 3.6.2 I used: CXX=clang++70 CC=clang70 cmake . make Everything built without issues, then I tried to compile my program, that requires dcmnet, dcmdata and a couple more libraries and got this: ld: error: undefined symbo...

I'm doing some C-Find commands against a GE PACS (Centricity) and found this funny results. When I query for series I get this: findscu -v --study -k 0008,0052=SERIES -k 0020,000D=1.2.840.113619.2.452.3.1678428672.149.1564403906.381 -k 0020,000E -k 0008,0060 --aetitle SCPAET --call GEPACS 10.100.0.4...

Thank you for your (feature) request. findscu already has various --extract options for extracting the C-FIND response datasets to various formats, including DICOM and XML. I don't think that it makes sense to add further output formats since all DCMTK tools are basically meant as sample programs t...

Hi, I use findscu, dcmsend and movescu from shell scripts, they of course work, but parsing its output is quite complicated. Is there a possibility in future versions to add an "--output-as-json" option to those tools to let them output results as JSON to easy it's parsing?. Regards, Leona...

Apart from this today I installed Conquest, but got the same results, so, aparently the problem is not server side?,

Today I did a comparison between storescp 3.6.4 and storescp 3.5.4 and found the older is much slower than the newer, almost 10 seconds slower.

All tests performed between my laptop at home sending a file to the Digital Ocean's droplet.

Ok, using iperf this are the results: Server: ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 4] local BBB.YYY.ZZZ.AAA port 5001 connected with XXX.YYY....

BTW, I did the test against a virtual machine running on a standard i7 PC on a remote location and it took the same time storescp and scp, so, it looks like the problem is on the Digital Ocean (and Vultr) droplets.

J. Riesmeier wrote: ↑Tue, 2019-05-14, 19:52 Did you already check what the maximum throughput of your network connection is (i.e. theoretically). Maybe, your "scp" tool compresses the transferred file by default,

Well, I don't know. How can I check that on Linux (Ubuntu 16.04 Server).

Today I used a Pynetdicom SCP program to test this issue and got the same results (dicom transfer much slower than scp), so it's not a problem of DCMTK.

Anyway, if someone has any idea how to track this issue I'll be glad to hear.

Leonardo.

J. Riesmeier wrote: ↑Mon, 2019-05-13, 19:38 You could also call "cmake -L | fgrep CMAKE_BUILD_TYPE" to see the build type.

Thanks, it returned "CMAKE_BUILD_TYPE:STRING=Release"

BTW, I built dcmtk with This generates a release or debug version?, if mine is a debug version can it be the cause of the slowness?.

Weird, because I did a test against two different servers (one Digital Ocean and other Vultr) and both gave very similar results 12 seconds for scp and 22 seconds for dcmsend.