Imebra¶
Download Imebra
Legal
Introduction
User documentation
API¶
- Objects lifecycle and Object ownership
- DICOM dataSet & tags classes
- UID generation classes
- Stream classes
- Imaging classes
- Transforms classes
- Memory management classes
- ACSE classes
- DIMSE classes
- Introduction
- Commands and responses transmission and reception
- Commands and response classes
- C-Commands and responses
- N-Commands and responses
- DICOMDIR classes
- DICOM dictionary
- Definitions
- Exceptions
- Introduction
- Exceptions manager
- Missing data exceptions
- Stream error exceptions
- TCP exceptions
- Dictionary exceptions
- Charset conversion exceptions
- Codec exceptions
- Data handler exceptions
- DataSet exceptions
- DICOMDIR exceptions
- Image exceptions
- Transform exceptions
- Memory exceptions
- LUT exceptions
- ACSE exceptions
- AcseError
- AcseCorruptedMessageError
- AcseNoTransferSyntaxError
- AcsePresentationContextNotRequestedError
- AcseWrongRoleError
- AcseWrongIdError
- AcseWrongResponseIdError
- AcseWrongCommandIdError
- AcseRejectedAssociationError
- AcseSCUNoReasonGivenError
- AcseSCUApplicationContextNameNotSupportedError
- AcseSCUCallingAETNotRecognizedError
- AcseSCUCalledAETNotRecognizedError
- AcseSCPNoReasonGivenError
- AcseSCPAcseProtocolVersionNotSupportedError
- AcseSCPPresentationReservedError
- AcseSCPPresentationTemporaryCongestionError
- AcseSCPPresentationLocalLimitExcededError
- AcseTooManyOperationsPerformedError
- AcseTooManyOperationsInvokedError
- AcseNoPayloadError
- DIMSE exceptions
Build distributions¶
Requirements & Risks
- Requirements
- Functional requirements
- [REQ_READ_DICOM_FILES] The library must be able to read DICOM files from a data source and replicate their structure in memory
- [REQ_WRITE_DICOM_FILES] The library must be able to write DICOM files from a DICOM structure in memory
- [REQ_DIMSE] The library must be able to send and receive DIMSE messages
- [REQ_ACSE] The library must be able to send and receive ACSE messages through a generic transport mechanism
- [REQ_GENERIC_STREAM_PROTOCOL] There must be a generic streaming protocol able to transport DIMSE messages
- [REQ_TCPIP_PROTOCOL] Imebra must supply a basic TCP streaming class
- [REQ_USER_PROTOCOL] Imebra must supply a base class for IO streaming
- [REQ_FUNCTIONAL_MACROS] The operations that get image specific parameters should be aware of Functional Macros
- [REQ_ENDIANESS_PLATFORM] Exposed memory with raw numerical data must use the platform endianess to represent numbers
- [REQ_READ_TAGS] The library must be able to extract the information contained in the DICOM tags
- [REQ_WRITE_TAGS] The library must be able to write tags into the DICOM structure
- [REQ_DECOMPRESS_IMAGES] Imebra must be able to decompress images contained in the DICOM dataset
- [REQ_COMPRESS_IMAGES] Imebra must be able to compress images and insert them in the DICOM dataset
- [REQ_PARSE_DICOMDIR] The library must be able to parse DICOMDIR structures and the records they contain
- [REQ_BUILD_DICOMDIR] The library must be able to build DICOMDIR structures and the records they contain
- [REQ_VOI_FUNCTION] Allow the calculation of the VOI transform using different defined DICOM functions
- [REQ_EXCEPTIONS] All the error should be reported via C++ exceptions
- [REQ_RAW_MEMORY] The library must be able to expose the raw memory of numeric DICOM tags
- [REQ_EXTRACT_LUT] The library must be able to extract LUT information from the DataSet
- [REQ_DELAYED_LOAD] The library must be able to delay the loading of large chunk of data from the DICOM file
- [REQ_UID_GEN] Supply a mechanism to generate unique DICOM UIDs
- [REQ_VR_CONVERSION] The library must be able to convert data between different VRs
- [REQ_LOGGING] The library must log the most important tasks execution
- [REQ_APPLY_MODALITY_VOILUT] The library must be able to apply the modality VOI or LUT to extracted images
- [REQ_PREPARE_RGB_IMAGE] Imebra must be able to create an image ready to be displayed on the computer screen
- [REQ_APPLY_VOILUT] The library must be able to apply the presentation VOI/LUT to the extracted images
- [REQ_RETURN_DEFAULT_VALUE] There has to be a special function able to return a default value for missing tags
- [REQ_APP_DECIDES_DEFAULT_VALUE] Default values must be explicitly set by the application for each tag
- [REQ_THROW_ON_MISSING_DATA] The library must throw an exception when the client tries to access data that doesn’t exist
- [REQ_DONT_RETURN_POINTER] The API should not return pointers to allocated objects
- [REQ_INSERT_FILES_IN_TAGS] Allow to insert reference to files into DICOM tags
- [REQ_IMMUTABLE_CLASSES] Data classes should be immutable, with mutable subclasses
- [REQ_OVERLAYS] The API must supply methods to retrieve and set overlay bitmaps
- Implementation requirements
- [REQ_NO_CALLBACK] User extensions should not be achievable by extending Imebra classes or by supplying callbacks
- [REQ_NO_MULTIPLE_INHERITANCE] Multiple inheritance is not allowed
- [REQ_CPP] The library must be implemented in C++ 0x
- [REQ_BINARY_COMPATIBILITY] The library should offer binary compatibility between minor revisions
- [REQ_MEMORY_ALLOCATION] Memory should be allocated via cpp std arrays, vectors, strings, etc, not through new
- [REQ_OBJECT_ALLOCATION] Objects should be allocated via shared pointers, unique pointers or on the stack
- [REQ_THROW_WRONG_CONVERSION] Throw exception on non allowed VR conversions
- [REQ_MAKE_SHARED] Object inserted in shared pointers must be allocated via make_shared
- [REQ_INTEGER_TYPES] The integer types in the public interface must be consistent
- [REQ_VARIABLE_MAX_IMAGE_SIZE] The settings of the maximum image size must be settable at runtime
- [REQ_TAGID_SEPARATE_CLASS] The tag id must be specified using a specific class
- [REQ_DONT_EXPOSE_INDEXED_WRITING] Don’t expose methods that allow indexed writing into the buffer while resetting it
- Performances
- [REQ_WRAP_FUNCTIONS_EXCEPTIONS_INFO] All the functions must be wrapped by macros that report the exception info
- [REQ_MEMORY_POOL] The library should reuse unused memory instead of allocating new blocks.
- [REQ_WRITING_HANDLER_EMPTY] New writing handler that write data to a buffer should be initially empty
- [REQ_MEMORY_POOL_THREAD] There should be a memory pool per thread
- [REQ_MEMORY_POOL_NEW_HANDLER] Provide a std::new_handler that clears the memory pool when necessary
- Security
- Functional requirements
- Risks
- [RISK_BUFFER_OVERFLOW] The library and its client may read or write memory outside the allocated buffer
- [RISK_RECEIVE_DEFAULT_VALUE] When receiving default values for non-existent data the client may understand that the tag is actually present
- [RISK_VR_CONVERSION] Implicit VR conversion may hide wrong tag’s VR
- [RISK_MEMORY_ALLOC] The library may use deallocated memory or forget to deallocate memory
- [RISK_OBJECT_ALLOC] The library and its client may use deallocated objects or forget to deallocate objects
- [RISK_BUFFER_RESET] When a client wants to write several values in the buffer it may inadvertently reset the buffer
- [RISK_SHARED_PTR_NEW] Out of sync shared_ptr usage counter
- [RISK_WRONG_MODALITY_VOILUT_DATASET] The client may apply to the image the modality VOI/LUT from the wrong dataset
- [RISK_FULL_MEMORY] The memory retained in the memory pool may cause an out-of-memory error
- [RISK_WRONG_VOILUT_DATASET] The library client may apply to an image the VOI/LUT from a wrong dataset
- [RISK_OUT_OF_MEMORY_BIG_IMAGE] Big images or corrupted image size tags may cause an out-of-memory error
- [RISK_LONG_PARAMETERS_LIST] Specifying the tag id in the dataset methods may create a long confusing list of parameters
- [RISK_COPY_CONST_OBJECTS] A const object may be copied into a non-const object
- [RISK_TAGS_DONT_EXIST] The client may ask for tags that don’t exist
Standard operating procedures
- Introduction
- SOPs
- SOP NEWSOP/1: Creating a new SOP
- SOP MODSOP/1: Modifying the SOPs
- SOP BUGUSER/1: Reporting a bug: instructions for users
- SOP BUGDEV/1: Reporting a bug: instructions for the library developers
- SOP ACKBUG/1 Acknowledging a bug report or a feature request
- SOP FIXBUG/2 Fixing a bug
- SOP FIXBUG/1 Fixing a bug
- SOP NEWREQ/1 Introducing a new requirement
- SOP NEWFEAT/1 Announcing a new feature
- SOP NEWENH/1 Announcing the enhancement of an existing feature
- SOP DEVFEAT/3 Implementing a new feature
- SOP DEVFEAT/2 Implementing a new feature
- SOP DEVFEAT/1 Implementing a new feature
- SOP DEVENH/2 Implementing a new enhancement
- SOP DEVENH/1 Implementing a new enhancement
- SOP CHGLOG/1 Preparing the changelog
- SOP RELEASE/3 Preparation of a new release
- SOP RELEASE/2 Preparation of a new release
- SOP RELEASE/1 Preparation of a new release
- SOP MAJORVERSION/2 Development of a new major version
- SOP MAJORVERSION/1 Development of a new major version