Registering Custom Codec with DicomObjects.NET
- Create new CodecFactory class
- Implement DicomObjects.DicomCodecs.IDecompressor
- Implement DicomObjects.DicomCodecs.ICompressor interface
- Registering your CodecFactory with DicomObjects.NET
Many of the less commonly used features of DicomObjects are controlled by “registry” values, which can be specified in one of 2 ways: Using the “real” registry (only for the COM version, not .NET), a sample “.Reg” file can be downloaded here. Using DicomGlobal functions Set up registry keys in the COM version of DicomObjects Using the “real” registry (COM Only) There are 2 variations on this, depending on the architecture of your machine
There are two kinds of Rejection during association establishment, Association Rejection and Contexts Rejection.
Relational Queries have been in the DICOM standard since the start, but are supported by only about half the PACS in the world. They are negotiated using Extended Negotiation and if requested by the SCU and accepted by the SCP then they remove several of the normal C-FIND rules, namely: It is no longer necessary to quote the unique identifiers for every level above the current query level It is possible to use matching attributes at different levels of the hierarchy e.
Private Elements (or Tags) are perfectly legal in DICOM, details of the structure of Private DICOM Elements can be found in DICOM Private Elements.
Removing all Private elements from any DICOM instance is quite simple, following sample code shows you how to do it in DicomObjects.
Out of the many label types available in DicomObjects.NET, LabelType.Image can be used to directly reference a System.Drawing.Image object (jpg, png, bmp, etc) and to be rendered as a DicomLabel on the viewer.
This article explains what DicomObjects (both COM and .NET versions) supports in terms of DICOM Structured reporting. Of course, DicomObjects as always provides full access to the data within any DICOM instance that has been loaded and it can handle the reading, writing and network transmission of Structured reports just the same as it can for images or any other sort of DICOM instance.
There are strict rules for UID formatting and usage. If these are not followed, then some modality equipment may refuse to accept MWL results containing invalid UIDs. Some of the systems are known to filter out requests for faulty UIDs.
We are sometimes asked how to retrieve as study based on the accession number. This is only possible by doing an initial query to find the StudyUID then using those in a retrieval. The explanation is that the DICOM rules allow only the Instance UID, Series UID, Study UID and Patient ID to be used in C-MOVE and C-GET requests. If you wish to retrieve a study based on accession number (or anything else except those 4 identifiers).
In the vast majority of Associations, the Association is initiated by the SCU with the SCP responding, but DICOM does allow Reverse Role Negotiation whereby the initiator can request to be regarded as the SCP. In practise, this is only used as part of the Storage Commitment service. An oddity of reverse role negotiation (like Extended Negotiation) is that it is agreed per SOP Class not Per Presentation Context, so an agreement to reverse the roles applies to all presentation contexts using that SOP Class.
The ROOT is the overall data model, and there are two main roots in DICOM, STUDY and PATIENT. A third root model also exists called PATIENTSTUDY but it was very rarely used in DICOM and is now officially retired. Within each root structure, operations (find or GET or MOVE) are done at a particular LEVEL. The allowed combinations are: PATIENT Root Allows operations at these levels: PATIENT STUDY SERIES IMAGE STUDY Root Allows these levels:
SOP class is one of those horrible obscure expressions used in DICOM which put people off the standard immediately! It is supposed to stand for “Service Object Pair”, and has its roots in the slightly odd object orientated origins of DICOM, but in practice, each object only has one directly associated service (Storage) and each other service only has one type of object, so a better name would be Service OR Object
Secondary Capture Images Composite Instances which are the “lowest common denominator” images available in DICOM. Whilst there is sufficient information to identify the patient, date and institution, they do not contain any scaling, or other modality information, so are effective “just pictures”. They are commonly used for: Screen captures Scanned request forms etc. Whilst the original secondary capture object definition was minimally defined and originally allowed a huge variety of DICOM bit-depths etc.
Users on some version of Windows will find that they might be blocked from opening/using the CHM help file. To avoid the main problem, always save the file to disk and open from there rather than directly from the web page. Even after that though, once the file is saved to disc, double-clicking it may result in an Open File - Security Warning dialogue asking the user, Do you want to open this file?