Difference between revisions of "The CTP DICOM Pixel Anonymizer"

From MircWiki
Jump to: navigation, search
(The Script File)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
The CTP DicomPixelAnonymizer is a pipeline stage that blanks regions of pixels in a DICOM image. It is configured with a script file that specifies which regions are to be blanked, based on information in the non-pixel part of the DICOM dataset. This article describes the script file and the language in which it is written. The intended audience for this article is CTP administrators setting up a processing pipeline.
 
The CTP DicomPixelAnonymizer is a pipeline stage that blanks regions of pixels in a DICOM image. It is configured with a script file that specifies which regions are to be blanked, based on information in the non-pixel part of the DICOM dataset. This article describes the script file and the language in which it is written. The intended audience for this article is CTP administrators setting up a processing pipeline.
 +
 +
For information on configuring the DicomPixelAnonymizer stage, see [[Using the CTP DicomPixelAnonymizer]].
 
==The Script File==
 
==The Script File==
 
The script file is organized into one or more sections, with each section being comprised of a <b>signature</b> and one or more <b>region</b>s. The format of a section is shown below:
 
The script file is organized into one or more sections, with each section being comprised of a <b>signature</b> and one or more <b>region</b>s. The format of a section is shown below:
Line 14: Line 16:
 
When the DicomPixelAnonymizer receives a DicomObject, it first tests the object to see if it is an image. If it is not an image, it passes the object on without modification.
 
When the DicomPixelAnonymizer receives a DicomObject, it first tests the object to see if it is an image. If it is not an image, it passes the object on without modification.
  
If the object is an image, it next determines whether the object contains encapsulated pixel data. Such objects contain compressed images. Encapsulated pixel data objects are passed without modification. If such objects are to be processed, they must first be decompressed by including a [[CTP-The_RSNA_Clinical_Trial_Processor#DicomDecompressor|DicomDecompressor]] stage in the pipeline somewhere before the DicomPixelAnonymizer.
+
If the object is an image, it next determines whether the object contains encapsulated pixel data. Such objects contain compressed images. The DicomPixelAnonymizer only accepts uncompressed images or images compressed with the JPEGBaseline syntax. All other images are passed without modification. Any other objects that are to be processed must first be decompressed by including a [[CTP-The_RSNA_Clinical_Trial_Processor#DicomDecompressor|DicomDecompressor]] stage in the pipeline somewhere before the DicomPixelAnonymizer.
  
 
If the object meets the above criteria, the DicomPixelAnonymizer sequences through the signatures defined in the script file to find a signature that the object matches. The DicomPixelAnonymizer blanks all the regions in the image associated with the first matching signature. When a region is blanked, all the pixels in the region are replaced with zeroes.
 
If the object meets the above criteria, the DicomPixelAnonymizer sequences through the signatures defined in the script file to find a signature that the object matches. The DicomPixelAnonymizer blanks all the regions in the image associated with the first matching signature. When a region is blanked, all the pixels in the region are replaced with zeroes.

Latest revision as of 22:41, 19 June 2015

The CTP DicomPixelAnonymizer is a pipeline stage that blanks regions of pixels in a DICOM image. It is configured with a script file that specifies which regions are to be blanked, based on information in the non-pixel part of the DICOM dataset. This article describes the script file and the language in which it is written. The intended audience for this article is CTP administrators setting up a processing pipeline.

For information on configuring the DicomPixelAnonymizer stage, see Using the CTP DicomPixelAnonymizer.

1 The Script File

The script file is organized into one or more sections, with each section being comprised of a signature and one or more regions. The format of a section is shown below:

{ signature }
(region) (region) ... (region)

Each signature defines one image type based on a calculation specified in the signature's script. The signature's script is enclosed in braces, { and }. Each region is enclosed in parentheses.

Any text that is not contained within braces or parentheses is treated as comments. Comments may not contain either braces or parentheses.

When the DicomPixelAnonymizer receives a DicomObject, it first tests the object to see if it is an image. If it is not an image, it passes the object on without modification.

If the object is an image, it next determines whether the object contains encapsulated pixel data. Such objects contain compressed images. The DicomPixelAnonymizer only accepts uncompressed images or images compressed with the JPEGBaseline syntax. All other images are passed without modification. Any other objects that are to be processed must first be decompressed by including a DicomDecompressor stage in the pipeline somewhere before the DicomPixelAnonymizer.

If the object meets the above criteria, the DicomPixelAnonymizer sequences through the signatures defined in the script file to find a signature that the object matches. The DicomPixelAnonymizer blanks all the regions in the image associated with the first matching signature. When a region is blanked, all the pixels in the region are replaced with zeroes.

If the object matches no signature in the script file, the object is passed on without modification.

2 The Script Language

The script language interrogates a DICOM object and computes a boolean result that, if true, is interpreted to be a match for the signature. The language is identical to the one defined for the DicomFilter pipeline stage.

3 Regions

A region is a rectangular area of an image, specified by four integers, separated by commas and encapsulated in parentheses. The integers represent:

  • the horizontal component of the left side
  • the vertical component of the top
  • the width
  • the height

The origin of the image's coordinate system is at the upper left corner, with the positive horizontal axis pointing to the right and the positive vertical axis pointing down.

4 Example

The following simple example shows the definition of regions for two different manufacturers' CT products.

{ Modality.equals("CT") 
    * Manufacturer.containsIgnoreCase("manufacturer1") 
        * ManufacturerModelName.containsIgnoreCase("modelA") }
(0,0,100,20) (480,200,32,250)

{ Modality.equals("CT") 
    * Manufacturer.containsIgnoreCase("manufacturer2") 
        * ManufacturerModelName.containsIgnoreCase("modelB") }
(400,0,112,20) (0,200,32,250)

Note that in a real CT study, one might want to use a more sophisticated test to discriminate, for example, between transaxial images and scout images, assigning different signatures and regions to each. For modalities which use DICOM element (0028,0301) to indicate that images contain burned-in annotation, one might also include the additional constraint:

BurnedInAnnotation.equals("YES")