I’m posting this in the hope of a possible low-hanging fruit performance improvement.
We are testing a recent feature in the OHIF viewer (still in beta) that makes it possible to explicitly set the transfer syntax of the requested image data (configurable Accept header).
I noticed that while our OHIF viewer is loading frames, Orthanc always logs lines like the following even if the requested transfer syntax is the same as that of the stored instance:
I1005 23:29:13.617946 PluginsManager.cpp:161] (plugins) DICOMweb RetrieveFrames: Transcoding instance 89875e6a-7ac4fe47-20dad417-53add7ca-47dd2a8c to transfer syntax 1.2.840.10008.1.2.4.70
On this line: https://hg.orthanc-server.com/orthanc-dicomweb/file/tip/Plugin/WadoRsRetrieveFrames.cpp#l463 , the code indeed first logs that it will do some transcoding (regardless of the actual transfer syntax of the stored instance). After that I got lost in trying to trace back what happens exactly, but I suspect that some unnecessary “transcoding” takes place from A → A transfer syntax which might be wasting considerable CPU time.
Some numbers with my test data:
If I request the same transfer syntax as stored, then on my machine, retrieving a frame takes about 0.8s.
If I request a different transfer syntax, then retrieving the frame takes about 4s.
This suggests that processing is much faster when there would be no need to transcode, but maybe Orthanc still does unnecessary processing.
Are my assumptions correct?
If so, can we add a check to see if the current transfer syntax of the stored instance is the same as the requested one?
Even if there is not much performance to be gained, we should only log “Transcoding instance …” if we really are doing transcoding, otherwise it is confusing for someone looking at the logs.
