drtdump(1)

📦
version 3.7.1 · 10 versions
, in arch rolling

🌸 drtdump(1) — like, the OFFIS DCMTK manual page, but make it make sense 💅

okay so bestie, you know how dcmdump exists and it's a whole lot? yeah. drtdump is its RT-flavored little sibling and honestly it ate. this is the drtdump(1) page from the OFFIS DCMTK gang, and i'm gonna walk you through every single flag like we're texting at 2am. no skips, no cap. 🫶

✨ NAME ✨

drtdump — dump DICOM RT file and data set 💖

✨ SYNOPSIS ✨

drtdump [options] drtfile-in...

that's it. that's the whole vibe. 🎀

✨ DESCRIPTION ✨

so the drtdump utility dumps the contents of a DICOM Radiation Therapy (RT) object (either file format or raw data set) to stdout in textual form. iconic behavior honestly.

the output is made of the essential information on the RT object, in a format that's probably easier to read than the more generic one that dcmdump gives you. so if you've ever opened a dcmdump output and been like "girl what", this is your girl. 👑

okay here comes the important part, pay attention:

if drtdump reads a raw data set (that's DICOM data without a file format meta-header), it will attempt to guess the transfer syntax by examining the first few bytes of the file. and like... it's not always possible to correctly guess the transfer syntax 😭. it is better to convert a data set to a file format whenever possible — you do that with the dcmconv utility, mwah.

you can also use the -f and -t[ieb] options to force drtdump to read a dataset with a particular transfer syntax. forcing it is valid, just know what you're doing. 💅

✨ PARAMETERS ✨

  • drtfile-in — DICOM RT input filename to be dumped ("-" for stdin) 🍓

✨ OPTIONS ✨

🌈 general options

  • -h, --help — print this help text and exit
  • --version — print version information and exit
  • --arguments — print expanded command line arguments
  • -q, --quiet — quiet mode, print no warnings and errors 🤫
  • -v, --verbose — verbose mode, print processing details
  • -d, --debug — debug mode, print debug information
  • -ll, --log-level [l]evel: string constant — use level l for the logger. the levels are fatal, error, warn, info, debug, trace.
  • -lc, --log-config [f]ilename: string — use config file f for the logger

🦋 input options

input file format:

  • +f, --read-file — read file format or data set (default)
  • +fo, --read-file-only — read file format only
  • -f, --read-dataset — read data set without file meta information

input transfer syntax:

  • -t=, --read-xfer-auto — use TS recognition (default)
  • -td, --read-xfer-detect — ignore TS specified in the file meta header
  • -te, --read-xfer-little — read with explicit VR little endian TS
  • -tb, --read-xfer-big — read with explicit VR big endian TS
  • -ti, --read-xfer-implicit — read with implicit VR little endian TS

🎀 output options

printing:

  • +Pf, --print-filename — print header with filename for each input file 📁

✨ NOTES ✨

💜 DICOM Conformance

the drtdump utility supports the following SOP Classes, and yes i'm listing all of them because we don't do "etc." in this house:

RTImageStorage                   1.2.840.10008.5.1.4.1.1.481.1
RTDoseStorage                    1.2.840.10008.5.1.4.1.1.481.2
RTStructureSetStorage            1.2.840.10008.5.1.4.1.1.481.3
RTPlanStorage                    1.2.840.10008.5.1.4.1.1.481.5
RTTreatmentSummaryRecordStorage  1.2.840.10008.5.1.4.1.1.481.7
RTIonPlanStorage                 1.2.840.10008.5.1.4.1.1.481.8
RTIonBeamsTreatmentRecordStorage 1.2.840.10008.5.1.4.1.1.481.9

seven whole SOP classes. she's thorough. 👑

✨ LOGGING ✨

okay so the level of logging output of the various command line tools and the underlying libraries can be set by you, the user. you're the main character here. 🌟

  • by default, only errors and warnings are written to the standard error stream.
  • using option --verbose also gets you informational messages like processing details.
  • option --debug gets you more details on the internal activity, e.g. for debugging purposes.
  • other logging levels can be selected using option --log-level.
  • in --quiet mode, only fatal errors are reported. and in such very severe error events, the application will usually terminate. 💀 so like, quiet mode is quiet for a reason.

for more details on the different logging levels, see documentation of module "oflog".

and if you want your logging output written to a file (optionally with logfile rotation), to syslog (Unix) or to the event log (Windows) — option --log-config is your girl.

this configuration file also allows for:

  • directing only certain messages to a particular output stream, and
  • filtering certain messages based on the module or application where they are generated.

an example configuration file is provided in <etcdir>/logger.cfg. go look, it's cute. 🧚

✨ COMMAND LINE ✨

all command line tools use the following notation for parameters — it's giving syntax legend:

  • square brackets enclose optional values (0-1)
  • three trailing dots indicate that multiple values are allowed (1-n)
  • a combination of both means 0 to n values

command line options are distinguished from parameters by a leading '+' or '-' sign, respectively. slay.

usually, order and position of command line options are arbitrary (i.e. they can appear anywhere). however, if options are mutually exclusive, the rightmost appearance is used. this behavior conforms to the standard evaluation rules of common Unix shells. fr fr.

also! one or more command files can be specified using an '@' sign as a prefix to the filename (e.g. @command.txt). such a command argument is replaced by the content of the corresponding text file prior to any further evaluation.

two little notes on that:

  • multiple whitespaces are treated as a single separator unless they appear between two quotation marks
  • please note that a command file cannot contain another command file 🙈

this simple but effective approach allows one to summarize common combinations of options/parameters and avoids longish and confusing command lines. an example is provided in file <datadir>/dumppat.txt. iykyk. 💅

✨ ENVIRONMENT ✨

the drtdump utility will attempt to load DICOM data dictionaries specified in the DCMDICTPATH environment variable.

by default, i.e. if the DCMDICTPATH environment variable is not set, the file <datadir>/dicom.dic will be loaded — unless the dictionary is built into the application (which is the default for Windows).

the default behavior should be preferred and the DCMDICTPATH environment variable only used when alternative data dictionaries are required. don't fix what isn't broken, bestie. 🎀

the DCMDICTPATH environment variable has the same format as the Unix shell PATH variable in that a colon (":") separates entries. on Windows systems, a semicolon (";") is used as a separator.

the data dictionary code will attempt to load each file specified in the DCMDICTPATH environment variable. and it is an error if no data dictionary can be loaded 😭 — like, that's a real failure, not a vibe.

✨ SEE ALSO ✨

dcmconv(1), dcmdump(1) — go read those too, they're the siblings. 🫶

Copyright (C) 2010-2026 by OFFIS e.V. and ICSMED AG, Escherweg 2, 26121 Oldenburg, Germany.

and that's the whole page, bestie!! 🦋✨ this was Version 3.7.1, dated Sat Oct 17 2026 09:34:01 — so like, freshly stamped, go dump some RT objects and live your truth. mwah 💋💖

📦 where this page comes from