Problem with disabled transfer syntax (JPEG-LS)

850 views
Skip to first unread message

Mat M

unread,
Jul 17, 2018, 2:12:48 PM7/17/18
to Orthanc Users
Greetings fellow users,

We just installed Orthanc last week as an alternative to our ageing and unstable Conquest PACS server and so far, we are please with the results.  However, most of our users internally use eFilm 3.3 vet edition.  Now, most DICOM transfers work without issue.  However, we were getting some issues (as reported here https://groups.google.com/forum/#!topic/orthanc-users/yU-XasmYSU4) with JPEG-LS Lossless syntax which, for one reason or another, could not be accepted by eFilm during the retrieve process.  We know this issue rests solely on eFilm's shoulders as we can open these same studies using a different viewer (RADIANT).

Here are some logs to illustrate the problem:

Orthanc:

I0713 14:25:02.091757 CommandDispatcher.cpp:491] Association Received from AET XXXX on IP XXX.XXX.XXX.XXX

I0713 14:25:02.091757 main.cpp:187] Incoming connection from AET XXXX on IP XXX.XXX.XXX.XXX, calling AET XXXX

I0713 14:25:02.091757 CommandDispatcher.cpp:689] Association Acknowledged (Max Send PDV: 64222)

I0713 14:25:02.123000 main.cpp:200] Incoming Move request from AET XXXX on IP XXX.XXX.XXX.XXX, calling AET XXXX

W0713 14:25:02.123000 OrthancMoveRequestHandler.cpp:179] Move-SCU request received for AET "XXXX"

I0713 14:25:02.123000 OrthancMoveRequestHandler.cpp:187]   (0008,0052)  QueryRetrieveLevel = STUDY

I0713 14:25:02.123000 OrthancMoveRequestHandler.cpp:187]   (0020,000d)  StudyInstanceUID = 1.2.826.0.1.3680043.2.876.5887.1.2.3.20180712183706.0.3

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT d.id FROM DicomIdentifiers AS d, Resources AS r WHERE d.id = r.internalId AND r.resourceType=? AND d.tagGroup=? AND d.tagElement=? AND d.value=?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT d.id FROM DicomIdentifiers AS d, Resources AS r WHERE d.id = r.internalId AND r.resourceType=? AND d.tagGroup=? AND d.tagElement=? AND d.value=?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT publicId FROM Resources WHERE internalId=?

I0713 14:25:02.123000 OrthancMoveRequestHandler.cpp:71] Sending resource 202ac532-46dded50-2972b72d-926faf99-876e551c to modality "XXXX"

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT internalId, resourceType FROM Resources WHERE publicId=?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT resourceType FROM Resources WHERE internalId=?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT a.internalId FROM Resources AS a, Resources AS b  WHERE a.parentId = b.internalId AND b.internalId = ?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT a.internalId FROM Resources AS a, Resources AS b  WHERE a.parentId = b.internalId AND b.internalId = ?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT a.internalId FROM Resources AS a, Resources AS b  WHERE a.parentId = b.internalId AND b.internalId = ?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT a.internalId FROM Resources AS a, Resources AS b  WHERE a.parentId = b.internalId AND b.internalId = ?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT resourceType FROM Resources WHERE internalId=?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT a.internalId FROM Resources AS a, Resources AS b  WHERE a.parentId = b.internalId AND b.internalId = ?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT a.internalId FROM Resources AS a, Resources AS b  WHERE a.parentId = b.internalId AND b.internalId = ?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT resourceType FROM Resources WHERE internalId=?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT publicId FROM Resources WHERE internalId=?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT resourceType FROM Resources WHERE internalId=?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT a.internalId FROM Resources AS a, Resources AS b  WHERE a.parentId = b.internalId AND b.internalId = ?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT a.internalId FROM Resources AS a, Resources AS b  WHERE a.parentId = b.internalId AND b.internalId = ?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT resourceType FROM Resources WHERE internalId=?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT publicId FROM Resources WHERE internalId=?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT resourceType FROM Resources WHERE internalId=?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT a.internalId FROM Resources AS a, Resources AS b  WHERE a.parentId = b.internalId AND b.internalId = ?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT a.internalId FROM Resources AS a, Resources AS b  WHERE a.parentId = b.internalId AND b.internalId = ?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT resourceType FROM Resources WHERE internalId=?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT publicId FROM Resources WHERE internalId=?

T0713 14:25:02.123000 Statement.cpp:144] SQLite::Statement::Step SELECT internalId, resourceType FROM Resources WHERE publicId=?

T0713 14:25:02.154264 Statement.cpp:144] SQLite::Statement::Step SELECT uuid, uncompressedSize, compressionType, compressedSize, uncompressedMD5, compressedMD5 FROM AttachedFiles WHERE id=? AND fileType=?

I0713 14:25:02.154264 FilesystemStorage.cpp:155] Reading attachment "b23b075c-5c35-4caa-90af-2c4a8dce7ac8" of "DICOM" content type

I0713 14:25:02.232368 DicomUserConnection.cpp:901] Opening a DICOM SCU connection from AET "XXXX" to AET "XXXX" on host XXX.XXX.XXX.XXX:4006 (manufacturer: Generic)

I0713 14:25:02.247992 DicomUserConnection.cpp:302] Change in the transfer syntax: the C-Store associated must be renegotiated

I0713 14:25:02.247992 DicomUserConnection.cpp:316] Renegotiating a C-Store association due to a change in the parameters

I0713 14:25:02.247992 DicomUserConnection.cpp:901] Opening a DICOM SCU connection from AET "XXXX" to AET "XXXX" on host XXX.XXX.XXX.XXX:4006 (manufacturer: Generic)

E0713 14:25:02.279241 DicomUserConnection.cpp:167] DicomUserConnection: DIMSE Failed to send message

E0713 14:25:02.310539 MoveScp.cpp:221] IMoveRequestHandler Failed: Error in the network protocol

I0713 14:25:02.357387 CommandDispatcher.cpp:892] DUL Peer Requested Release

I0713 14:25:02.357387 CommandDispatcher.cpp:899] Association Release

T0713 14:25:07.210104 Connection.cpp:388] SQLite::Connection::FlushToDisk

 

Shown on the console:

W: DIMSE Warning: (GVMIEXT,AE_Imagerie01): sendMessage: unable to convert dataset from 'JPEG-LS Lossless' transfer syntax to 'Little Endian Explicit'

 

 

This is what it looks like on eFilm’s side in the DICOM.log :

 

(1644) 07-13 14:25:02.44 MC3  W: Presentation context 1 rejected, reason 0x03

(1644) 07-13 14:25:02.45 MC3  W: |  Abstract syntax: 1.2.840.10008.5.1.4.1.2.3.1 (PATIENT_STUDY_ONLY_QR_FIND)

(1644) 07-13 14:25:02.45 MC3  W: |  Abstract Syntax Rejected

(1644) 07-13 14:25:02.45 MC3  W: Presentation context 3 rejected, reason 0x03

(1644) 07-13 14:25:02.46 MC3  W: |  Abstract syntax: 1.2.840.10008.5.1.4.1.2.3.2 (PATIENT_STUDY_ONLY_QR_MOVE)

(1644) 07-13 14:25:02.46 MC3  W: |  Abstract Syntax Rejected


We read about similar problems with other viewers elsewhere here so we are awaiting feedback from eFilm's support regarding this but, in the meantime, we figured we'd simply disable the JPEG-LS syntax from the orthanc.json config file like so:

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

  // Whether Orthanc accepts to act as C-Store SCP for unknown storage
  // SOP classes (aka. "promiscuous mode")
  "UnknownSopClassAccepted"            : false,

Now, for some reason unknown to me, it appears we're still getting the issue with some new studies being sent as JPEG-LS regardless.  Unless I am misunderstanding something here, shouldn't the sending DICOM node be renegotiating with Orthanc using a different syntax?  Why are we still getting some JPEG-LS studies?

Thanks for your time!

Sébastien Jodogne

unread,
Jul 17, 2018, 2:23:39 PM7/17/18
to Orthanc Users
Hello,

Welcome to the Orthanc community!


We just installed Orthanc last week as an alternative to our ageing and unstable Conquest PACS server and so far, we are please with the results.  However, most of our users internally use eFilm 3.3 vet edition.  Now, most DICOM transfers work without issue.  However, we were getting some issues (as reported here https://groups.google.com/forum/#!topic/orthanc-users/yU-XasmYSU4) with JPEG-LS Lossless syntax which, for one reason or another, could not be accepted by eFilm during the retrieve process.  We know this issue rests solely on eFilm's shoulders as we can open these same studies using a different viewer (RADIANT).

Mid-air collision: I have already answered this part of your question in another thread:


We read about similar problems with other viewers elsewhere here so we are awaiting feedback from eFilm's support regarding this but, in the meantime, we figured we'd simply disable the JPEG-LS syntax from the orthanc.json config file like so:

  // The transfer syntaxes that are accepted by Orthanc C-Store SCP
  "JpegLosslessTransferSyntaxAccepted" : false,

Now, for some reason unknown to me, it appears we're still getting the issue with some new studies being sent as JPEG-LS regardless.  Unless I am misunderstanding something here, shouldn't the sending DICOM node be renegotiating with Orthanc using a different syntax?  Why are we still getting some JPEG-LS studies?

In your setup, you visibly have the following chain of tools: "Source PACS" => "Orthanc" => "eFilm".

By setting the option "JpegLosslessTransferSyntaxAccepted" to false, you tell the "Source PACS" that "Orthanc" cannot receive JPEG-LS files. As a consequence, as your "Source PACS" visibly has transcoding abilities, it converts the JPEG-LS file to an raw, uncompressed DICOM image. This makes the link "Orthanc" => "eFilm" works, as eFilm is happy with raw, uncompressed DICOM images.

So, this option only solves your issue if you re-send JPEG-LS images from the "Source PACS" using the DICOM protocol.

HTH,
Sébastien-

Mat M

unread,
Jul 17, 2018, 2:32:04 PM7/17/18
to Orthanc Users
Hi Sébastien,

Thanks for the answer in the other thread.  As mentioned before, I am aware that the issue decoding JPEG-LS rests solely on eFilm's shoulders and have already contacted them regarding this and am awaiting feedback.

The source PACS is external to our institution and not controlled by us in any way.  It is a referral, meaning it can be anything and we have no way of knowing without calling the referring institution ourselves and asking them.

I understand that it does not really solve the issue more than it works around it but that isn't the problem here.  We disabled the JPEG-LS transfer syntax last week and restarted Orthanc.  However, we've received some DICOM studies today with, or at least I think, this same transfer syntax even though it should be disabled.  I'm getting the same error message regarding JPEG-LS hence why I'm assuming we received this study with the same transfer syntax though I'm not 100% certain how I'd check this on Orthanc's side.

This is what has me wondering if I disabled the right thing.  Is there any way for the Source PACS to send JPEG-LS to Orthanc even if its disabled on Orthanc's side?

What am I missing?


Thanks for your time and patience.

Regards,
Mat

Sébastien Jodogne

unread,
Jul 17, 2018, 2:45:27 PM7/17/18
to Orthanc Users
Hello,


On Tuesday, July 17, 2018 at 8:32:04 PM UTC+2, Mat M wrote:
The source PACS is external to our institution and not controlled by us in any way.  It is a referral, meaning it can be anything and we have no way of knowing without calling the referring institution ourselves and asking them.

As a consequence, setting the "JpegLosslessTransferSyntaxAccepted" to "false" will not solve your issue in all the cases. This solution is only valid if the PACS of the referring institution has transcoding capabilities. If the latter has no such capabilities, the transfer from the referring institution to Orthanc would fail.

 
This is what has me wondering if I disabled the right thing.  Is there any way for the Source PACS to send JPEG-LS to Orthanc even if its disabled on Orthanc's side?

No, this is not be possible. Are you sure that you have cleared all the content of the Orthanc database after setting the option to "false"? If not, JPEG-LS files that were received before setting the option to "false" will not be readable by eFilm.

The actual solution to your problem consists in transcoding the JPEG-LS files once Orthanc receives them, either through REST scripting or through Lua scripting:

As a starting point, you can take inspiration from the following sample Lua script that is part of the Orthanc source distribution, and that transcodes any incoming DICOM file to JPEG2k in order to reduce the disk space:

Sébastien-

Mat M

unread,
Jul 17, 2018, 3:05:06 PM7/17/18
to Orthanc Users
Hello Sébastien,


On Tuesday, July 17, 2018 at 2:45:27 PM UTC-4, Sébastien Jodogne wrote:
Hello,

On Tuesday, July 17, 2018 at 8:32:04 PM UTC+2, Mat M wrote:
The source PACS is external to our institution and not controlled by us in any way.  It is a referral, meaning it can be anything and we have no way of knowing without calling the referring institution ourselves and asking them.

As a consequence, setting the "JpegLosslessTransferSyntaxAccepted" to "false" will not solve your issue in all the cases. This solution is only valid if the PACS of the referring institution has transcoding capabilities. If the latter has no such capabilities, the transfer from the referring institution to Orthanc would fail.


Ok, thanks for the information.
 
 
This is what has me wondering if I disabled the right thing.  Is there any way for the Source PACS to send JPEG-LS to Orthanc even if its disabled on Orthanc's side?

No, this is not be possible. Are you sure that you have cleared all the content of the Orthanc database after setting the option to "false"? If not, JPEG-LS files that were received before setting the option to "false" will not be readable by eFilm.


I understand that it should not be possible but I am certain that we received it, yes.  This is actually a brand new patient received this morning hence this question.  How would I be able to tell the transfer syntax used from within the logs/Orthanc Explorer?  Also, if that makes any difference, I'm using 1.3.2 though I did see that 1.4.1 was released recently and will be upgrading to it later this week.  Don't know if it will make any difference but I will report back regardless.
 
The actual solution to your problem consists in transcoding the JPEG-LS files once Orthanc receives them, either through REST scripting or through Lua scripting:

As a starting point, you can take inspiration from the following sample Lua script that is part of the Orthanc source distribution, and that transcodes any incoming DICOM file to JPEG2k in order to reduce the disk space:

Sébastien-

Thanks for this!  I'll definitely try and implement this on our end. 

Mat M

unread,
Jul 20, 2018, 2:21:50 PM7/20/18
to Orthanc Users
Hello,

First off, I apologize for my newbishness.  This is the first time I delve deep into DICOM problems beyond the usual IP/port/AET problems.  I appreciate any kind of support I may get so please forgive me if any of the followings questions sound dumb.  Please go easy on me. :)

So, I did get some response from our support but unfortunately, its not very promising.  However, FWIW, here are the logs on eFilm's side:

(2572) 07-20 11:40:57.64 MC3  W: Presentation context 1 rejected, reason 0x03
(2572) 07-20 11:40:57.64 MC3  W: |  Abstract syntax: 1.2.840.10008.5.1.4.1.2.3.1 (PATIENT_STUDY_ONLY_QR_FIND)
(2572) 07-20 11:40:57.65 MC3  W: |  Abstract Syntax Rejected
(2572) 07-20 11:40:57.65 MC3  W: Presentation context 3 rejected, reason 0x03
(2572) 07-20 11:40:57.65 MC3  W: |  Abstract syntax: 1.2.840.10008.5.1.4.1.2.3.2 (PATIENT_STUDY_ONLY_QR_MOVE)
(2572) 07-20 11:40:57.67 MC3  W: |  Abstract Syntax Rejected

I'm not 100% certain what this means but, according to this webpage (https://www.dicomlibrary.com/dicom/sop/) these syntaxes should not be used anymore as they have been retired:

1.2.840.10008.5.1.4.1.2.3.1Patient/Study Only Query/Retrieve Information Model – FINDRetired
1.2.840.10008.5.1.4.1.2.3.2Patient/Study Only Query/Retrieve Information Model – MOVERetired




I haven't been able to find this tag anywhere within Orthanc so I'm not sure where it's pulled from exactly nor have I been able to figure out how to tell the transfer syntax used in the received problematic study.  According to this page (https://www.dicomlibrary.com/dicom/dicom-tags/), it should be the DICOM tag (0002,0010) but I don't see it in Orthanc nor anywhere else for that matter.

Is there anybody who could point me in the right direction so I can confirm that the received study is indeed encoded in JPEG-LS like the error message says?  It shouldn't be since I've rejected them in the configuration file hence why I want to make sure.  If it isn't, and its using something else, I may be able to reject those syntaxes as well and possibly "fix" the problem without having to resort to transcoding all received DICOMs or at least tailor the LUA script so that it only transcodes those specific studies.

Also, is there a way to reject studies using retired DICOM SOPs?

Thanks for your time,
Mat

Mat M

unread,
Jul 24, 2018, 5:12:41 PM7/24/18
to Orthanc Users
Hello again,

So, looking at the problematic studies with DicomWorks, I can clearly see that the problematic DICOM studies are indeed using JPEG-LS despite the syntax not being enabled in Orthanc.  Here is what I found so far:

// First, the command I've been using to manually start the server for debugging purposes (please note that the service is stopped and disabled for the time being)
C:\Program Files\Orthanc Server>Orthanc.exe --trace .\Configuration\ --logdir=.\Logs\

// Next, here is the start of the logs to confirm loading the proper configuration files (especially orthanc.json)
W0724 10:59:25.698504 main.cpp:1298] Orthanc version: 1.3.2
W0724 10:59:25.698504 OrthancInitialization.cpp:168] Scanning folder ".\Configuration\" for configuration files
W0724 10:59:25.698504 OrthancInitialization.cpp:120] Reading the configuration from: ".\Configuration\dicomweb.json"
W0724 10:59:25.698504 OrthancInitialization.cpp:120] Reading the configuration from: ".\Configuration\orthanc.json"
W0724 10:59:25.698504 OrthancInitialization.cpp:120] Reading the configuration from: ".\Configuration\postgresql.json"
W0724 10:59:25.698504 OrthancInitialization.cpp:120] Reading the configuration from: ".\Configuration\serve-folders.json"
W0724 10:59:25.698504 OrthancInitialization.cpp:120] Reading the configuration from: ".\Configuration\webviewer.json"
W0724 10:59:25.698504 OrthancInitialization.cpp:120] Reading the configuration from: ".\Configuration\worklists.json"
I0724 10:59:25.698504 Toolbox.cpp:1363] Using locale: "" for case-insensitive comparison of strings
I0724 10:59:25.698504 Enumerations.cpp:1819] Default encoding for DICOM was changed to: Latin1
I0724 10:59:25.698504 FromDcmtkBridge.cpp:206] Using DCTMK version: 362
I0724 10:59:25.698504 FromDcmtkBridge.cpp:214] Loading the embedded dictionaries
I0724 10:59:25.776638 FromDcmtkBridge.cpp:226] Loading the embedded dictionary of private tags

// This part here, I'm not 100% certain if this is normal or not.  Should it be registering the JPEG Lossless codecs even if the syntax isn't accepted?
I0724 10:59:25.823523 FromDcmtkBridge.cpp:2091] Registering JPEG Lossless codecs in DCMTK
I0724 10:59:25.823523 FromDcmtkBridge.cpp:2096] Registering JPEG codecs in DCMTK

Here is the important part from the orthanc.json file:

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

  // Whether Orthanc accepts to act as C-Store SCP for unknown storage
  // SOP classes (aka. "promiscuous mode")
  "UnknownSopClassAccepted"            : false,

I attached a screenshot of the critical DICOM tags from one of the studies in question which I grabbed a screenshot of through DicomWorks.  For the record, I checked two different studies received after disabling the transfer syntax and both have the same transfer syntax UID which is:

1.2.840.10008.1.2.4.80JPEG-LS Lossless Image Compression



So, did I disable the correct thing?  Is it normal that I'm still receiving JPEG-LS images even though its disabled in the configuration?  Is it because I'm starting it from the command line?  What else could I do to help in troubleshooting this?


Thanks!
Mat
Flash Critical DICOM Tags.JPG

Sébastien Jodogne

unread,
Jul 25, 2018, 7:25:35 AM7/25/18
to Orthanc Users
Hello,

I have reproduced your issue: Setting the "JpegLosslessTransferSyntaxAccepted" to "false" has indeed no effect on Orthanc <= 1.4.1. 

The issue can be reproduced with the following DICOM JPEG-LS image that is part of the Orthanc integration tests:

The following command should fail given this option, but it erroneously succeeds:

# storescu -xt localhost 4242 1.2.840.10008.1.2.4.80.dcm -v

After digging in the code of Orthanc, I have found and fixed the issue:

This patch will be part of Orthanc 1.4.2, for which no release date is planned currently.

Thanks for reporting this issue!

Regards,
Sébastien-

NB: Regarding the sub-question: "Should Orthanc be registering the JPEG Lossless codecs even if the syntax isn't accepted?",  yes, this is expected and correct.

Mat M

unread,
Jul 25, 2018, 9:22:04 AM7/25/18
to Orthanc Users
Great news!  Thanks for taking a look at this Sébastien.  I'll be anxiously awaiting the 1.4.2 release. :)

Cheers and have a great day,
Mat

Sébastien Jodogne

unread,
Jul 25, 2018, 9:56:45 AM7/25/18
to Orthanc Users
Note that in the meantime, our continuous integration server has already updated the mainline Docker images and the mainline Linux Standard Base binaries with this fix:
http://lsb.orthanc-server.com/orthanc/mainline/

Pay however attention to the fact that these binaries are unstable (they change on an almost daily basis), and shouldn't be used in production environments.

Mat M

unread,
Jul 25, 2018, 10:13:30 AM7/25/18
to Orthanc Users
I figured as much but we're using the Windows build currently for ease of management so I'll wait for the stable release with the installer.

Thanks for the feedback!

Mat M

unread,
Jul 27, 2018, 11:39:46 AM7/27/18
to Orthanc Users
This is for anybody else who might encounter this same issue so they don't have to go through hoops like I did to finally get an answer.  I also answered this in Alex's thread here for reference (https://groups.google.com/d/msg/orthanc-users/yU-XasmYSU4/VbrRLzY2BwAJ):

I finally managed to get a list from Sound, although all they could provide me is a REALLY old (2007) DICOM conformance document for version 3.0 but I'm assuming it hasn't changed since.

Here is the interesting part of the document:


JPEG2000 should work, fortunately enough.  This means that, until 1.4.2 is released, the LUA script to transcode images to JPEG2000 should also work.  This also means that they currently do not support JPEG-LS, as expected.

Hope this helps someone in the future!

Cheers,
Mat

Mat M

unread,
Oct 29, 2018, 8:57:33 AM10/29/18
to Orthanc Users
Confirmed fixed and working in our environment.  We no longer receive JPEG-LS studies!

Thanks. :)

Sébastien Jodogne

unread,
Oct 29, 2018, 11:16:02 AM10/29/18
to Orthanc Users
Great news, thanks for the feedback!

Sébastien-
Reply all
Reply to author
Forward
0 new messages