turned on Housekeeper with default settings (except for schedule which is configured to run after hours) and noticed storage consumption started increasing dramatically. could this be caused by ingest transcoding being set as 1.2.840.10008.1.2.4.70
What was the TransferSyntax of studies before running the Housekeeper ?
Having IngestTranscoding set to 1.2.840.10008.1.2.4.70 (JPEG Lossless) means that the Housekeeper will compress the data which should usually decrease the storage consumption unless the files were previously compressed using a more efficient TransferSyntax.
If you had lossy compression before (e.g.TS = 1.2.840.10008.1.2.4.50), then switching to JPEG Lossless will indeed dramatically increase the disk usage.
I have never tested that. You should prototype it on a test server first.
By default, when compressing to a lossy transfer syntax, Orthanc generates new DICOM identifiers since you are destroying information.
unfortunately i can’t test it because orthanc crashes when the housekeeper tries to convert .70 to .50
if an incoming study is already .50 and Orthanc is configured to transcode to .50 with a quality of 80%, what will Orthanc do to the incoming .50 study?
in an effort to reduce S3 costs, we moved the .70 files to Glacier Instant Retrieval. Now that we can transcode them back to .50, I just wanted to understand the transcoding process a little better, i.e. will each .dcm file be “touched” once or multiple times by the Orthanc housekeeper to transcode from .70 back to .50? I ask because AWS will charge depending on the number of times a file in Glacier Instant Retrieval is retrieved.
Yes, it will be touched once everytime you run the housekeeper and, some plugins like the DicomWEB plugin will touch them on the StableStudy event one minute later. However, the second touch will not happen if your MaximumStorageCacheSize is large enough (an option to reduce the cache size requirement is to modify the StableAge to reduce it to a few seconds but you’ll still need a cache).