Some of the functions in our library have the correct annotation already, whereas some (more legacy) functions don't feature annotations yet. At the same time, there is a (pretty useful) trend to outsource annotations into a separate .pyi file (think C++ headers, but actually just annotations not declarations). It makes sense to follow this trend

It seems like a slight pain to do this, but it might be useful to have a GitHub action generate HTML GoDoc on PRs / code pushes, so that reviewers can easily preview what the GoDoc will look like.

It looks like the easiest way to do this is with wget sadly (if you want all the nice styles and such applied in the html).

The current Transfer Options page leaves a bit to be desired. I propose that these aspects are improved:

• There isn't a way to enable a transfer syntax regardless of the SOP class (or at least for those already admitting at least one transfer syntax). This means that allowing a transfer syntax requires looking up every applicable SOP class.
• The "Select All" and "Deselect All" will check and

Many important DICOM attributes rely on a textual value representation even if their intent is to encode numbers (in emphasis, DS and IS). On the other hand, it might be easier for some users to collect numbers in binary form and create a DICOM value directly from them.

The idea is the following: provide the method into_text_value(self) that consumes the value (PrimitiveValue and `Value

At the moment, standard codes used require manual typing of the code tuple, such as here. This is error-prone and long. Instead, we should use the #defined constants, as done in dcmsr: https://github.com/commontk/DCMTK/blob/patched-DCMTK-3.6.3_20180205/dcmsr/include/dcmtk/dcmsr/codes/dcm.h#L51.

It would be also i