Azure blob storage connection issue

Hello,

I have used below docker for azure blob.
docker run -p 8042:8042 -p 4242:4242 -v plugin-config.json:/etc/orthanc/plugin-config.json mschmieder/orthanc-plugins:latest.

And Configurations:-
“AzureBlobStorage” : {
“EnableStorage” : true,
“ConnectionString”: “DefaultEndpointsProtocol=https;AccountName=XXXXXX;AccountKey=XXXXXX;EndpointSuffix=core.windows.net”,
“ContainerName” : “XXXXX”,
“CreateContainerIfNotExists”: true, // available from version 1.2.0
“RootPath”: “”, // see below
“MigrationFromFileSystemEnabled”: false, // see below
“StorageStructure”: “flat”, // see below
“EnableLegacyUnknownFiles”: true, // optional: see below
“StorageEncryption” : {} , // optional: see the section related to encryption
“HybridMode”: “WriteToObjectStorage” // optional: see the section related to Hybrid storage
}

Below is the screenshot of an error:-

Please help me as soon as possible.

Regards,
Avijit

Hi Avijit,

Seems you are using a custom azure storage plugin: and a custom docker image that have not been updated for years.

I would strongly recommend using the osimis/orthanc:23.3.5-full image and follow these instructions

HTH,

Alain

Hello Alain

I appreciate your response.

I tried the osimis/orthanc:23.3.5-full docker image, but I am having trouble mounting the orthanc.json configuration file with my local file. I cannot find orthanc.json file in a docker image /etc/orthanc folder If you can help, that would be greatly appreciated.

Thanks,
Avijit

Hello

The Osimis image /etc/orthanc folder is empty in the image, this is normal. You have to mount your configuration file(s) in it for the Orthanc startup scripts to use it (or them: all files matching *.json will be processed).

For instance, you can use the following command to map the toto.json file in the /etc/orthanc directory, where it will be used as a configuration file.

docker run -p 8042:8042 --rm -v $(pwd)/toto.json:/etc/orthanc/toto.json:ro osimis/orthanc:22.2.2

(pay no attention to 22.2.2 … I just wanted to avoid pulling a new image)

Please note that $(pwd)/ is important, and ./toto.json would not work, because the file is read in the context of the Docker daemon that is not running in the same directory.

What kind of trouble do you have?

Hi Avijit,

This page explains how to configure the osimis/orthanc images.

Here is a sample related to Azure storage plugin.

HTH,

Alain

HI Benjamin,

Thank you for your response,

I am actually trying to run “docker run --entrypoint=cat osimis/orthanc /etc/orthanc/orthanc.json > /var/tmp/orthancisimis.json”
where /var/tmp/ is my local directory but i am getting an error “cat: /etc/orthanc/orthanc.json: No such file or directory”.

Please check the below screenshot:-

Thanks,
Avijit

Hi Avijit
Your error is normal. There is no orthanc.json file in the Osimis image.

The instructions that you’re using are for the jodogne/orthanc image. The Osimis one is different (see links above)

You simply need to provide your own piece of configuration, including the one for the Azure Blob Storage, and ensure that YOUR file sits in /etc/orthanc in the running container, as my example demonstrates.

Hope this helps.

Hi Benjamin,

Can you please tell me what exactly i have to run i mean how i will get orthanc.json configuration file and how i will put it in /etc/orthanc folder of an image.

I am running this "docker run -p 5252:5252 -p 8052:8052 -v /var/tmp/orthanc.json:/etc/orthanc/orthanc.json:ro osimis/orthanc:22.2.2 "

And getting this error " Traceback (most recent call last):
File “/startup/generateConfiguration.py”, line 36, in
with open(filePath, “r”) as f:
IsADirectoryError: [Errno 21] Is a directory: ‘/etc/orthanc/orthanc.json’ "

I know i am doing something wrong it will be very helpful for me if you please tell me what exactly i have to put in the below command:-
“docker run -p 5252:5252 -p 8052:8052 -v /var/tmp/orthancosimis.json:/etc/orthanc/orthanc.json:ro osimis/orthanc:22.2.2”

already 1 container running on port 8042 thats why i am using different port number.

Thanks,
Avijit

Hi Avijit

I had the same problem as you when trying

docker run -p 5252:5252 -p 8052:8052 -v ./orthanc.json:/etc/orthanc/orthanc.json:ro osimis/orthanc:22.2.2

(notice the ./), because my file could not be found by the Docker daemon. When you try to map a file that does not exist, it indeed gets seen as a directory inside the container.

Maybe for some reason your Docker daemon cannot see the file. Can you please perform the following test :

  1. copy the file in the current directory (the one you’re executing the commands from)
  2. Execute chmod 777 ./orthanc.json to make it readable by everyone
  3. Execute docker run -p 5252:5252 -p 8052:8052 -v $(pwd)/orthanc.json:/etc/orthanc/orthanc.json:ro osimis/orthanc:22.2.2 again and post the result here.

You’re using bash or zsh (Linux or macOS), right?

If it works, it seems that either:

  • your file is not actually in /var/tmp
  • there’s a typo in the name
  • the file permissions are not readable by the daemon

I suspect the latter…

In any case, if your config file contains secrets, do not forget to change back the permissions when this is sorted out!

Hi Benjamin,

I followed your instruction now its giving different error please check the screenshot below:-

please check my configuration file below :-

{
“Name” : “Orthanc Azure Blob Storage”,

// Path to the directory that holds the heavyweight files (i.e. the
// raw DICOM instances). Backslashes must be either escaped by
// doubling them, or replaced by forward slashes “/”.
“StorageDirectory” : “/var/lib/orthanc/db”,

// Path to the directory that holds the SQLite index (if unset, the
// value of StorageDirectory is used). This index could be stored on
// a RAM-drive or a SSD device for performance reasons.
“IndexDirectory” : “/var/lib/orthanc/db”,

// Path to the directory where Orthanc stores its large temporary
// files. The content of this folder can be safely deleted once
// Orthanc is stopped. The folder must exist. The corresponding
// filesystem must be properly sized, given that for instance a ZIP
// archive of DICOM images created by a job can weight several GBs,
// and that there might be up to “min(JobsHistorySize,
// MediaArchiveSize)” archives to be stored simultaneously. If not
// set, Orthanc will use the default temporary folder of the
// operating system (such as “/tmp/” on UNIX-like systems, or
// “C:/Temp” on Microsoft Windows).
// “TemporaryDirectory” : “/tmp/Orthanc/”,

// Enable the transparent compression of the DICOM instances
“StorageCompression” : false,

// Maximum size of the storage in MB (a value of “0” indicates no
// limit on the storage size)
“MaximumStorageSize” : 0,

// Maximum number of patients that can be stored at a given time
// in the storage (a value of “0” indicates no limit on the number
// of patients)
“MaximumPatientCount” : 0,

// List of paths to the custom Lua scripts that are to be loaded
// into this instance of Orthanc
“LuaScripts” : [
],

// List of paths to the plugins that are to be loaded into this
// instance of Orthanc (e.g. “./libPluginTest.so” for Linux, or
// “./PluginTest.dll” for Windows). These paths can refer to
// folders, in which case they will be scanned non-recursively to
// find shared libraries. Backslashes must be either escaped by
// doubling them, or replaced by forward slashes “/”.

“Plugins” : [
“/usr/share/orthanc/plugins”, “/usr/local/share/orthanc/plugins”
],

// Maximum number of processing jobs that are simultaneously running
// at any given time. A value of “0” indicates to use all the
// available CPU logical cores. To emulate Orthanc <= 1.3.2, set
// this value to “1”.
“ConcurrentJobs” : 2,

/**

  • Configuration of the HTTP server
    **/

// Enable the HTTP server. If this parameter is set to “false”,
// Orthanc acts as a pure DICOM server. The REST API and Orthanc
// Explorer will not be available.
“HttpServerEnabled” : true,

// Enable/disable the Orthanc Explorer Web user interface. This
// option is only meaningful if the “HttpServerEnabled” option is
// set to “true” (new in Orthanc 1.8.2).
“OrthancExplorerEnabled” : true,

// HTTP port for the REST services and for the GUI
“HttpPort” : 8052,

// When the following option is “true”, if an error is encountered
// while calling the REST API, a JSON message describing the error
// is put in the HTTP answer. This feature can be disabled if the
// HTTP client does not properly handles such answers.
“HttpDescribeErrors” : true,

// Enable HTTP compression to improve network bandwidth utilization,
// at the expense of more computations on the server. Orthanc
// supports the “gzip” and “deflate” HTTP encodings.
“HttpCompressionEnabled” : true,

// Enable the publication of the content of the Orthanc server as a
// WebDAV share (new in Orthanc 1.8.0). On the localhost, the WebDAV
// share is mapped as “http://localhost:8042/webdav/”.
“WebDavEnabled” : true,

// Whether to allow deletions through the WebDAV share. This is
// disabled by default to avoid accidental loss of DICOM instances.
“WebDavDeleteAllowed” : false,

// Whether to allow uploads through the WebDAV share.
“WebDavUploadAllowed” : true,

/**

  • Configuration of the DICOM server
    **/

// Enable the DICOM server. If this parameter is set to “false”,
// Orthanc acts as a pure REST server. It will not be possible to
// receive files or to do query/retrieve through the DICOM protocol.
“DicomServerEnabled” : true,

// The DICOM Application Entity Title (cannot be longer than 16
// characters)
“DicomAet” : “ORTHANC_AZURE”,

// Check whether the called AET corresponds to the AET of Orthanc
// during an incoming DICOM SCU request
“DicomCheckCalledAet” : false,

// The DICOM port
“DicomPort” : 5252,

// The default encoding that is assumed for DICOM files without
// “SpecificCharacterSet” DICOM tag, and that is used when answering
// C-FIND requests (including worklists). The allowed values are
// “Ascii”, “Utf8”, “Latin1”, “Latin2”, “Latin3”, “Latin4”,
// “Latin5”, “Cyrillic”, “Windows1251”, “Arabic”, “Greek”, “Hebrew”,
// “Thai”, “Japanese”, “Chinese”, “JapaneseKanji”, “Korean”, and
// “SimplifiedChinese”.
“DefaultEncoding” : “Latin1”,

// The transfer syntaxes that are accepted by Orthanc C-STORE SCP.
// This is an array listing the accepted transfer syntax UIDs. Each
// entry can contain wildcards (“?” or “"). By default, all the
// known transfer syntaxes are accepted. (new in Orthanc 1.9.0)
“AcceptedTransferSyntaxes” : [ "1.2.840.10008.1.
” ],

// User-friendly groups of transfer syntaxes that can be enabled or
// disabled at once. These options are applied after the main
// “AcceptedTransferSyntaxes” option has been applied (if present).
/**
“DeflatedTransferSyntaxAccepted” : true,
“JpegTransferSyntaxAccepted” : true,
“Jpeg2000TransferSyntaxAccepted” : true,
“JpegLosslessTransferSyntaxAccepted” : true,
“JpipTransferSyntaxAccepted” : true,
“Mpeg2TransferSyntaxAccepted” : true,
“RleTransferSyntaxAccepted” : true,
“Mpeg4TransferSyntaxAccepted” : true, // New in Orthanc 1.6.0
“H265TransferSyntaxAccepted” : true, // New in Orthanc 1.9.0
**/

// Whether Orthanc accepts to act as C-STORE SCP for unknown storage
// SOP classes (aka. “promiscuous mode”)
“UnknownSopClassAccepted” : false,

// Set the timeout (in seconds) after which the DICOM associations
// are closed by the Orthanc SCP (server) if no further DIMSE
// command is received from the SCU (client).
“DicomScpTimeout” : 30,

/**

  • Security-related options for the HTTP server
    **/

// Whether remote hosts can connect to the HTTP server
“RemoteAccessAllowed” : true,

// Whether or not SSL is enabled
“SslEnabled” : false,

// Path to the SSL certificate used by the HTTP server. The file
// must be stored in the PEM format, and must contain both the
// certificate and the private key. This option is only meaningful
// if “SslEnabled” is true.
“SslCertificate” : “certificate.pem”,

// Sets the minimum accepted SSL protocol version
// (cf. “ssl_protocol_version” option of civetweb). By default,
// require SSL 1.2. This option is only meaningful if “SslEnabled”
// is true. (new in Orthanc 1.8.2)
//
// Value => Protocols
// 0 SSL2+SSL3+TLS1.0+TLS1.1+TLS1.2
// 1 SSL3+TLS1.0+TLS1.1+TLS1.2
// 2 TLS1.0+TLS1.1+TLS1.2
// 3 TLS1.1+TLS1.2
// 4 TLS1.2
“SslMinimumProtocolVersion” : 4,

// Set the accepted ciphers for SSL connections. The ciphers must be
// provided as a list of strings. If not set, this will default to
// FIPS 140-2 ciphers. This option is only meaningful if
// “SslEnabled” is true. (new in Orthanc 1.8.2)
/**
“SslCiphersAccepted” : [ “AES128-GCM-SHA256” ],
**/

// Whether or not peer client certificates shall be checked. This
// option is only meaningful if “SslEnabled” is true.
“SslVerifyPeers” : false,

// Path to a file containing the concatenation of the client SSL
// certificate(s) that are trusted to verify the identify of remote
// HTTP clients. The individual certificate(s) must be stored in the
// PEM format. This option is only meaningful if “SslVerifyPeers”
// is true.
“SslTrustedClientCertificates” : “trustedClientCertificates.pem”,

// Whether or not the password protection is enabled (using HTTP
// basic access authentication). Starting with Orthanc 1.5.8, if
// “AuthenticationEnabled” is not explicitly set, authentication is
// enabled iff. remote access is allowed (i.e. the default value of
// “AuthenticationEnabled” equals that of “RemoteAccessAllowed”).
/**
“AuthenticationEnabled” : true,
**/

// The list of the registered users. Because Orthanc uses HTTP
// Basic Authentication, the passwords are stored as plain text.
“RegisteredUsers” : {
“alice” : “alice”
},

/**

  • Security-related options for the DICOM connections (SCU/SCP)
    **/

// Whether DICOM TLS is enabled in the Orthanc SCP (new in Orthanc 1.9.0)
“DicomTlsEnabled” : false,

// Path to the TLS certificate file (in PEM format) to be used for
// both Orthanc SCP (incoming DICOM connections) and Orthanc SCU
// (outgoing DICOM connections). Note that contrarily to the
// “SslCertificate” option, the certificate and its private key must
// be split into two separate files. (new in Orthanc 1.9.0)
/**
“DicomTlsCertificate” : “orthanc.crt”,
**/

// Path to the file containing the private key (in PEM format) that
// corresponds to the TLS certificate specified in option
// “DicomTlsCertificate”. (new in Orthanc 1.9.0)
/**
“DicomTlsPrivateKey” : “orthanc.key”,
**/

// Path to a file containing all the TLS certificates that Orthanc
// can trust, both for its SCP (incoming DICOM connections) and SCU
// (outgoing DICOM connections). This file must contain a sequence
// of PEM certificates. (new in Orthanc 1.9.0)
/**
“DicomTlsTrustedCertificates” : “trusted.crt”,
**/

// Whether Orthanc rejects DICOM TLS connections to/from remote
// modalities that do not provide a certificate. Setting this option
// to “true” (resp. “false”) corresponds to “–require-peer-cert”
// (resp. “–verify-peer-cert”) in the DCMTK command-line
// tools. (new in Orthanc 1.9.3)
“DicomTlsRemoteCertificateRequired” : true,

// Whether the Orthanc SCP allows incoming C-ECHO requests, even
// from SCU modalities it does not know about (i.e. that are not
// listed in the “DicomModalities” option above). Orthanc 1.3.0
// is the only version to behave as if this argument were set to “false”.
“DicomAlwaysAllowEcho” : true,

// Whether the Orthanc SCP allows incoming C-STORE requests, even
// from SCU modalities it does not know about (i.e. that are not
// listed in the “DicomModalities” option above)
“DicomAlwaysAllowStore” : true,

// Whether the Orthanc SCP allows incoming C-FIND requests, even
// from SCU modalities it does not know about (i.e. that are not
// listed in the “DicomModalities” option above). Setting this
// option to “true” implies security risks. (new in Orthanc 1.9.0)
“DicomAlwaysAllowFind” : false,

// Whether the Orthanc SCP allows incoming C-GET requests, even
// from SCU modalities it does not know about (i.e. that are not
// listed in the “DicomModalities” option above). Setting this
// option to “true” implies security risks. (new in Orthanc 1.9.0)
“DicomAlwaysAllowGet” : false,

// Whether the Orthanc SCP allows incoming C-MOVE requests, even
// from SCU modalities it does not know about (i.e. that are not
// listed in the “DicomModalities” option above). Setting this
// option to “true” implies security risks. (new in Orthanc 1.9.7)
“DicomAlwaysAllowMove” : false,

// Whether Orthanc checks the IP/hostname address of the remote
// modality initiating a DICOM connection (as listed in the
// “DicomModalities” option above). If this option is set to
// “false”, Orthanc only checks the AET of the remote modality.
“DicomCheckModalityHost” : false,

/**

  • Network topology
    **/

// The list of the known DICOM modalities. This option is ignored if
// “DicomModalitiesInDatabase” is set to “true”, in which case you
// must use the REST API to define modalities.
“DicomModalities” : {
/**
* Uncommenting the following line would enable Orthanc to
* connect to an instance of the “storescp” open-source DICOM
* store (shipped in the DCMTK distribution), as started by the
* command line “storescp 2000”. The first parameter is the
* AET of the remote modality (cannot be longer than 16
* characters), the second one is the remote network address,
* and the third one is the TCP port number corresponding
* to the DICOM protocol on the remote modality (usually 104).
**/

/**
 * A fourth parameter is available to enable patches for
 * specific PACS manufacturers. The allowed values are currently:
 * - "Generic" (default value),
 * - "GenericNoWildcardInDates" (to replace "*" by "" in date fields 
 *   in outgoing C-FIND requests originating from Orthanc),
 * - "GenericNoUniversalWildcard" (to replace "*" by "" in all fields
 *   in outgoing C-FIND SCU requests originating from Orthanc),
 * - "Vitrea",
 * - "GE" (Enterprise Archive, MRI consoles and Advantage Workstation
 *   from GE Healthcare).
 *
 * This parameter is case-sensitive.
 **/
// "vitrea" : [ "VITREA", "192.168.1.1", 104, "Vitrea" ]

/**
 * By default, the Orthanc SCP accepts all DICOM commands (C-ECHO,
 * C-STORE, C-FIND, C-MOVE, C-GET and storage commitment) issued by the
 * registered remote SCU modalities. Starting with Orthanc 1.5.0,
 * it is possible to specify which DICOM commands are allowed,
 * separately for each remote modality, using the syntax
 * below.
 *
 * The "AllowEcho" (resp.  "AllowStore") option only has an effect
 * respectively if global option "DicomAlwaysAllowEcho"
 * (resp. "DicomAlwaysAllowStore") is set to "false".
 *
 * Starting with Orthanc 1.7.0, "AllowTranscoding" can be used to
 * disable the transcoding to uncompressed transfer syntaxes if
 * this remote modality doesn't support compressed transfer
 * syntaxes. This option currently applies to Orthanc C-GET SCP
 * and to Orthanc C-STORE SCU. This option only has an effect if
 * the global option "EnableTranscoding" is set to "true".
 *
 * By default, all "Allow*" options are true.
 * "AllowStorageCommitment" is actually an alias for 
 * "AllowNAction" & "AllowEventReport".
 * 
 * The "UseDicomTls" option specifies whether DICOM TLS should be
 * used when opening a SCU connection from Orthanc to this remote
 * modality. By default, DICOM TLS is not enabled.
 *
 * The "LocalAet" option allows one to overwrite the global
 * "DicomAet" configuration option in order to specify another AET
 * for Orthanc when initiating an SCU to this very specific
 * modality. Similarly, "Timeout" allows one to overwrite the
 * global value "DicomScuTimeout" on a per-modality basis.
 **/
//"untrusted" : {
//  "AET" : "ORTHANC",
//  "Port" : 104,
//  "Host" : "127.0.0.1",
//  "Manufacturer" : "Generic",
//  "AllowEcho" : false,
//  "AllowFind" : false,
//  "AllowGet"  : false,
//  "AllowMove" : false,
//  "AllowStore" : true,
//  "AllowStorageCommitment" : false,  // new in 1.6.0
//  "AllowTranscoding" : true,         // new in 1.7.0
//  "UseDicomTls" : false              // new in 1.9.0
//  "LocalAet" : "HELLO"               // new in 1.9.0
//  "Timeout" : 60                     // new in 1.9.1
//}

},

// Whether to store the DICOM modalities in the Orthanc database
// instead of in this configuration file (new in Orthanc 1.5.0)
“DicomModalitiesInDatabase” : false,

// Whether the C-ECHO SCU is automatically followed by a C-FIND SCU,
// while testing the connectivity from Orthanc to a remote DICOM
// modality. This allows one to check that the remote modality does
// accept C-FIND requests from Orthanc (new in Orthanc 1.8.1).
“DicomEchoChecksFind” : false,

// The timeout (in seconds) after which the DICOM associations are
// considered as closed by the Orthanc SCU (client) if the remote
// DICOM SCP (server) does not answer.
“DicomScuTimeout” : 10,

// During a C-STORE SCU request initiated by Orthanc, if the remote
// modality doesn’t support the original transfer syntax of some
// DICOM instance, specify which transfer syntax should be preferred
// to transcode this instance (provided the remote modality accepts
// this syntax). In Orthanc between 1.7.0 and 1.8.2, this parameter
// was implicitly set to “Little Endian Implicit”
// (1.2.840.10008.1.2). In Orthanc <= 1.6.1 and in Orthanc >= 1.9.0,
// this parameter is by default set to “Little Endian Explicit”
// (1.2.840.10008.1.2.1). This parameter can possibly correspond to
// a compressed transfer syntax. (new in Orthanc 1.9.0)
“DicomScuPreferredTransferSyntax” : “1.2.840.10008.1.2.1”,

// The list of the known Orthanc peers. This option is ignored if
// “OrthancPeersInDatabase” is set to “true”, in which case you must
// use the REST API to define Orthanc peers.
“OrthancPeers” : {
/**
* Each line gives the base URL of an Orthanc peer, possibly
* followed by the username/password pair (if the password
* protection is enabled on the peer).
**/
// “peer” : [ “http://127.0.0.1:8043/”, “alice”, “alicePassword” ]
// “peer2” : [ “http://127.0.0.1:8044/” ]

},

“OrthancPeersInDatabase” : false,

“HttpProxy” : “”,

“HttpVerbose” : false,

“HttpTimeout” : 60,

“HttpsVerifyPeers” : true,

“HttpsCACertificates” : “/etc/ssl/certs/ca-certificates.crt”,

/**

  • Advanced options
    **/

“UserMetadata” : {
// “Sample” : 1024
},

// Dictionary of symbolic names for the user-defined types of
// attached files. Each entry must map an unique string to an unique
// number between 1024 and 65535. Optionally, a second argument can
// provided to specify a MIME content type for the attachment.
“UserContentType” : {
// “sample” : 1024
// “sample2” : [ 1025, “application/pdf” ]
},

// Number of seconds without receiving any instance before a
// patient, a study or a series is considered as stable.
“StableAge” : 60,

// By default, Orthanc compares AET (Application Entity Titles) in a
// case-insensitive way. Setting this option to “true” will enable
// case-sensitive matching.
“StrictAetComparison” : false,

// When the following option is “true”, the MD5 of the DICOM files
// will be computed and stored in the Orthanc database. This
// information can be used to detect disk corruption, at the price
// of a small performance overhead.
“StoreMD5ForAttachments” : true,

// The maximum number of results for a single C-FIND request at the
// Patient, Study or Series level. Setting this option to “0” means
// no limit.
“LimitFindResults” : 0,

// The maximum number of results for a single C-FIND request at the
// Instance level. Setting this option to “0” means no limit.
“LimitFindInstances” : 0,

// The maximum number of active jobs in the Orthanc scheduler. When
// this limit is reached, the addition of new jobs is blocked until
// some job finishes.
“LimitJobs” : 10,

// If this option is set to “true” (default behavior until Orthanc
// 1.3.2), Orthanc will log the resources that are exported to other
// DICOM modalities or Orthanc peers, inside the URI
// “/exports”. Setting this option to “false” is useful to prevent
// the index to grow indefinitely in auto-routing tasks (this is the
// default behavior since Orthanc 1.4.0).
“LogExportedResources” : false,

// Enable or disable HTTP Keep-Alive (persistent HTTP
// connections). Setting this option to “true” prevents Orthanc
// issue #32 (“HttpServer does not support multiple HTTP requests in
// the same TCP stream”), but can possibly slow down HTTP clients
// that do not support persistent connections. The default behavior
// used to be “false” in Orthanc <= 1.5.1. Setting this option to
// “false” is also recommended if Orthanc is compiled against
// Mongoose.
“KeepAlive” : true,

// Enable or disable Nagle’s algorithm. Only taken into
// consideration if Orthanc is compiled to use CivetWeb. Experiments
// show that best performance can be obtained by setting both
// “KeepAlive” and “TcpNoDelay” to “true”. Beware however of
// caveats: The Caveats of TCP_NODELAY
“TcpNoDelay” : true,

// Number of threads that are used by the embedded HTTP server.
“HttpThreadsCount” : 50,

// If this option is set to “false”, Orthanc will run in index-only
// mode. The DICOM files will not be stored on the drive: Orthanc
// only indexes the small subset of the so-called “main DICOM tags”
// in its SQL database. Note that this option might prevent the
// upgrade to newer versions of Orthanc. Also note that this
// behavior might not be available with the storage area plugins.
“StoreDicom” : true,

// DICOM associations initiated by Lua scripts are kept open as long
// as new DICOM commands are issued. This option sets the number of
// seconds of inactivity to wait before automatically closing a
// DICOM association used by Lua. If set to 0, the connection is
// closed immediately. This option is only used in Lua scripts.
“DicomAssociationCloseDelay” : 5,

// Maximum number of query/retrieve DICOM requests that are
// maintained by Orthanc. The least recently used requests get
// deleted as new requests are issued.
“QueryRetrieveSize” : 100,

// When handling a C-FIND SCP request, setting this flag to “true”
// will enable case-sensitive match for PN value representation
// (such as PatientName). By default, the search is
// case-insensitive, which does not follow the DICOM standard.
“CaseSensitivePN” : false,

// Configure PKCS#11 to use hardware security modules (HSM) and
// smart cards when carrying on HTTPS client authentication.
/**
“Pkcs11” : {
“Module” : “/usr/local/lib/libbeidpkcs11.so”,
“Module” : “C:/Windows/System32/beidpkcs11.dll”,
“Pin” : “1234”,
“Verbose” : true
}
**/

// If set to “false”, Orthanc will not load its default dictionary
// of private tags. This might be necessary if you cannot import a
// DICOM file encoded using the Implicit VR Endian transfer syntax,
// and containing private tags: Such an import error might stem from
// a bad dictionary. You can still list your private tags of
// interest in the “Dictionary” configuration option below.
“LoadPrivateDictionary” : true,

// Locale to be used by Orthanc. Currently, only used if comparing
// strings in a case-insensitive way. It should be safe to keep this
// value undefined, which lets Orthanc autodetect the suitable locale.
// “Locale” : “en_US.UTF-8”,

// Register a new tag in the dictionary of DICOM tags that are known
// to Orthanc. Each line must contain the tag (formatted as 2
// hexadecimal numbers), the value representation (2 upcase
// characters), a nickname for the tag, possibly the minimum
// multiplicity (> 0 with defaults to 1), possibly the maximum
// multiplicity (0 means arbitrary multiplicity, defaults to 1), and
// possibly the Private Creator (for private tags).
“Dictionary” : {
// “0014,1020” : [ “DA”, “ValidationExpiryDate”, 1, 1 ]
// “00e1,10c2” : [ “UI”, “PET-CT Multi Modality Name”, 1, 1, “ELSCINT1” ]
// “7053,1003” : [ “ST”, “Original Image Filename”, 1, 1, “Philips PET Private Group” ]
// “2001,5f” : [ “SQ”, “StackSequence”, 1, 1, “Philips Imaging DD 001” ]
},

// Load a set of external DICOM dictionaries in order to replace the
// default dictionaries. This option must contain a set of files in
// the DCMTK format. The order of the dictionaries is
// important. This option can be used to turn Orthanc into a DICONDE
// server. (new in Orthanc 1.9.4)
/**
“ExternalDictionaries” : [
“/usr/share/libdcmtk12/dicom.dic”,
“/usr/share/libdcmtk12/diconde.dic”
]
**/

// Whether to run DICOM C-MOVE operations synchronously. If set to
// “false” (asynchronous mode), each incoming C-MOVE request results
// in the creation of a new background job. Up to Orthanc 1.3.2, the
// implicit behavior was to use synchronous C-MOVE (“true”). Between
// Orthanc 1.4.0 and 1.4.2, the default behavior was set to
// asynchronous C-MOVE (“false”). Since Orthanc 1.5.0, the default
// behavior is back to synchronous C-MOVE (“true”, which ensures
// backward compatibility with Orthanc <= 1.3.2).
“SynchronousCMove” : true,

// Maximum number of completed jobs that are kept in memory. A
// processing job is considered as complete once it is tagged as
// “Success” or “Failure”. Since Orthanc 1.5.0, a value of “0”
// indicates to keep no job in memory (i.e. jobs are removed from
// the history as soon as they are completed), which prevents the
// use of some features of Orthanc (typically, synchronous mode in
// REST API) and should be avoided for non-developers.
“JobsHistorySize” : 10,

// Whether to save the jobs into the Orthanc database. If this
// option is set to “true”, the pending/running/completed jobs are
// automatically reloaded from the database if Orthanc is stopped
// then restarted (except if the “–no-jobs” command-line argument
// is specified). This option should be set to “false” if multiple
// Orthanc servers are using the same database (e.g. if PostgreSQL
// or MariaDB/MySQL is used).
“SaveJobs” : true,

// Specifies how Orthanc reacts when it receives a DICOM instance
// whose SOPInstanceUID is already stored. If set to “true”, the new
// instance replaces the old one. If set to “false”, the new
// instance is discarded and the old one is kept. Up to Orthanc
// 1.4.1, the implicit behavior corresponded to “false”.
“OverwriteInstances” : false,

// Maximum number of ZIP/media archives that are maintained by
// Orthanc, as a response to the asynchronous creation of archives.
// The least recently used archives get deleted as new archives are
// generated. This option was introduced in Orthanc 1.5.0, and has
// no effect on the synchronous generation of archives.
“MediaArchiveSize” : 1,

// Performance setting to specify how Orthanc accesses the storage
// area during find operations (C-FIND, /tools/find API route and
// QIDO-RS in dicom-web). Three modes are available: (1) “Always”
// allows Orthanc to read the storage area as soon as it needs an
// information that is not present in its database (slowest mode),
// (2) “Never” prevents Orthanc from accessing the storage area, and
// makes it uses exclusively its database (fastest mode), and (3)
// “Answers” allows Orthanc to read the storage area to generate its
// answers, but not to filter the DICOM resources (balance between
// the two modes). By default, the mode is “Always”, which
// corresponds to the behavior of Orthanc <= 1.5.0.
“StorageAccessOnFind” : “Always”,

// Whether Orthanc monitors its metrics (new in Orthanc 1.5.4). If
// set to “true”, the metrics can be retrieved at
// “/tools/metrics-prometheus” formetted using the Prometheus
// text-based exposition format.
“MetricsEnabled” : true,

// Whether calls to URI “/tools/execute-script” is enabled. Starting
// with Orthanc 1.5.8, this URI is disabled by default for security.
“ExecuteLuaEnabled” : false,

// Set the timeout while serving HTTP requests by the embedded Web
// server, in seconds. This corresponds to option
// “request_timeout_ms” of Mongoose/Civetweb. It will set the socket
// options “SO_RCVTIMEO” and “SO_SNDTIMEO” to the specified value.
“HttpRequestTimeout” : 30,

// Set the default private creator that is used by Orthanc when it
// looks for a private tag in its dictionary (cf. “Dictionary”
// option), or when it creates/modifies a DICOM file (new in Orthanc 1.6.0).
“DefaultPrivateCreator” : “”,

// Maximum number of storage commitment reports (i.e. received from
// remote modalities) to be kept in memory (new in Orthanc 1.6.0).
“StorageCommitmentReportsSize” : 100,

// Whether Orthanc transcodes DICOM files to an uncompressed
// transfer syntax over the DICOM protocol, if the remote modality
// does not support compressed transfer syntaxes (new in Orthanc 1.7.0).
“TranscodeDicomProtocol” : true,

// If some plugin to decode/transcode DICOM instances is installed,
// this option specifies whether the built-in decoder/transcoder of
// Orthanc (that uses DCMTK) is applied before or after the plugins,
// or is not applied at all (new in Orthanc 1.7.0). The allowed
// values for this option are “After” (default value, corresponding
// to the behavior of Orthanc <= 1.6.1), “Before”, or “Disabled”.
“BuiltinDecoderTranscoderOrder” : “After”,

// If this option is set, Orthanc will transparently transcode any
// incoming DICOM instance to the given transfer syntax before
// storing it into its database. Beware that this might result in
// high CPU usage (if transcoding to some compressed transfer
// syntax), or in higher disk consumption (if transcoding to an
// uncompressed syntax). 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.
/**
“IngestTranscoding” : “1.2.840.10008.1.2”,
**/

// Whether ingest transcoding is applied to incoming DICOM instances
// that have an uncompressed transfer syntax, i.e. Little Endian
// Implicit, Little Endian Explicit or Big Endian Explicit (new in
// Orthanc 1.8.2).
“IngestTranscodingOfUncompressed” : true,

// Whether ingest transcoding is applied to incoming DICOM instances
// that have a compressed transfer syntax (new in Orthanc 1.8.2).
“IngestTranscodingOfCompressed” : true,

// The compression level that is used when transcoding to one of the
// lossy/JPEG transfer syntaxes (integer between 1 and 100).
“DicomLossyTranscodingQuality” : 90,

“SyncStorageArea” : true,

“MallocArenaMax” : 5,

“DeidentifyLogs” : true,

“DeidentifyLogsDicomVersion” : “2021b”,

“MaximumPduLength” : 16384,

/**
“DatabaseServerIdentifier” : “Orthanc1”,
**/

“CheckRevisions” : false,

“SynchronousZipStream” : true

}

Avijit,

Are you sure you’re running the osimis/orthanc:23.3.5-full image as instructed by Alain? My sample command line mentioning 22.2.2 was only meant to fix the .json mapping error (which is now fixed, as you can see)

(If you ARE using 23.3.5-full, then maybe this .so plugin is at another location. You can for example open a terminal in the container and use find to look for it… I am not familiar with the layout in this image but I am pretty sure Alain will chime in with more info)

Hi Benjamin,

Thanks for your help.

As you said there will be different locations of plugins in osimis/orthanc:23.3.5-full image so I have tried 22.2.2 and the Orthanc started. Even though there are just two plugins, I can still see an Azure blob storage plugin.

however, I don’t believe it is connected to Azure Blob Storage. kindly view screenshot of log below:-

Hi Alain,

I have already read the materials you shared, but I am still unable to resolve the problem. Benjamin was a huge assistance, however I want to use the most recent version of Osimis/Orthanc. If you can help me address the problem, It will be really beneficial to me. Please see the following screenshot.:-

The last error report I replied to was this:

OK I am editing my message :

  • in Orthanc 22.2.2, the plugin is loaded (and works correctly?)
  • in Orthanc 23.3.5, the plugin does NOT load, am I correct?

You’re saying that it’s not related to Azure Blob storage but, at the same time, the error clearly indicates that the libOrthancAzureBlobStorage.so cannot be loaded. I am confused :smile:

The last error you posted indicates that the path to the plugin is NOT correct in your configuration file. You need to locate the .so file in the container and edit your configuration so that it points to this location. You can for instance open a terminal in your running container (maybe disable the configuration so that the container is able to start), and use find /usr -iname '*azureblob*.so' or sth along those lines.

Hi Benjamin,

Sorry for the confusion but I am not talking about an error that I shared earlier because it was related to osimis/orthanc:23.3.5-full and you said you are not familiar with it. If you see my reply to Alain I already asked him about it.

I am just saying that when I ran “docker run -p 5252:5252 -p 8052:8052 -v /var/tmp/orthancosimis.json:/etc/orthanc/orthanc.json:ro osimis/orthanc:22.2.2,” Orthanc launched without any issues. kindly view log below:-

I think Azure blob storage is not connected. I already uploaded one study to the Azure blob storage, but I cannot see it in All studies option. So I am asking if I am missing anything in the Azure blob configuration.

Hi Avijit,

The Azure blob storage is only available in the -full images starting from version 22.6.1-full (release notes).
So you should replace osimis/orthanc:22.2.2 by osimis/orthanc:23.4.0-full

Best regards,

Alain

Hi Alain,

Thank you for the response.

I just executed

“docker run -p 5252:5252 -p 8052:8052 -v $(pwd)/orthancosimis.json:/etc/orthanc/orthancosimis.json:ro osimis/orthanc:23.4.0-full”

and orthanc started without any error. Could you kindly respond to my few questions:-

  1. Only three plugins are available. How will I obtain other plugins?

  1. What volumes are being used, because Docker Local Volume is not being used?

  1. I have submitted a few studies using Orthanc’s uploads feature, and the studies have been saved in the /var/lib/orthanc folder of the docker container as well as Azure blob storage. Only blob storage is where I want to save it. Please advise what information I should put in the configuration file. I already used below configuration

“AzureBlobStorage” : {
“ConnectionString”: “DefaultEndpointsProtocol=https;AccountName=xxxxxxxxx;AccountKey=yyyyyyyy===;EndpointSuffix=core.windows.net”,
“ContainerName” : “test-orthanc-storage-plugin”,
“CreateContainerIfNotExists”: true, // available from version 1.2.0
“RootPath”: “”, // see below
“MigrationFromFileSystemEnabled”: false, // see below
“StorageStructure”: “flat”, // see below
“EnableLegacyUnknownFiles”: true, // optional: see below
“StorageEncryption” : {} // optional: see the section related to encryption
“HybridMode”: “Disabled” // optional: see the section related to Hybrid storage
}

I also used "HybridMode": "WriteToObjectStorage"

Regards,
Avijit

Hi Avijit,

Please read How Orthanc stores its data. It shows that there is a SQL DB and a file storage. The Azure storage stores only the dicom files in the blob storage.

What you see in /var/lib/orthanc/db is probably the default SQLite DB since you do not seem to have configured a PostgreSQL DB.

If you want to persist your SQLite DB, you should indeed map a volume on /var/lib/orthanc/db when starting your container.

Please again check the Docker setup samples for info on how to use Orthanc with Docker with dozens of scenarios.

HTH,

Alain

Hi Alain,

That means i will need both db and file storage. Only azure blob storage will not work.

thanks,
Avijit

I have also read from Migration & Hybrid mode Storage structure

What does it mean…??

Thanks,
Avijit