Created attachment 32 [details]
US000000.dcm

[BitBucket user: Zsolt Bagyura]
[BitBucket date: 2020-01-17.22:31:20]

Hi, 

Further information that might help: the images can be viewed with an older version of orthanc \(1.3.1\) webviewer 2.3.

[BitBucket user: András Sallai]
[BitBucket date: 2020-01-18.22:57:46]

Could it be coming from this line?

https://bitbucket.org/sjodogne/orthanc-dicomweb/annotate/8b8b8cef7722779ac10a0ac1480b2eed7513844e/Plugin/WadoRsRetrieveFrames.cpp?at=default&fileviewer=file-view-default#WadoRsRetrieveFrames.cpp-421

[BitBucket user: Alain Mazy]
[BitBucket date: 2020-01-20.09:28:50]

After some digging in the DicomWeb plugin, we get this error in the logs:



```
I0120 10:08:52.707474 PluginsManager.cpp:172] DICOMweb RetrieveFrames: Transcoding instance da3e1026-7dc4d6f1-c2dd8be7-081b8a6f-4235b995 from transfer syntax 1.2.840.10008.1.2.4.50 to 1.2.840.10008.1.2.1
Warning: In C:\Users\alain\osimis\build-orthanc-dicomweb-Ninja64-Default\GDCM-prefix\src\GDCM\Source\MediaStorageAndFileFormat\gdcmImageHelper.cxx, line 1140, function <unknown>
FIXME

E0120 10:10:37.055004 PluginsErrorDictionary.cpp:111] Exception inside the plugin engine: Internal error
```

Coming from this piece of code in GDCM:



```
  case MediaStorage::UltrasoundMultiFrameImageStorage:
    // gdcmData/US-MONO2-8-8x-execho.dcm
    // this should be handled somewhere else
    //assert(0);
    gdcmWarningMacro( "FIXME" );
    t = Tag(0xffff,0xffff);
    break;
```

It should work with t = Tag\(`0x0028,0x0030`\) \(disclaimer: not test\).  Note: we’re still using GDCM 2.8.8 but this has not been fixed in latest GDCM version.  

Note that we hope to get rid of GDCM in DicomWeb once we implement a transcoding plugin in Orthanc.  The plugin is currently foreseen for Q2 2020…

[BitBucket user: Alain Mazy]
[BitBucket date: 2020-01-20.09:53:33]

Concerning the issue in the OrthancViewer, when starting the viewer with the default configuration, here are the GDCM errors we get in the logs:



```
Not a JPEG file: starts with 0x00 0x00
```



I had no time to get in deeper …  As a workaround, you can configure the viewer with this config to use GDCM only for JP2K decoding and use DCMTK for all other decoding.  That’s actually the ideal configuration.



```
"WebViewer" : {
    "EnableGdcm" : true,
    "RestrictTransferSyntaxes" : [
      "1.2.840.10008.1.2.4.90",   // JPEG 2000 Image Compression (Lossless Only)
      "1.2.840.10008.1.2.4.91",   // JPEG 2000 Image Compression
      "1.2.840.10008.1.2.4.92",   // JPEG 2000 Part 2 Multicomponent Image Compression (Lossless Only)
      "1.2.840.10008.1.2.4.93"    // JPEG 2000 Part 2 Multicomponent Image Compression
    ]
  }
```

[BitBucket user: András Sallai]
[BitBucket date: 2020-01-20.10:54:55]

Thanks for the info!

We want **to make it work with the OHIF viewer** so I’m not sure if this will help us. If this changes how Orthanc decodes images for the DICOMweb API, then it might. But then it should not be part of the WebViewer configuration.

[BitBucket user: Alain Mazy]
[BitBucket date: 2020-01-20.10:57:06]

Indeed, the WebViewer configuration will not affect the DicomWeb … so, the only way to solve it currently is by fixing GDCM \(and compile Orthanc against that fixed GDCM version\).

[BitBucket user: András Sallai]
[BitBucket date: 2020-01-21.06:05:07]

BTW, @{557058:506c8cac-b5f5-42d4-9991-550a3a685e3d} , how did you get that GDCM warning to show up in the Orthanc logs?

[BitBucket user: Alain Mazy]
[BitBucket date: 2020-01-21.08:27:52]

I ran Orthanc from the command line and checked the output.  I think the Orthanc logs actually contains stderr only while this “warning” is in stdout.

[BitBucket user: Sébastien Jodogne]
[BitBucket date: 2020-02-04.09:34:11]

Follow-up: The problem reported in the Orthanc/Osimis Web viewer plugins vanishes if the `jodogne/orthanc-plugins:latest` image is used instead of `jodogne/orthanc-plugins:1.5.8`. This is a direct consequence of the upgrade of GDCM from version 2.8.4 \(in image “1.5.8”\) to version 3.0.4 \(in image “latest”\).

Regarding the DICOMweb plugin, this looks like a bug to be reported to GDCM: https://sourceforge.net/p/gdcm/bugs/

[BitBucket user: Sébastien Jodogne]
[BitBucket date: 2020-02-04.10:48:07]

After a more in-depth analysis, it turns on that the “FIXME” warning from GDCM was a false alarm, and it totally unrelated to this issue.

I have just committed a fix that solves this issue ni the mainline version of the DICOMweb plugin: https://hg.orthanc-server.com/orthanc-dicomweb/changeset/2977ef0eabbb0700a593e58ef23ab284acd95b83

Obviously, I would be happy to have the feedback from OHIF team! poke @{557058:0c4b66f7-21ff-4e2d-8be2-270827f5cab7}

[BitBucket user: András Sallai]
[BitBucket date: 2020-02-04.15:03:28]

@{557058:9abedbc7-f66f-45c9-95e8-9b6fee22c7c3} great news! Does this mean that it is available in the `latest` tag of the orthanc-plugins docker image?

[BitBucket user: Sébastien Jodogne]
[BitBucket date: 2020-02-04.15:32:48]

The `jodogne/orthanc-plugins:latest` has just been updated with the new mainline version of the DICOMweb plugin.