Crashes on housekeeper transcode storing in S3

General
1

Hello,

changed transcoding from .70 to .50 but crashes during housekeeper update, specifically storing in S3
running 1.12.4 in Docker 27.3.1

I1110 20:17:51.654262 HOUSEKEEPER AWS S3 Storage:/StoragePlugin.cpp:259] AWS S3 Storage: read whole attachment 4682f990-fdb8-48a5-bd53-132278f5150e (591.83 KB in 47.64ms = 101.77Mbps)
I1110 20:17:51.664874 HOUSEKEEPER ServerContext.cpp:2058] The installed transcoding plugins cannot handle an image, fallback to the built-in DCMTK transcoder
I1110 20:17:51.665119 HOUSEKEEPER DcmtkTranscoder.cpp:347] DCMTK transcoding from 1.2.840.10008.1.2.4.70 to one of: 1.2.840.10008.1.2.4.50
I1110 20:17:51.693459 HOUSEKEEPER FromDcmtkBridge.cpp:1692] (dicom) Transcoded an image from transfer syntax 1.2.840.10008.1.2.4.70 to 1.2.840.10008.1.2.4.50
I1110 20:17:51.694591 HOUSEKEEPER AWS S3 Storage:/StoragePlugin.cpp:110] AWS S3 Storage: creating attachment 23ba519e-6b5b-481b-85f1-141f353b59e4 of type 1
I1110 20:17:51.739996 HOUSEKEEPER AWS S3 Storage:/StoragePlugin.cpp:134] AWS S3 Storage: created attachment 23ba519e-6b5b-481b-85f1-141f353b59e4 (209.82KB in 45.40ms = 37.86Mbps)
E1110 20:17:51.743008 HOUSEKEEPER OrthancException.cpp:62] Internal error: New instance while reconstructing; this should not happen.
E1110 20:17:51.743268 HOUSEKEEPER ServerContext.cpp:729] Unexpected error while storing an instance in DB, cancelling and deleting the attachments: New instance while reconstructing; this should not happen.
I1110 20:17:51.743302 HOUSEKEEPER AWS S3 Storage:/StoragePlugin.cpp:317] AWS S3 Storage: deleting attachment 23ba519e-6b5b-481b-85f1-141f353b59e4 of type 1 terminate called after throwing an instance of ‘OrthancPlugins::PluginException’

config (via Docker env var) attached
orthancdocker.txt (2.4 KB)

Thanks in advance for any thoughts on this

2

Hello Oliver,

I think you’ve just triggered an edge case that was not planned in Orthanc.

Actually, you are using a lossy transfer syntax and, as explained in the IngestTranscoding documentation:

// ... Also, beware that transcoding to a transfer
// syntax with lossy compression (notably JPEG) will change the
// "SOPInstanceUID" DICOM tag, and thus the Orthanc identifier at
// the instance level, which might break external workflow.

In human medicine, it is usually not accepted to use lossy compression therefore, Orthanc generates new SOPIntanceUID to avoid overwriting the original full quality image.

So I think the Housekeeper should just refuse to start if you are using a lossy transfer syntax because that would generate new orthanc ids as well and there is a risk of messing up things.

Best regards,

Alain.