Osimis Webviewer has problems with some dcm files

Google Groups archive
1

Hi,

I am testing current version of Osimis WebViewer plugin as part of Orthanc 1.2. Good improvements btw.

However, some of my simple test files lead to bad results here and the log indicates that Osimis viewer has problems here. The same files are shown perfectly in Osirix8.

I attach two of my test files with which the problem can be reproduced. The files have been created manually from a jpg with dcmtk tool im2dcm (http://support.dcmtk.org/docs-dcmrt/img2dcm.html)

The problems are
- bad quality of image (even worse compared to the PNG directly requested via Orthanc REST API)
- red bar at bottom of viewer
- indications in Orthanc/Osimis log "low-quality etc."

best
Torsten

Relevant log extract below
I0519 15:36:05.397214 OrthancPlugins.cpp:876] Delegating HTTP request to plugin for URI: /osimis-viewer/images/6b07fa7f-5ab6465c-6963abce-bd3193ac-0653a9db/0/low-quality
T0519 15:36:05.397309 OrthancPlugins.cpp:2849] Calling service 3001 from plugin /Users/ts/Orthanc1.2/libOsimisWebViewer.dylib
I0519 15:36:05.397348 OrthancPlugins.cpp:1294] Plugin making REST GET call on URI /instances/6b07fa7f-5ab6465c-6963abce-bd3193ac-0653a9db/simplified-tags (built-in API)
T0519 15:36:05.397409 Statement.cpp:144] SQLite::Statement::Step SELECT internalId, resourceType FROM Resources WHERE publicId=?
T0519 15:36:05.397538 Statement.cpp:144] SQLite::Statement::Step SELECT uuid, uncompressedSize, compressionType, compressedSize, uncompressedMD5, compressedMD5 FROM AttachedFiles WHERE id=? AND fileType=?
I0519 15:36:05.397610 FilesystemStorage.cpp:154] Reading attachment "677EB04F-33E2-49EE-A832-C91DE8CE47DE" of "JSON summary of DICOM" content type
T0519 15:36:05.397723 OrthancPlugins.cpp:2849] Calling service 3001 from plugin /Users/ts/Orthanc1.2/libOsimisWebViewer.dylib
I0519 15:36:05.397770 OrthancPlugins.cpp:1294] Plugin making REST GET call on URI /instances/6b07fa7f-5ab6465c-6963abce-bd3193ac-0653a9db/frames/0/raw (built-in API)
T0519 15:36:05.397813 MemoryCache.cpp:46] Reusing a cache page
T0519 15:36:05.398248 OrthancPlugins.cpp:2849] Calling service 6014 from plugin /Users/ts/Orthanc1.2/libOsimisWebViewer.dylib
I0519 15:36:05.398303 PluginsManager.cpp:171] Decoding one DICOM instance of 0.6MB using GDCM
I0519 15:36:05.398548 PluginsManager.cpp:171] ImageProcessingPolicy: PixelDataQualityPolicy
I0519 15:36:05.398582 PluginsManager.cpp:171] ImageProcessingPolicy: KLVEmbeddingPolicy
T0519 15:36:05.398680 OrthancPlugins.cpp:2849] Calling service 2000 from plugin /Users/ts/Orthanc1.2/libOsimisWebViewer.dylib
E0519 15:36:05.400774 PluginsManager.cpp:163] Cannot decode image using GDCM: GDCM cannot change the photometric interpretation
I0519 15:36:05.401006 OrthancPlugins.cpp:3090] The installed image decoding plugins cannot handle an image, fallback to the built-in decoder
I0519 15:36:05.401889 DicomImageDecoder.cpp:575] Decoding a JPEG baseline (process 1) DICOM image
T0519 15:36:05.431475 HttpOutput.cpp:369] Compressing a HTTP answer using gzip
T0519 15:36:05.441431 OrthancPlugins.cpp:2849] Calling service 6000 from plugin /Users/ts/Orthanc1.2/libOsimisWebViewer.dylib
T0519 15:36:05.441503 OrthancPlugins.cpp:2849] Calling service 6001 from plugin /Users/ts/Orthanc1.2/libOsimisWebViewer.dylib
T0519 15:36:05.441537 OrthancPlugins.cpp:2849] Calling service 6002 from plugin /Users/ts/Orthanc1.2/libOsimisWebViewer.dylib
T0519 15:36:05.441572 OrthancPlugins.cpp:2849] Calling service 6003 from plugin /Users/ts/Orthanc1.2/libOsimisWebViewer.dylib
T0519 15:36:05.441605 OrthancPlugins.cpp:2849] Calling service 6004 from plugin /Users/ts/Orthanc1.2/libOsimisWebViewer.dylib
I0519 15:36:05.441645 PluginsManager.cpp:171] ImageProcessingPolicy: LowQualityPolicy
I0519 15:36:05.441666 PluginsManager.cpp:171] ImageProcessingPolicy: CompositePolicy
I0519 15:36:05.441687 PluginsManager.cpp:171] ImageProcessingPolicy: ResizePolicy
T0519 15:36:05.442411 OrthancPlugins.cpp:2849] Calling service 6006 from plugin /Users/ts/Orthanc1.2/libOsimisWebViewer.dylib
I0519 15:36:05.443097 PluginsManager.cpp:171] ImageProcessingPolicy: Uint8ConversionPolicy
I0519 15:36:05.443124 PluginsManager.cpp:171] ImageProcessingPolicy: JpegConversionPolicy
T0519 15:36:05.443160 OrthancPlugins.cpp:2849] Calling service 6007 from plugin /Users/ts/Orthanc1.2/libOsimisWebViewer.dylib
I0519 15:36:05.445510 PluginsManager.cpp:171] ImageProcessingPolicy: KLVEmbeddingPolicy
T0519 15:36:05.445577 OrthancPlugins.cpp:2849] Calling service 2000 from plugin /Users/ts/Orthanc1.2/libOsimisWebViewer.dylib
T0519 15:36:05.447100 HttpOutput.cpp:369] Compressing a HTTP answer using gzip

IM-0001-10000.dcm (627 KB)

IM-0001-10000.dcm (495 KB)

2

I can reproduce, thanks a lot for the report!

(Indeed the high-quality images are never loaded.)

We're tracking this issue internally and will report once we have a
resolution.

3

Hello,

However, some of my simple test files lead to bad results here and the log indicates that Osimis viewer has problems here. The same files are shown perfectly in Osirix8. […]

The problems are

  • bad quality of image (even worse compared to the PNG directly requested via Orthanc REST API)
  • red bar at bottom of viewer
  • indications in Orthanc/Osimis log “low-quality etc.”

Please could you confirm that this issue is only present in Osimis Web viewer?

I am indeed unable to reproduce your problems with Orthanc Web viewer.

Regards,
Sébastien-

4

Hello,

Could you please send us the your orthanc json config file ?
We’ll fix this as soon as possible once we’re able to reproduce the issue.

Kind Regards,
Thibault.

5

Hi Thibault,

you have already confirmed to be able to reproduce the problem, haven’t you?
I think it has nothing to do with orthanc.json here.

BR
Torsten

6

Hello,

Actually it was Thibault Nélis, but mistake is mine as he did forwa
The instance contains a compressed RGB JPEG.
This bug is related to the frontend decompression library we use.

We can’t solve it right away without hurting the performance of the viewer.

Kind Regards,
Thibault

7

Hello,

Actually it was Thibault Nélis, but mistake is mine as he did forward the issue.

The instance contains a compressed RGB JPEG.
This bug is related to the frontend decompression library we use.

We can’t solve it right away without hurting the performance of the viewer.

Kind Regards,
Thibault