dicomobjects manual
LINK 1 ENTER SITE >>> Download PDF
LINK 2 ENTER SITE >>> Download PDF
File Name:dicomobjects manual.pdf
Size: 4304 KB
Type: PDF, ePub, eBook
Category: Book
Uploaded: 23 May 2019, 16:23 PM
Rating: 4.6/5 from 676 votes.
Status: AVAILABLE
Last checked: 19 Minutes ago!
In order to read or download dicomobjects manual ebook, you need to create a FREE account.
eBook includes PDF, ePub and Kindle version
✔ Register a free 1 month Trial Account.
✔ Download as many books as you like (Personal use)
✔ Cancel the membership at any time if not satisfied.
✔ Join Over 80000 Happy Readers
dicomobjects manualThe help file remains the primary reference guide for all DicomObjects objects, methods and properties, so if you know which you need, go directly to the help file. This manual however, starts from the opposite point of view, and tells you how to use DicomObjects to accomplish specific aims. In many cases you will still need to reference the help file for full details of parameters etc., but at least after reading this manual, you should know which sections you need to consult. The purpose of DicomObjects is to allow you, the application developer, to use DICOM in your applications, with as little need as possible for knowledge of the intricacies of the DICOM standard. It is of course not the only DICOM toolkit available, but the hope is that it fills an important niche in the market, due to the following features: DICOM is accessed through high-level interfaces, allowing many operations to occur on whole images etc. Finer level details are available where needed, allowing modification of individual image attributes. All DICOM SOP classes are supported, even types of image or other data not yet defined. Internal multi-threading, allows high-performance servers to be constructed even using singlethreaded clients such as Visual Basic. A high level of support and advice is provided as expected from a commercial product. The pricing structure removes the up-front costs often associated with such toolkits. There are many possible uses for DicomObjects, but here is a brief list of some common ones: Image viewing software (either stand-alone or web-based) DICOM image servers DICOM image creation from scratch in radiological equipment Import and export of images from and to other formats Teleradiology applications Intermediate routing stations, receiving images from one application and sending to another, modifying the data itself, or the surrounding associations to overcome incompatibilities.https://www.emsesizdirmazlik.com/yuklenen/fck/breville-espresso-800esxl-manual.xml
- Tags:
- dicomobjects manual.
Modality worklist servers, using data from ODBC or HL7 Quality assurance Off-line media readers and writers including DICOMDIR handling DICOM and Windows printing Diagnostic test applications 1.1 Structure DicomObjects uses only a small selection of objects, but most of these have a wide variety of methods and properties available. The main items are: DicomViewer This is one of only two objects to occupy space in a window at runtime, and can display multiple images. DicomImage and DicomDataSet These two hold DICOM instances, and have many similarities, the difference being that a DicomImage has pixel data, whereas a DicomDataSet normally does not. DicomPrint An object to simplify DICOM printing. Collections DicomImages, DicomDataSets and DicomAttributes objects hold multiple items of the corresponding types. Advanced Objects Other objects include the DicomLog, DicomServer, DicomGlobal and DicomContext(s), but these will be introduced as necessary below. 1.2 Languages Supported The language used for all examples in this manual is Visual Basic. There are several reasons for this, the main ones being: It is the language used within Medical Connections for client programming. The structure is fairly obvious even to those not used to it. Using one consistent language throughout keeps this manual simple. Of course, the language specific sections use appropriate code! 1.3 Effects of Using the COM Object Model DicomObjects uses the Windows COM model exclusively, which has the following advantages: Language independence Encapsulation within a replaceable file (The OCX file) However, there are a few drawbacks and common mistakes: Every method must apply to one or more objects, as there are no freestanding methods. An example where this can be confusing is the ReadFile method, which has to be applied to an existing object (a DicomImages collection or DicomGlobal object) to create a new object of a different type.http://www.romaritmie.it/userfiles/breville-esp8xl-cafe-roma-manual.xml The DicomObjects file must be distributed and registered with every copy of the application. Fortunately, with version 4, other file dependencies have now virtually been eliminated, and most modern installers have no problems adding and registering components such as DicomObjects. 1.4 Collections in DicomObjects There are a number of Collection objects in DicomObjects, which share many common methods, enabling objects to be added to, accessed or removed from the collection. The following properties and methods are common to all collections in DicomObjects. Count The number of items currently in the collection Item(long integer n) Returns a reference to the n th item in the collection. This is the default member of the collection, so for instance Images.Item(n) may be replaced in Visual Basic by Images(n). Not all languages support this simplification however, so the full version or other forms such as Images.GetItem(n) may be necessary in some environments. In general (but with a few important exceptions), only objects of the appropriate type may be added to a collection, e.g. only DicomLabel objects may be added to a DicomLabels collection. Remove (long integer n) Removes item n from the collection, moving items above it down to fill the gap. Clear Completely empties the collection, removing all items from it. Notes: In DicomObjects, all collection indices start from 1 (not 0), so the range of items is from Item(1) to Item(Count). A DicomContexts collection is indexed by presentation context ID, which must in DICOM always be a small odd integer, so indices are 1, 3, 5 etc. DicomImages and DicomDataSets collections allow indexing by instance UID, so the index is actually a variant, which should be either an integer, or a UID string. 1.5 DicomObjects Representation of DICOM Data The object most commonly used in DicomObjects is the DicomImage, which encapsulates a single SOP instance, normally including pixel data.http://superbia.lgbt/flotaganis/1647766485 A DicomDataSet is virtually the same, but is normally used for datasets (e.g. query results or elements within sequences) which do not contain pixel data. For the remainder of this section, a DicomImage (or just image) will be used for examples, but unless specified otherwise most non-pixel related features apply equally to both. An important concept to grasp early on is that a DicomImage includes two completely separate sources of data: The original DICOM dataset Ephemeral data such as zoom factor, orientation, associated annotations and windowing values In general, the DICOM data itself is accessed and modified through the image s Attributes property, and ephemeral data through simple properties, but there are a few properties such as Name, PatientID etc., which are in fact just shortcuts to the underlying DICOM data. All such properties are clearly indicated as such in the help file. A few properties, such as window Width and Level are ephemeral properties which may be altered without modifying the underlying data, but where possible, they are initialised using data from the DICOM dataset. There are 2 important and often misunderstood consequences of the separation of the two types of data in a DicomImage: Two or more DicomImages can share the same permanent data, yet have their own ephemeral data. This facility is in fact used whenever a DicomImage is added to a DicomImages collection, as this method causes a completely new DicomImage to be created and added to the collection. This new image references the same permanent data, and is initialised with a copy of the original ephemeral data, but this may subsequently be modified. This procedure saves memory for the large DICOM dataset, yet allows different display parameters (e.g. dual window displays). Changes made to simple DicomImages properties do not generally modify the underlying DICOM data (other than for the shortcut properties mentioned above).http://entrevoies.com/images/braeburn-model-5000-thermostat-manual.pdfSlightly different procedures apply for accessing (reading) and modifying the data Accessing Attributes An individual attribute is normally accessed from any language using the group and element tag numbers. In some languages a syntax such as image.attributes.item(gggg,eeee) or image.attributes.getitem(gggg,eeee) is required. However, as Item is the default property for a DicomAttributes object, many languages allow a syntax more like image.attributes(gggg,eeee). The value returned by this property is a DicomAttribute, which has a few properties, but the main ones of interest are: Exists: True if the item is present in the dataset. Value: A variant representation of the data contained This is the default property, and the explicit name can in some languages be omitted. See below for details of sequence handling. Otherwise, if the data element could possibly contain multiple values (i.e. the DICOM VM is not 1 ), then the variant returned will be a single dimensional array of the appropriate type of value, even if only a single item happens to be present. This will also apply to any attributes unknown to DicomObjects such as private elements, as the VM cannot be determined. The rationale for this behaviour is to simplify coding, as a programmer does not need to write separate code for single and multiple value cases. As of version 4.1 it is no longer necessary to handle multiple values using a variant array, as the number of items may be determined using a DicomAttribute s VM property, and the individual items may then be accessed directly using the ValueByIndex(n) property. For some applications it is necessary to iterate through all the attributes, without necessarily knowing in advance which tags are present. In languages which support direct iterators on collections, this is easy (e.g. For Each in Visual Basic), but for languages which lack this facility, the ItemByIndex method is provided.https://evocative.ru/wp-content/plugins/formcraft/file-upload/server/content/files/16280881d84f8f---bsim3-manual.pdf Some scripting languages (notably VBScript, and some unusual scripts such as that used in MatLab), cannot use arrays consisting of anything except variants. For these environments, the VariantValue is provided, which can return variant arrays of variants see the help file for more details. Another variation on the Value property is the UnicodeValue. If the value is a suitable string, and if the character set attribute (0x0008,0x0005) is present, then the value is interpreted according to the appropriate character set rules (if installed on the operating system!) Changing the DICOM data As we cannot know in advance whether a particular attribute will even exist in a dataset, DicomObjects does not allow direct modification of the value of a DicomAttribute. Instead, particular members of a DicomAttributes collection may be replaced or removed, using the Add and Remove methods The Add method uses a variant parameter to hold the value, which should normally be of the same type as listed above for the Attribute.Value result, with the following modifications: Values will be coerced as necessary e.g. the value 2 would be valid for any numerical VR. A zero-length string may be used to set null value. Single values may be used even when the VM is 1-n (though arrays are also of course allowable). Where an attribute with the same tags already exists, it is simply replaced. 1.6 Interpreting and Using Sequences DICOM allows one attribute to contain a sequence of datasets, and DicomObjects provides direct support for this arrangement by allowing one attribute to contain a DicomDataSets object, which in turn may contain one or more DicomDataSet objects. This structure is inherently recursive, and nesting to any depth is allowed (some DICOM IODs require 4 level nesting!), and can be used for both creation and read access to data in sequences.BANGKOKSOLARPOWER.COM/syner_upload/images/files/bpw-eco-plus-manual.pdf Note though that recursion is through two levels, as a DicomDataSet object contain a DicomDataSets collection, which contains one or more DicomDataSet objects, so it is necessary to be careful with the syntax. DicomObjects has an internal dictionary of all officially known tags at its release date, but new tags are being added all the time, and a programmer using the latest definitions may face the same problem. DicomObjects provides two ways of dealing with this problem: AddExplicit This method is a minor variant on the normal Attributes.Add method, supplying a two character VR code, in addition to the tag numbers and the value. This code must be one of the standard VR types such as US (unsigned short), LO (long text) etc. A VM may be added, which improves error checking, and allows the DicomAttribute.Value property to return single values where appropriate, rather than arrays.As in all examples, the actual script is visual Basic, but the equivalent should be clear in any other environment. If all is well, an obstetric ultrasound image should be shown (my twins!), scaled to fit the DicomViewer you have created. So what does the above command actually do, and how does this introduce you to use of DicomObjects. In fact, you have used 3 of the 10 different object types available, a DicomViewer, which provides a display area within a window, a DicomImage, which represents a single DICOM image, and a DicomImages collection, which as expected, holds a collection of DicomImage objects. We will consider each of these in turn: The DicomViewer This provides a rectangular area within which one or more images may be displayed. It has many properties and methods, to which you will be introduced later, but a few or the more important are: MultiRows and MultiColumns These integer properties control the division of the DicomViewer into a number of images cells, a grid of the specified number of equally sized rows and columns, with the ability to display an image in each.https://www.birdandwildlifeteam.com/wp-content/plugins/formcraft/file-upload/server/content/files/16280882f43d66---Bsl-solution-manual.pdf Images This is a DicomImages collection (see below), an intrinsic and inseparable part of the DicomViewer, which holds the images to be displayed by the DicomViewer. CurrentIndex An integer index (1-based) specifying which of the images in the Images collection is to be displayed in the top-right cell The DicomImages Collection Like most objects, a DicomImages collection may be created as a stand-alone object, but a special collection exists as part of each DicomViewer. This object, accessed as the Images property of the DicomViewer, holds the images displayed by that DicomViewer. It has the standard methods and The file is read, and added to the end of the DicomImages collection. The method also returns a reference to the added image, but this is not always used A DicomImage This is the object used most commonly in DicomObjects, and encapsulates a DICOM image, whether that image has been read from disk (as above), generated from scratch or received over a network. It is important to realise that a DicomImage object is more than just the underlying DICOM data, as many of its properties, such zoom or rotation affect only how an image is displayed or otherwise handled within DicomObjects, without affecting the underlying data. The underlying data can be altered, but only though explicit use of the Attributes property or through a limited number of named properties. Some of the more commonly used methods and properties of a DicomImage are: Width and Level (long integer) As is normal practice for radiological images, these properties allow the user to alter the mapping of the original DICOM data to the greyscale values displayed. They exemplify the principle stated above concerning underlying and transient information, as the initial values are derived from the suggested values in the DICOM data (if present), but changes to these values do not cause the DICOM attributes themselves to change.http://exactblue.com/wp-content/plugins/formcraft/file-upload/server/content/files/16280883e96567---bsnl-manual-gprs-settings-north-zone.pdf StretchToFit (boolean) and Zoom (float) If StretchToFit is true, the image is scaled to show it at the largest size possible within it s cell in the DicomViewer (and Zoom is ignored). Otherwise, the Zoom property controls the image s magnification, a value of 1 causing one image pixel to correspond with 1 screen pixel. Many other properties exist, and will be considered later. WriteFile(FileName as String, Part10 as Boolean, TransferSyntax as String, Quality as Variant) In a sense this is the reverse of the ReadFile method above, except that it applies to an image, not a collection, and it has more options, as it is necessary to specify features such as transfer syntax, which are determined automatically when a file is read.Whilst the protocols are internally complex, and advanced programmers can access most of this complexity if they wish, DicomObjects provides several simple ways for you to do such transfers without worrying too much about the underlying transport system. 3.1 Sending an Image For this, the Send method of a DicomImage (or DicomDataSet) is required, and this takes just four parameters: IP address or other resolvable network name of the SCP Port number on which the SCP is listening The Application Entity Title (AET) of the SCP The AET you wish to call your application for this operation Although some setting up of the SCP to receive images from your application may be required (most only accept from a list of known machines), this simple four parameter method is all you need to do to do a full transfer, as it will: Make an Association Negotiate presentation contexts (to include that for your image or dataset) Send the image using C-STORE Close the association Return the status it is sent (0 for success) Because of this last point, the operation must be synchronous i.e. it does not return until the transfer is complete (or fails). If any error occurs other than a non-zero status code (e.g. TCP connection failure), a trappable error will be thrown. 3.BANGKOKCABLE.COM/ckf_bccUpload/files/bpw-eco-plus-2-manual.pdf2 Receiving Images Every DicomViewer has the ability to listen on one or more TCP ports, and to receive images sent to it over the network. DicomServer objects have approximately the same functionality without the ability to display images, and unless noted explicitly, most of the properties, methods and events related to network activity apply equally well to a DicomServer. As an utterly trivial example of how to receive an image (assuming you have an application or equipment that can send images), re-open the simple program created in the last chapter (just use points 1-3 if starting from scratch here), but then add and run code to perform the following method call: Viewer.Listen 104 Next, set up your sending equipment or program to send images to your PC, using the following parameters: IP Address: That of Your PC Port: 104 Called Application Entity: Anything (for now!) Finally, try sending an image to the destination configured above it should display on the viewer! By using the same object for both query (C-FIND) and retrieve (C-GET and C-MOVE) constant properties such as the application entry details of the server do not have to be re-entered. A few other methods also exist, which have some differences: DoRawQuery This is like DoQuery, but permits more flexibility, and is needed for worklist queries. MoveSync A synchronous move operation, only suitable for moving to other programs or machines. MoveImages This is an asynchronous operation, which return immediately. A 4 th value WORKLIST is used for modality worklist queries, but these are covered separately (section 14 below) and will not be covered further in this section. As it is common to make many consecutive calls to the same SCP using the same query root, these properties may usefully be set just once, and then re-used for subsequent queries. The type of object represented by each response is set by the QueryLevel property which indicates the type of query being performed. Valid values are PATIENT, STUDY, SERIES or IMAGE. DicomObjects requests a reasonably comprehensive list of return values, including all mandatory values. If any obscure values are required (and are supported by the SCP), then you may need to use DoRawQuery to add them as nulls to the query dataset. 4.3 GetImages Where the SCP supports C-GET (now increasingly rare!), this method allows simple synchronous image retrieval. All selection properties relevant to the QueryRoot are used, and the result of this method is a DicomImages collection. One of the problems with C-GET is that the SCU must, during negotiation, pass a list of the abstract syntaxes (SOP classes) it is prepared to accept, yet until the query is run it does not necessarily know what the SCP will attempt to send it. DicomObjects copes with this by sending a list of all the The internal mechanics are much more complicated, as it has to set up a listening port, send the request and receive the images on one or more separate associations, but the overall effect is a similar synchronous method. There are however, several important differences: The Destination property must be set to a value known to the SCP to represent this application. Note that this is the only information which the C-MOVE protocol allows the SCU to send regarding the image destination, therefore the SCP must be set up to map this name to the correct IP address and port number. Many users fail to understand that C-MOVE cannot be used without such configuration of the SCP, and that no DICOM SCU has any way of avoiding this necessity. The ListenPort property must be set to the value known to the SCP as above. This port must not be used for other purposes, and in particular, it should not be used in a DicomViewer.Listen or DicomSever.Listen call. 4.5 DoRawQuery Functionally, this is just like DoQuery, the only difference being that a user-supplied dataset is used to create the query, rather than using the selection properties to create one. This is slightly more work for the programmer, but does then allow total flexibility, as any of the query and return values may be included. Please note that the QueryLevel property is in fact a member of this dataset, and an appropriate value for this attribute (0x0008,0x0052) needs to be included. 4.6 MoveSync This method simply issues a C-MOVE request, instructing images to be moved to the AET given by the Destination property. It waits for the operation to complete (by which time any secondary C-STORE operations must also be complete), then returns the final status of the C-MOVE operation. This method is ideal for moving images to a different application (whether on the same machine or another), but it must not be used to move images back to the same application. The reason is that such images could not be accepted until the AssociationRequest and ImageReceived events had fired, but these cannot fire while this (synchronous) operation is waiting for completion, so a deadlock would occur. For moves back to the originating application, use GetUsingMove, MoveImages, or DicomConnection.Move instead. 4.7 MoveImages This method is like MoveSync above, but it after making the initial association, it returns immediately. The result is that it can be used to move images back to the originating application, avoiding the deadlock described above, but it has a major problem in that no success or error indications can be returned. There are some occasions, however, where it is desirable to run these methods in the background, and this can be done All these are like DoRawQuery, in that they require you to provide a complete valid query dataset, so they are slightly more work than the simpler DicomQuery-based methods, but they do provide total flexibility, asynchronous operation, and full error reporting. They are therefore the recommended query methods for advanced users. Please note that the SOP classes required for these methods are not included in the default list offered by an outgoing DicomConnection.Many of these requirements such as the requirement to use ISO 9660 format for CDs are beyond the scope of DicomObjects, but it does provide support for reading, writing and modifying DICOMDIR files, as well as the actual images. The structure of a DICOMDIR file is actually quite complex. Logically, it is arranged hierarchically, the normal 5 layer hierarchy being: Fileset, which contains one or more Patients, which have one or more Studies, which have one or more Series, which have one or more Images, which reference the actual image files, and may contain icons (Other structures are possible but rare) However, the data items are arranged as a single sequence within the DICOMDIR file, using a complex series of file offsets to define the hierarchical structure. It would clearly be very difficult for a highlevel programmer to generate these offsets, so DicomObjects presents the DICOMDIR to the programmer using the hierarchical structure, and does any necessary offset calculations only during reading and writing. A DICOMDIR is read as a DicomDataSet, representing the Fileset object, and the next level of the hierarchy (normally representing individual patients) can be found as the items in its Children collection, and these in turn have Children properties containing the studies, and so on down to images. This same structure may be modified or built from scratch to allow modification and writing of DICOMDIR files. 5.1 Reading Reading a DICOMDIR file is very easy just create a new DicomDataSets object, use the ReadDirectory method, and the whole hierarchical structure referred to above will be found in the resulting DicomDataSet. To extract all the information within it, just iterate through the members of the datasets Children collection, each of which should represent a patient. Each of these will have a Children collection representing studies, and so on down to images. Note that you should, at each level, check the directory record type attribute (0x0004,0x1430), to ensure that it is as expected (PATIENT, STUDY etc.), as some manufacturers (quite legally) add PRIVATE items, which can cause confusion if not skipped Finding the Image File Once the lowest level of the hierarchy is reached, the dataset should represent a single image, but you then may need to find the filename of the image file it references. The required attribute is 0x0004,0x1500, and the value of this is an array of strings, representing the path from the DICOMDIR, to the image file. e.g. if the directory is at D:\DICOMDIR, and this attribute returns a 3 value array containing IMAGES, PAT02, IMG0004, then the image file can be found at: D:\IMAGES\PAT02\IMG0004 Sample VB code is as follows, but other this is slightly more complex in other languages due to the need to interpret SAFEARRAYs correctly. If present, this appears as a sequence attribute (0x0088,0x0200), normally in an IMAGE level dataset, but it may sometimes be found in a SERIES dataset. The icon itself is like a minimalist image, with pixel data, and immediately associated attributes such as size and format, but no demographic data. Due to the way that DicomObjects is structured, extracting this item (the one and only item of the sequence) will result in a DicomDataSet object not a DicomImage, but fortunately, this is not a problem, as a DicomDataSet may be added to a DicomImages collection, and the result is (perhaps surprisingly) a DicomImage. This takes an image and a few other details as its parameters, and adds all necessary elements to the dataset, ensuring not only that every patient, study etc.In addition, icon images may easily be added to the data. This massively reduces the amount of work involved in making a DICOMDIR, but there are still some things you need to consider: You need to choose your own file and path names, and ensure these are not duplicated within a FileSet You must ensure that file and path names correspond to the requirements for your chosen media. For CDs, this means that they must be 8 or less characters, upper case, and with no extensions. Note that the filename you pass to the AddToDirectory method must be relative to where you intend to write the DICOMDIR. When calling AddToDirectory the first time on a new dataset, basic top level information is filled in, including a FileSetID (0x0004,0x1130), but you may wish to check and amend this. You should, where possible, also arrange for the FileSetID to be written as the volume label when burning onto a CD or writing to MOD etc. Some profiles require attributes beyond the basic ones added by DicomObjects. To help you to add these, the return values from AddToDirectory is itself a DicomDataSets collection, with four items, referencing the patient, study, series and image datasets respectively. If required, further attributes may be added to any of these. Any necessary changes to the offset values will happen automatically. 5.4 Multiply Referenced Directory Records DICOM allows a variation on the neat hierarchical structure above whereby a record can be referenced by multiple other records, a Multiply referenced directory record, or MRDR. DicomObjects supports such records, through the MRDR property, which is documented fully in the help file, but if such records are used, it is your responsibility to maintain the directory structure, using the MRDR property. This type of record is not used by the AddToDirectory method, but DicomObjects does still handle offset calculations during both reading and writing.