Материал: part17

The UV Mapping Sequence (0080,0008) is used to associate the VL Photographic Image instances with the Surface Scan Point​ Cloud instance. The Texture Label (0080,0009) is used to identify the textures of one point cloud.​

Figure JJJ.6-1. Multishot With Two Texture Per Point Cloud​

JJJ.7 Using Colored Vertices Instead of Texture​

Use-case:Asinglesurfacerecordofapatientismade,forexampleteeth,nose,orbreast.Ifthirdpartysoftwaredoesthepost-processing​ only the point cloud needs to be stored. Gray or color values can be assigned to each point in the point cloud.​

The point cloud is stored in a Surface Scan Point Cloud instance. A study with a single series is created. One or both of the Attributes​ Surface Point Presentation Value Data (0080,0006), or Surface Point Color CIELab Value Data (0080,0007) may be used to assign​ gray or color values to each point in the point cloud.​

Figure JJJ.7-1. Using Colored Vertices Instead of Texture​

JJJ.8 4D Surface Data Analysis​

Use-case: To replay a sequence of multiple 3D shots of different facial expressions of a patient before facial surgeries such as facial​ transplantation.​

A time stamp for each shot is stored in the Acquisition DateTime Attribute (0008,002A).​

JJJ.9 Referencing A Texture From Another Series​

Use-case: A texture from another series must be applied to a point cloud.​

The Referenced Instances And Access Macro is used within the Referenced Textures Sequence (0080,0012) to reference a VL​ Photographic Image instance from a different study.​

Figure JJJ.9-1. Referencing A Texture From Another Series​

- Standard -​

- Standard -​

KKK Use-cases For Conversion of Classic​ Single Frame Images to Legacy Converted​ Enhanced Multi-frame Images (Informative)​

KKK.1 Introduction​

Traditionally, images from cross-sectional modalities like CT, MR and PET have been stored with one reconstructed slice in a single​ frame instance. Large studies with a large number of slices potentially pose a problem for many existing implementations, both for​ efficient transfer from the central store to the user's desktop for viewing or analysis, and for bulk transfer between two stores (e.g.,​ between a PACS and another archive or a regional image repository).​

There are two primary issues:​

•​Transporting large numbers of slices as separate single instances (files) is potentially extremely inefficient due to the overhead​ associated with each transfer (such as C-STORE acknowledgment and database insertion).​

•​Replicating the Attributes describing the entire patient/study/series/acquisition in every separate single instance is also potentially​ extremely inefficient, and though the size of the this information is trivial by comparison with the bulk data, the effort to repeatedly​ parse it and sort out what it means as a whole on the receiving end is not trivial.​

The Enhanced family of modality-specific multi-frame IODs is intended to address both these concerns, but there is a large installed​ base of older equipment that does not yet support these, both on the sending and receiving end, and a large archive of single frame​ instances.​

An interim step, a legacy transition strategy for a mixed environment containing older and newer modalities, PACS and workstations,​ is described here. It is predicated on the ability to "convert" single frame instances into new "enhanced multi-frame instances".​

KKK.2 Enhanced Legacy Converted Image Storage IODs​

The Enhanced family of modality-specific multi-frame IODs contain many requirements that cannot be satisfied by the limited inform-​ ation typically available in the older single frame objects. A family of Multi-frame Secondary Capture IODs is available, but their use​ would mean that a recipient could not depend on the presence of important cross-sectional information like spacing, position and​ orientation. Accordingly, a new family of modality-specific Legacy Converted Enhanced Image Storage IODs has been defined that​ bridge the gap in conversion complexity and usability between these two extremes.​

KKK.3 Heterogeneous Environment​

Figure KKK-1 illustrates the approach to enabling a heterogeneous environment with conversion from single to multi-frame objects​ as appropriate. In this figure, modalities that generate single or enhanced images peacefully co-exist with PACS or workstations that​ support either or both.​

- Standard -​

Legend:

Classic Single Frame

Legacy Converted Multi-Frame

True Enhanced Multi-Frame

Figure KKK-1. Heterogeneous environment with conversion between single and multi-frame objects​

The following use-cases are explicitly supported:​

•​A PACS that accepts single frame images, and converts them to Multi-frame Images for its own internal use.​

•​A PACS that accepts single frame images, and converts them to Multi-frame Images for externalization via DICOM services​ (Query/Retrieval) so that they can be used by external workstations (or other processing applications) that support Multi-frame​ Images.​

•​A PACS that accepts Multi-frame Images from a modality, and converts them to single frame images for its own internal use.​

•​A PACS that accepts true and/or legacy converted enhanced Multi-frame Images, and converts them to single frame images for​ externalizationviaDICOMservices(Query/Retrieval)sothattheycanbeusedbyexternalworkstations(orotherprocessingapplic-​ ations) that do not support Multi-frame Images.​

•​A modality that can create true enhanced Multi-frame Images, as well as receive true (+/- legacy converted) enhanced Multi-frame​ Images.​

•​Return of results from workstations in either single frame or true or legacy converted enhanced multi-frame form.​

The amount of standard information is the same in single frame and transitional legacy-converted Multi-frame Images, but greater in​ the true enhanced Multi-frame Images, and this affects the level of functionality obtainable within the PACS or with an external​ workstation (without depending on private information).​

Since the transitional legacy-converted and true enhanced Multi-frame Images share a common structure and common functional​ group macros, this scalability can be implemented incrementally.​

ItisNOTtheexpectationthatmodalitieswillgenerateLegacyConvertedEnhancedImageStorageSOPInstances;rather,theyshould​ create True Enhanced Image Storage SOP Instances fully populated with the appropriate Standard Attributes and codes.​

KKK.4 Compatibility With Modality Association Negotiation​

This strategy is compatible with an approach commonly implemented on acquisition modalities when deciding which SOP Class to​ use to encode images.​

Normally a modality will propose in the Association that images be transferred using the SOP Class for which the IOD provides the​ richest set of information (i.e., the True Enhanced Image Storage SOP Class), and will choose the corresponding Abstract Syntax​ for C-STORE Operations if the Association Acceptor accepts multiple choices of SOP Class.​

- Standard -​

Consider a modality that supports the appropriate modality-specific Enhanced Image Storage SOP Class, but which is faced with the​ dilemma of a PACS that does not. In this case, it will commonly "fall back" to sending images the "old" way as single-frame SOP​ Class Instances, either because it has been pre-configured that way by service personnel, or because it discovers this limitation​ during Association Negotiation. This strategy is also common amongst modalities for which there are different choices of single frame​ SOP Class (e.g., DX versus CR versus Secondary Capture, for Digital X-Rays). In some cases, this may be implemented formally​ using the ability during Association Negotiation to specify a Related General SOP Class (Section B.4.2.1 “SCU Fall-Back Behavior”​ in PS3.4).​

If the PACS is upgraded to include multi-frame conversion capability, and no change is made in the configuration of the modality, or​ in the SOP Classes accepted by the PACS, then in this scenario, the PACS can potentially convert the single-frame instances into​ Legacy Converted Enhanced instances. The net result is continuing sacrifice of information compared to what the modality is actually​ capable of.​

A better choice, since the PACS is now capable of handling Multi-frame Images, is to also reconfigure it to also accept the "true" En-​ hanced Image rather than just "transitional" Legacy Converted Enhanced Storage SOP Classes. Since the two SOP Class families​ usethesamestructureandcommonimportantFunctionalGroups,inalllikelihoodthePACSwillbeabletouseeitherclassofobjects,​ and in a future upgrade take advantage of the additional information in the superior object (perhaps for more complex processing or​ annotation or rendering). In any case, storing the modality's best output in the archive will benefit future re-use as priors and may​ enable greater functionality in external workstations.​

A special consideration is when prior images need to be displayed on the modality before starting a new study (perhaps to setup a​ comparableprotocolorbetterunderstandtherequest).Inthiscase,careneedstobetakenwithrespecttowhichimagesareaccessible​ to the modality (either pushed to it or retrieved by it), and the question of "round trip fidelity" of conversion arises.​

KKK.5 Query and Retrieval​

The coexistence (either actually or logically) of two different representations of the same information creates a potential challenge in​ that the user must not be presented with both sets simultaneously.​

A naïve conversion that added converted images to the study without an ability to distinguish or "filter" them from view would not only​ be confusing but would potentially result in twice as much data to transfer.​

Accordingly, the Query/Retrieve mechanism is extended with an optional extended negotiation capability to specify which "view" of​ the information is required by the SCU:​

•​A"classic"view,whichincludeseitheroriginal(asreceived)classicsingleframeimagesorenhancedMulti-frameImagesconverted​ to single frame.​

•​An "enhanced" view, which includes either original (as received) enhanced Multi-frame Images, or classic single frame images​ converted to true or legacy converted enhanced multi-frame.​

KKK.6 Referential Integrity​

Often instances within a Study will cross-reference each other. For example, a Presentation State or a Structured Report or an RT​ Structure Set will reference the images to which they apply, cross-sectional images may reference localizer images, and images that​ were acquired with annotations may contain references to Presentation States encoding those annotations.​

Accordingly, when there are multiple "views" of the same study content (classic or enhanced), the instances will have different SOP​ InstanceandSeriesInstanceUIDsforconvertedcontentineachview.Henceanyreferenceswithinaninstancetoaconvertedinstance​ needs to be updated as well. In doing such an update of references to UIDs, instances that might not otherwise have needed to be​ converted do need to be converted, and so on, until the entire set of instances within the scope of the conversion for the view has​ referential integrity.​

In practice, the only instances that do not need to be converted (and assigned new UIDs) are those that contain no references and​ are not classic or enhanced images to be converted.​

Whether or not assignment of a converted instance to a new Series triggers the need to convert all instances in that Series to the​ new Series, even if they would not otherwise be converted, is not defined (i.e., it is neither required nor prohibited, and hence a Series​ can be "split" as a consequence of conversion).​

- Standard -​