We are pleased to announce the release of Orthanc 1.13.0!
This release notably features a complete rewrite of how DICOM files are retrieved from the storage area, parsed, and transcoded. This large-scale refactoring improves control over the memory footprint of Orthanc, while also enhancing caching and performance by reducing coupling between threads.
Several new options have consequently been introduced to fine-tune memory and CPU usage. The complete list is available in the release notes.
Besides this main change, this major release brings several new features:
The configuration file has been split into two parts, with a new file containing advanced options for experienced users. This reduces the complexity of the standard configuration file. Multiple configuration files can now be specified, providing greater flexibility when organizing the configuration of Orthanc.
The REST API has been upgraded to version 31, with new information exposed through the /system route and new metrics related to the storage, DICOM parsing, and transcoding components.
Several security and robustness improvements have been introduced, including protection against deeply nested DICOM sequences and various out-of-bounds read/write issues, as well as improvements to DICOM validation and handling.
The latest value representations introduced in the DICOM standard are supported.
The Docker packages and Windows installers will be released in the coming days. For the complete list of changes and improvements, please refer to the full release notes.
Overall, Orthanc 1.13.0 is a major step forward in terms of performance, configurability, observability, and security.
Congratulations to the new release! That sounds awful, and involves a lot of work for you and your team!
As a sunday morning activity I tried to build it for Leap 16.0 and run into errors with boost (1.86.0) as it seems.
The relevant error messages are here: openSUSE Paste
Any hints?
Many thanks
Axel
The problem is that Orthanc must now be linked with boost::program_options, which is a new Boost dependency to handle command-line arguments. Visibly, the development package is already installed on your Leap box (otherwise build would have failed earlier), so what is missing the -lbboost_program_options argument at the link step. You should give a try adding the -DORTHANC_FRAMEWORK_ADDITIONAL_LIBRARIES=boost_program_options flag when invoking CMake.
Please find attached to this message a Dockerfile illustrating how to perform a minimal build of Orthanc 1.13.0 on openSUSE Leap 16. I think you were simply missing the libboost_program_options-devel package.
Many thanks Sebastien. normally a missing dependency shows up in the config sectionâŠhowever, it compiles now.
But throws an error during test:
[ 32s] + build/UnitTests
[ 32s] E0818 05:59:31.375430 MAIN OrthancException.cpp:144] Bad file format: The configuration section âDicomAssociationCloseDelayâ i
s defined in 2 different configuration files
[ 32s] terminate called after throwing an instance of âOrthanc::OrthancExceptionâ
Hi, thatâs not a problem on the side of Orthanc, but some specificity of the Boost package in openSUSE: installing boost-devel installs the development headers of the boost::program_options library, but not the library itself. Either the development headers should not be part of boost-devel, or boost-devel should have a dependency on libboost_program_options-devel.
I am unable to reproduce this issue. Please provide a full Dockerfile which would allow me to reproduce it on my computer.
Hi Sebastien,
boost-devel seems not to be the problem (I have included it and that does not change the result).
The issue is in the testing section, when variables are defined in
OrthancServer/Resources/Configuration.json and AdvancedConfiguration.json
That seems to affect all double parameters - if I patch out one, the next one comes up :-/
See: https://build.opensuse.org/package/show/home:DocB:Orthanc/orthanc â build results â failed
So my uneducated guess it that the processing of the 2 config files runs now into an error
Chers
Axel
I thought you were referring to the unit tests, but it seems youâre actually talking about launching the main Orthanc server.
Indeed, your openSUSE package must be updated to reflect the fact that the configuration file was split in 2 files starting with Orthanc 1.13.0. If you use the new advanced.json together with your old orthanc.json, some options will be defined in the two files, preventing Orthanc from starting (as you observed). Three possibilities:
1- You keep your unique configuration file from the earlier versions of the package and you ignore the new advanced.json (simply donât create the file, or create a JSON file with the empty dictionary {}). I think Orthanc should start gracefully, as advanced settings have default values that are embedded inside the binaries. Downside: The openSUSE user will not see the new configuration options.
2- You create advanced.json by executing Orthanc --config=advanced.json, and manually remove all the options from the old configuration file orthanc.json that clash with advanced.json. Downside: The setup will not be future-proof if new options are added in next releases.
3- You regenerate both orthanc.json and advanced.json from scratch on each release of the openSUSE package. Those files can be created by respectively executing Orthanc --config=orthanc.json and Orthanc --config=advanced.json. It will be up to the user to chose whether to preserve their old, unique configuration file, or to replace this file by the new orthanc.json and advanced.json (I guess this is handled by openSUSE).
As far as Iâm concerned, I would definitely favor option 3.
Hello Sebastien,
thank you for this explanation, as written, I noticed this in between as well.
Following your 3rd point, I ran both calls (in a VM with orthanc, and without a config file)
orthanc --config=orthanc.json
orthanc --config=advanced.json
and afterwards both files have the same content.
I guess this is not desired?
Ah OK. Thank you.
So I cleaned the /etc/orthanc, created 2 new .json - config and advanced - and tried to start the orthanc service. It stops as parameter âReadOnlyâ is not defined or invalid.
In fact, it is not in the newly created files
PS: Same at least for
âDicomTlsRemoteCertificateRequiredâ
âBuiltinDecoderTranscoderOrderâ
as well
Could you please check the attached Dockerfile? It starts without any issues on my side, so there is something different in the way Orthanc is being started in your package. Are you providing the /etc/orthanc/ folder as an argument? Dockerfile.txt (421 Bytes)
Yes, I did. I started over with a new VM and a clean build, with an updated config file (and no advanced config) and nowâŠit works dont ask me why. Anyway, its on the way to Tumbleweed, Leap 16 and 16.1.
Many thanks for your support!
dont ask me why. Anyway, its on the way to Tumbleweed, Leap 16 and 16.1.