How to change default transfer syntax for out-going from Orthanc.

Google Groups archive
1

Can I change from “LittleEndianImplicitTransferSyntax” to “LittleEndianExplicitTransferSyntax” ?
Is it necessary to modify source code at “DEFAULT_PREFERRED_TRANSFER_SYNTAX = UID_LittleEndianImplicitTransferSyntax;” in “Core/DicomNetworking/DicomUserConnection.cpp” ?

Best,

2

Hello,

As of version 1.5.7, Orthanc does not support transcoding (i.e. on-the-fly conversion between DICOM transfer syntaxes), as can be seen on our roadmap:
https://bitbucket.org/sjodogne/orthanc/src/Orthanc-1.5.7/TODO#lines-105

We are looking for industrial sponsors to implement this feature.

Regards,
Sébastien-

3

Hi Sébastien,

Thanks for your reply, but It does not mean to convert between DICOM transfer syntaxes.

In this situation, when transmitting data from the modality(i. e. CT, MRI,) to other DICOM client (i. e. Horos, movescu in DCMTK, other DICOM servers,) via Orthanc, it is assumed that the explicit transfer syntax is not converted.

However, even though other DICOM client has requested to Orthanc with explicit transfer syntax, it has been changed to implicit transfer syntax when transferred from orthanc to another viewer.

Is it BUG?

Best,

2019年7月22日月曜日 18時41分57秒 UTC+9 Sébastien Jodogne:

4

This is presumably because your source DICOM server has used the “little Endian implicit” transfer syntax while sending to Orthanc. As a consequence, Orthanc only has the latter syntax at its disposal, and cannot send “little Endian explicit” to your viewer because Orthanc does not feature transcoding yet.

Try and configure your source DICOM server in order to prevent it from changing the transfer syntax.

As an alternative, you could try and compile Orthanc from sources, commenting lines 368 and 369 in order to make your source DICOM server think that Orthanc cannot receive “little Endian implicit”:
https://bitbucket.org/sjodogne/orthanc/src/90140b7796a1738a525f3a9d1ef404cb35e5e2c7/Core/DicomNetworking/Internals/CommandDispatcher.cpp#lines-366

Obviously, after compilation, make sure to clear all the Orthanc database and resend DICOM data from your source DICOM server to Orthanc.

5

This is not feature transcoding on Orthanc.
Also, I have not source DICOM server that has used the “little Endian implicit” transfer syntax.

My data flow is here.First, The MRI data with little Endian explicit is sent from the MRI CONSOLE to Orthanc, Orthanc not transcode it in this situation, I know.
Next, Downloaded data from web UI on Orthanc are with little Endian explicit yet, I know, too.
Final, Horos and movescu requested C-MOVE with little Endian explicit to Orthanc, but Orthanc sent the MRI data with little Endian implicit to Horos and movescu.

Any ideas?

Best,

2019年7月28日日曜日 22時09分26秒 UTC+9 Sébastien Jodogne:

6

Please provide a minimal working example using only DCMTK/GDCM/dcm4che command-line tools, together with sample (possibly anonymized) DICOM file:
https://en.wikipedia.org/wiki/Minimal_working_example

This is necessary for us to understand your issue and reproduce it independently using only free and open-source tools.

7

Unfortunately, OsiriX/Horos require Apple’s OS X to run, which in not free and open-source.

Please provide instructions usable under GNU/Linux (i.e. using only DCMTK/GDCM/dcm4chee, as written in my previous post).

8

Previous post is NOT mine, OK?

So I would show you instructions usable UNDER GNU/Linux ONLY USING DCMTK and ORTHANC, you said.

First, The dcmdump tool in DCMTK shows DICOM TAG on the part of my MRI data:

$ dcmdump my_MR_data_name.dcm

Dicom-File-Format

Dicom-Meta-Information-Header

Used TransferSyntax: Little Endian Explicit

(0002,0000) UL 196 # 4, 1 FileMetaInformationGroupLength

(0002,0001) OB 00\01 # 2, 1 FileMetaInformationVersion

(0002,0002) UI =MRImageStorage # 26, 1 MediaStorageSOPClassUID

(0002,0010) UI =LittleEndianExplicit # 20, 1 TransferSyntaxUID

Dicom-Data-Set

Used TransferSyntax: Little Endian Explicit

(0008,0005) CS [ISO_IR 100] # 10, 1 SpecificCharacterSet

(0008,0008) CS [ORIGINAL\PRIMARY\M\ND\MFSPLIT] # 30, 5 ImageType

(0008,0012) DA [20180622] # 8, 1 InstanceCreationDate

(0008,0013) TM [174321.564656] # 14, 1 InstanceCreationTime

(0008,0016) UI =MRImageStorage # 26, 1 SOPClassUID

Second, The storescu tool in DCMTK sent the my MRI data to ORTHANC, and the tool shows this logs:

$ storescu -aet LOCAL_AET -aec ORTHANC_AET --verbose ORTHANC_IP ORTHANC_PORT my_MR_data_name.dcm

I: checking input files …

I: Requesting Association

I: Association Accepted (Max Send PDV: 16372)

I: Sending file: my_MR_data_name

I: Converting transfer syntax: Little Endian Explicit → Little Endian Explicit

I: Sending Store Request (MsgID 1, MR)

XMIT: …

I: Received Store Response (Success)

I: Releasing Association

Third, Downloaded the my MRI data from web UI of ORTHANC, and the dcmdump tool in DCMTK shows this logs :
The Private TAGs have VR values and TAG values (this private TAGs are registered in the “Dictionary” section of Configuratuin.json).

$ dcmdump 15dc5855-d5c3-4c92-b2c8-***********.dcm

Dicom-File-Format

Dicom-Meta-Information-Header

Used TransferSyntax: Little Endian Explicit

(0002,0000) UL 202 # 4, 1 FileMetaInformationGroupLength

(0002,0001) OB 00\01 # 2, 1 FileMetaInformationVersion

(0002,0002) UI =MRImageStorage # 26, 1 MediaStorageSOPClassUID

(0002,0010) UI =LittleEndianExplicit # 20, 1 TransferSyntaxUID

(0002,0012) UI [1.2.276.0.7230010.3.0.3.6.4] # 28, 1 ImplementationClassUID

(0002,0013) SH [OFFIS_DCMTK_364] # 16, 1 ImplementationVersionName

Dicom-Data-Set

Used TransferSyntax: Little Endian Explicit

(0008,0005) CS [ISO_IR 100] # 10, 1 SpecificCharacterSet

(0008,0008) CS [ORIGINAL\PRIMARY\M\ND\MFSPLIT] # 30, 5 ImageType

(0008,0012) DA [20180622] # 8, 1 InstanceCreationDate

(0008,0013) TM [174321.564656] # 14, 1 InstanceCreationTime

(0008,0016) UI =MRImageStorage # 26, 1 SOPClassUID

…(snip)…

(0021,1001) IS [70] # 2, 1 Unknown Tag & Data

(0021,1004) DS [1] # 2, 1 Unknown Tag & Data

(0021,1005) IS [0\0\0] # 6, 3 Unknown Tag & Data

(0021,1006) LO [void] # 4, 1 Unknown Tag & Data

(0021,1008) SH [Normal] # 6, 1 Unknown Tag & Data

(0021,1009) LO [p2 s4] # 6, 1 Unknown Tag & Data

(0021,100a) DS [1] # 2, 1 Unknown Tag & Data

(0021,100d) US 0 # 2, 1 Unknown Tag & Data

…

Forth, The movescu tool in DCMTK requested C-MOVE the my MRI data w/ little Endian explicit to ORTHANC, and the tool shows this logs:

$ movescu -v --propose-little --prefer-little -k 0010,0020=“123456789” -aet LOCAL_AET +P LOCAL_PORT -aec ORTHANC_AET -od ./tmp/ ORTHANC_IP ORTHANC_PORT

I: Requesting Association

I: Association Accepted (Max Send PDV: 16372)

I: Sending Move Request (MsgID 1)

I: Request Identifiers:

I:

I: # Dicom-Data-Set

I: # Used TransferSyntax: Little Endian Explicit

I: (0010,0020) LO [123456789] # 10, 1 PatientID

I:

I: Sub-Association Received

I: Sub-Association Acknowledged (Max Send PDV: 16372)

I: Received Store Request (MsgID 1, MR)

RECV: …

I: Received Final Move Response (Success)

I: Releasing Association

Finery, The dcmdump tool in DCMTK shows the logs of moved the my MRI data:
The log shows changing to “Little Endian Explicit” to “Little Endian Implicit”, and Private TAGs gone (this private TAGs are registered in the “Dictionary” section of Configuratuin.json).

$ dcmdump tmp/my_MR_data_move_from_orthanc.dcm

Dicom-File-Format

Dicom-Meta-Information-Header

Used TransferSyntax: Little Endian Explicit

(0002,0000) UL 212 # 4, 1 FileMetaInformationGroupLength

(0002,0001) OB 00\01 # 2, 1 FileMetaInformationVersion

(0002,0002) UI =MRImageStorage # 26, 1 MediaStorageSOPClassUID

(0002,0003) UI [1.3.12.2.1107.5.2.50.175680.30000018062111274458500041449] # 58, 1 MediaStorageSOPInstanceUID

(0002,0010) UI =LittleEndianImplicit # 18, 1 TransferSyntaxUID

(0002,0012) UI [1.2.276.0.7230010.3.0.3.6.4] # 28, 1 ImplementationClassUID

(0002,0013) SH [OFFIS_DCMTK_364] # 16, 1 ImplementationVersionName

(0002,0016) AE [ORTHANC_AET] # 4, 1 SourceApplicationEntityTitle

Dicom-Data-Set

Used TransferSyntax: Little Endian Implicit

(0008,0005) CS [ISO_IR 100] # 10, 1 SpecificCharacterSet

(0008,0008) CS [ORIGINAL\PRIMARY\M\ND\MFSPLIT] # 30, 5 ImageType

(0008,0012) DA [20180622] # 8, 1 InstanceCreationDate

(0008,0013) TM [174321.564656] # 14, 1 InstanceCreationTime

(0008,0016) UI =MRImageStorage # 26, 1 SOPClassUID

…(snip)…

(0021,1001) ?? 37\30 # 2, 1 Unknown Tag & Data

(0021,1004) ?? 31\20 # 2, 1 Unknown Tag & Data

(0021,1005) ?? 30\5c\30\5c\30\20 # 6, 1 Unknown Tag & Data

(0021,1006) ?? 76\6f\69\64 # 4, 1 Unknown Tag & Data

(0021,1008) ?? 4e\6f\72\6d\61\6c # 6, 1 Unknown Tag & Data

(0021,1009) ?? 70\32\20\73\34\20 # 6, 1 Unknown Tag & Data

(0021,100a) ?? 31\20 # 2, 1 Unknown Tag & Data

(0021,100d) ?? 00\00 # 2, 1 Unknown Tag & Data

…

The instructions have show usable UNDER GNU/Linux ONLY USING DCMTK and ORTHANC, you see?

Any ideas?

Best,
YOKOHAMA

2019年7月29日月曜日 13時57分31秒 UTC+9 Sébastien Jodogne:

9

Previous post is NOT mine, OK?

Yes, OK, and I have not written it was yours.

So I would show you instructions usable UNDER GNU/Linux ONLY USING DCMTK and ORTHANC, you said.

Yes, but we also need a sample DICOM file as written above: You have only provided a dump.

[…] The instructions have show usable UNDER GNU/Linux ONLY USING DCMTK and ORTHANC, you see?

Yes, I see. No need to use uppercase.

Let’s relax,
Sébastien-

10

We can not provide our sample file, but we got same interaction using the sample file on GDCM below (i. e. Abdo.zip)
https://www.creatis.insa-lyon.fr/~jpr/PUBLIC/gdcm/gdcmSampleData/zippedImages/

Best,
YOKOHAMA

2019年7月29日月曜日 16時27分27秒 UTC+9 Sébastien Jodogne:

11

any ideas?

Best,

2019年7月29日月曜日 18時13分31秒 UTC+9 Noriya YOKOHAMA:

12

Please be patient. Your question will be processed, but we can’t tell you when.

Regards,
Sébastien-

13

Understood.

Best,

2019年8月9日金曜日 15時52分56秒 UTC+9 Sébastien Jodogne:

14

Hello,

I think your problem is the same as this issue on our bug tracker:
https://bitbucket.org/sjodogne/orthanc/issues/169/transfersyntaxuid-change-from-explicit-to

A preliminary fix is already available courtesy of Sylvain Rouquette. We’ll rework it in the following weeks, as we’re in the process of adding transcoding to Orthanc.

Regards,
Sébastien-

15

That’s great !

Best,

2020年3月23日月曜日 15時32分25秒 UTC+9 Sébastien Jodogne:

16

I’m pleased to inform you that the following changeset (that is part of the “transcoding” branch) fixes this issue:
https://hg.orthanc-server.com/orthanc/rev/8f7ad4989fec

This change will be part of forthcoming Orthanc 1.7.0 release.

Regards,
Sébastien-

17

Great job!
I’m looking forward to its release**.**

Best,

2020年5月7日木曜日 18時43分55秒 UTC+9 Sébastien Jodogne: