DicomPixelAnonymizer

258 views
Skip to first unread message

Anna

unread,
Aug 2, 2018, 4:06:00 PM8/2/18
to RSNA MIRC CTP/TFS User Group
I added a few lines to DicomPixelAnonymizer.script to remove PHI box in a top part of the frame on bone scan image:

{ ImageType.containsIgnoreCase("SECONDARY") *
Modality.containsIgnoreCase("NM") *
Manufacturer.containsIgnoreCase("GE MEDICAL") *
Rows.equals("862") }
(0,0,1132,60)

The script does not remove anything.
I tried similar scripts for other types of images and manufactures, but could never have any pixels removed from 'secondary' images.
Is there a way to do it or some of the burned-in information cannot be removed from images?

John Perry

unread,
Aug 2, 2018, 4:54:20 PM8/2/18
to rsnas-ctpmir...@googlegroups.com
Anna:
 
If I understand correctly, the script doesn't blank the top part of the image.
 
If so, then the pixel anonymizer isn't matching the image to the signature script. Either that, or the image is compressed and the anonymizer is skipping it.
 
Can you send me (john...@dls.net) an image? I can dump the binary and see what's in it.

If you want to see what the anonymizer is matching, you can set the DicomPixelAnonymizer stage's log attribute to yes. That will force it to log the signature that it matches for the image.
 
If you have the DicomEditor application (http://mirc.rsna.org/download/DicomEditor-installer.jar), it will list the elements and you can see if the signature script really matches the image.
 
JP
--
You received this message because you are subscribed to the Google Groups "RSNA MIRC CTP/TFS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rsnas-ctpmirc-user...@googlegroups.com.
To post to this group, send email to rsnas-ctpmir...@googlegroups.com.
Visit this group at https://groups.google.com/group/rsnas-ctpmirc-user-group.
For more options, visit https://groups.google.com/d/optout.

Anna Alber

unread,
Aug 7, 2018, 6:50:17 PM8/7/18
to rsnas-ctpmir...@googlegroups.com
I installed Image IO Tools and added DicomDecompressor before DicomPixelAnonymizer to the pipeline to see if it resolves the problem. Unfortunately, I cannot send dicom files.

DicomDecompressor expects a script 
script="scripts/dicom-decompressor.script"
 Is there an example of decompressor script that I can use?
I get an error when run with nothing in the script.

 ERROR [DicomObject] 
java.lang.Exception: Failure in parsing the script.
	at org.rsna.ctp.objects.DicomObject.parse(DicomObject.java:2530)
	at org.rsna.ctp.objects.DicomObject.expression(DicomObject.java:2500)
	at org.rsna.ctp.objects.DicomObject.matches(DicomObject.java:2460)
	at org.rsna.ctp.stdstages.DicomDecompressor.process(DicomDecompressor.java:66)
	at org.rsna.ctp.pipeline.Pipeline.processObjects(Pipeline.java:220)
	at org.rsna.ctp.pipeline.Pipeline.run(Pipeline.java:181)


On Thu, Aug 2, 2018 at 1:54 PM, John Perry <john...@dls.net> wrote:
Anna:
 
If I understand correctly, the script doesn't blank the top part of the image.
 
If so, then the pixel anonymizer isn't matching the image to the signature script. Either that, or the image is compressed and the anonymizer is skipping it.
 
Can you send me (john...@dls.net) an image? I can dump the binary and see what's in it.

If you want to see what the anonymizer is matching, you can set the DicomPixelAnonymizer stage's log attribute to yes. That will force it to log the signature that it matches for the image.
 
If you have the DicomEditor application (http://mirc.rsna.org/download/DicomEditor-installer.jar), it will list the elements and you can see if the signature script really matches the image.
 
JP
 
From: Anna
Sent: Thursday, August 02, 2018 3:05 PM
Subject: [MIRC CTP/TFS User Group] DicomPixelAnonymizer
 
I added a few lines to DicomPixelAnonymizer.script to remove PHI box in a top part of the frame on bone scan image:
 
{ ImageType.containsIgnoreCase("SECONDARY") *
Modality.containsIgnoreCase("NM") *
Manufacturer.containsIgnoreCase("GE MEDICAL") *
Rows.equals("862") }
(0,0,1132,60)

The script does not remove anything.
I tried similar scripts for other types of images and manufactures, but could never have any pixels removed from 'secondary' images.
Is there a way to do it or some of the burned-in information cannot be removed from images?
--
You received this message because you are subscribed to the Google Groups "RSNA MIRC CTP/TFS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rsnas-ctpmirc-user-group+unsub...@googlegroups.com.
To post to this group, send email to rsnas-ctpmirc-user-group@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "RSNA MIRC CTP/TFS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rsnas-ctpmirc-user-group+unsub...@googlegroups.com.
To post to this group, send email to rsnas-ctpmirc-user-group@googlegroups.com.

John Perry

unread,
Aug 7, 2018, 7:59:12 PM8/7/18
to rsnas-ctpmir...@googlegroups.com
Anna:
 
If you give the DicomDecompressor a script file, the file must contain a valid script. The script determines whether the decompressor will process the image or skip it. If you want to process (decompress) all images, then you can set the script attribute to the empty string or you can provide a script file that contains the text:
 
    true.
Note that the period after true is required.
 
JP
To unsubscribe from this group and stop receiving emails from it, send an email to rsnas-ctpmirc-user...@googlegroups.com.
To post to this group, send email to rsnas-ctpmir...@googlegroups.com.

Anna Alber

unread,
Aug 9, 2018, 2:35:10 PM8/9/18
to rsnas-ctpmir...@googlegroups.com
John,
After I put 

true.

into decompressor.script, all files went to quarantine directory as a result of running decompressor
Log file does not show anything remarkable, the same as usual.

On Tue, Aug 7, 2018 at 4:59 PM, John Perry <john...@dls.net> wrote:
Anna:
 
To unsubscribe from this group and stop receiving emails from it, send an email to rsnas-ctpmirc-user-group+unsubscr...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "RSNA MIRC CTP/TFS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rsnas-ctpmirc-user-group+unsubscr...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "RSNA MIRC CTP/TFS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rsnas-ctpmirc-user-group+unsub...@googlegroups.com.
To post to this group, send email to rsnas-ctpmirc-user-group@googlegroups.com.
Visit this group at https://groups.google.com/group/rsnas-ctpmirc-user-group.
For more options, visit https://groups.google.com/d/optout.

Karine Seymour

unread,
Aug 17, 2018, 3:38:53 PM8/17/18
to RSNA MIRC CTP/TFS User Group
Dear all,

I am having the same problem as Anna with the DicomPixelAnonymizer stage.

My pipeline stages are :
- ArchiveImportService
- DicomDecompressor
- DicomPixelAnonymizer
- IDMap
- DicomAnonymizer
- FileStorageService

My DicomPixelAnonymizer script is :

 SCREENSHOTS
  { Modality.equals("NM") }
  (0, 0, 500, 300)

I followed John's advice and set log to yes to log the matching signature. I also activated the test mode.

I see in the logs : 
21:14:04 INFO  [DicomPixelAnonymizer] DicomPixelAnonymizer: DicomObject 1.3.12.2.1107.5.6.1.12345.30000017101708323030300000011 matched:
 Modality.equals("NM") 


I understand this means it did find a matching signature and should blank the image, but nothing happens. 
If I look at status, the name and file location remain the same after this stage. Images have not been moved to the DicomPixelAnonymizer root directory.

I tried removing the DicomDecompressor stage, but this did not change anything. Note that my images are uncompressed.

The version I am currently running is Build: 2017.10.12.

Could this be a bug?

Thanks in advance,
Best regards,
Karine

John Perry

unread,
Aug 17, 2018, 5:01:11 PM8/17/18
to rsnas-ctpmir...@googlegroups.com
Karine:
 
I don't have any NM images handy, so I ran a test on uncompressed CT images using the latest version of CTP from the RSNA site.
 
This is the configuration I used:
 
<Configuration>
    <Server
        maxThreads="20"
        port="9080"/>
    <Pipeline
        name="Test"
        root="test">
        <DicomImportService
            class="org.rsna.ctp.stdstages.DicomImportService"
            logConnections="no"
            name="DicomImportService"
            port="104"
            quarantine="quarantines/DicomImportService"
            root="roots/DicomImportService"/>
        <DicomPixelAnonymizer
            class="org.rsna.ctp.stdstages.DicomPixelAnonymizer"
            log="yes"
            name="DicomPixelAnonymizer"
            quarantine="quarantines/DicomPixelAnonymizer"
            root="roots/DicomPixelAnonymizer"
            script="scripts/DicomPixelAnonymizer.script"
            test="yes"/>
        <FileStorageService
            class="org.rsna.ctp.stdstages.FileStorageService"
            exportDirectory="/data/export"
            name="FileStorageService"
            port="9081"
            quarantine="quarantines/FileStorageService"
            requireAuthentication="yes"
            returnStoredFile="yes"
            root="roots/FileStorageService"/>
    </Pipeline>
</Configuration>
 
This was the DicomPixelAnonymizer script:
 
{ Modality.equals("CT") }
(64,96,128,256)
 
I put the script at the top of the standard script file to make sure that it would be the first possible match.
 
I sent an image to the DicomImportService and then viewed the result in the FileStorageService:
 
image
 
Note that the blanked region is white because I set the DicomPixelAnonymizer's test attribute to yes.
 
I also tested with a region that was larger than the image; it worked correctly.
 
You said that images were not moved to the root directory of the DicomPixelAnonymizer. That should not have happened. Images should ultimately appear in the FileStorageService's directory tree. You didn't send your config file, so I can't tell whether you specified a port for the FileStorageService, but I recommend that you do so, if only to make it easy to find the images.
 
If you can send me your image, I'll test with it here.
 
In any case, I recommend that you upgrade, just to be sure you and I are on the same code base.
 
JP
 
 
Sent: Friday, August 17, 2018 2:38 PM
--
You received this message because you are subscribed to the Google Groups "RSNA MIRC CTP/TFS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rsnas-ctpmirc-user...@googlegroups.com.
To post to this group, send email to rsnas-ctpmir...@googlegroups.com.
image[1].png

Karine Seymour

unread,
Aug 18, 2018, 4:33:37 AM8/18/18
to RSNA MIRC CTP/TFS User Group
Hi John,

Thanks for your help! I got it to work. 

What got me is that I ran my pipeline with different configurations several times over the same images, but did not delete the results in the FileStorageService directory. So when I displayed the results with the FileStorageService viewer, I kept viewing the results of my initial pipeline. Note that I had the "acceptDuplicateUIDs" option set to YES. Shouldn't it add instances of images/directories and add new results in the index of the FileStorageService stage?

Anyway, after I emptied my roots/FileStorageService directory, it worked.

Thanks!
Best,
Karine

John Perry

unread,
Aug 18, 2018, 9:15:32 AM8/18/18
to rsnas-ctpmir...@googlegroups.com
Karine:
 
The default value of the acceptDuplicateUIDs attribute is yes. If you send the same image twice, the FileStorageService will store both copies of the object:
 
image
 
The file names will be different, but the objects will be the same. In the test above, note that the two copies have the same SeriesNumber, AcquisitionNumber, and InstanceNumber.
 
The list is sorted by SeriesNumber, AcquisitionNumber, and InstanceNumber. The order that the duplicate copies appear in the list is the order in which they were stored, so to see the latest one, you must look at the last one in the list for the SeriesNumber, AcquisitionNumber, and InstanceNumber in question.
 
JP
 
Sent: Saturday, August 18, 2018 3:33 AM
Subject: [MIRC CTP/TFS User Group] Re: DicomPixelAnonymizer
 
image[1].png

Karine Seymour

unread,
Aug 20, 2018, 6:32:04 AM8/20/18
to rsnas-ctpmir...@googlegroups.com
Thanks John! It's perfectly clear now.

From: John Perry
Sent: Saturday, August 18, 2018 3:15 PM

Garanti sans virus. www.avast.com
image[1].png

Anna

unread,
Aug 21, 2018, 2:57:12 PM8/21/18
to RSNA MIRC CTP/TFS User Group
Hi John,

I am not sure why I do not see blanked out region anywhere on "NM" scan in my case. There are 6 files that placed in directory-import.  Below is both the script that I put on the top of DicomPixelAnonymizer.script and log:

SCREENCAPTURE
{ Modality.equals("NM") }
(60, 60, 500, 300)




<Pipeline name="Dicom Pixel Anonymizer Pipeline">
      
        <DirectoryImportService
            class="org.rsna.ctp.stdstages.DirectoryImportService"
            id="stage ID"
            import="roots/directory-import"
            name="DirectoryImportService"
            port="1104"
            quarantine="quarantines/directory-service"
            root="roots/directory-service"/>
      
        <DicomPixelAnonymizer
            class="org.rsna.ctp.stdstages.DicomPixelAnonymizer"
            id="stage ID"
            log="yes"
            name="DicomPixelAnonymizer"
            quarantine="quarantines/dicom-pixel-anonymizer"
            root="roots/dicompixel-service"
            script="scripts/DicomPixelAnonymizer.script"
            test="yes"/>
        <DicomAnonymizer
            class="org.rsna.ctp.stdstages.DicomAnonymizer"
            log="yes"
            name="DicomAnonymizer"
            quarantine="quarantines/dicom-anonymizer"
            root="roots/dicom-anonymizer"
            script="scripts/da.script"/>
        <FileStorageService
            class="org.rsna.ctp.stdstages.FileStorageService"
            log="yes"
            name="FileStorageService"
            quarantine="quarantines/storage-service"
            returnStoredFile="no"
            root="roots/storage-service"/>
  
    </Pipeline>
</Configuration>

11:46:56 INFO  [HttpServer] HttpServer started on port 1080 [maxThreads=4]
11:46:56 INFO  [FileStorageService] FileStorageService root: /Users/caidm05/JavaPrograms/CTP/roots/storage-service
11:47:17 INFO  [DicomPixelAnonymizer] DicomPixelAnonymizer: DicomObject 1.2.840.113619.2.170.1.2.0.31072018162813984.16517 matched:
 Modality.equals("NM") 
11:47:17 INFO  [DicomPixelAnonymizer] DicomPixelAnonymizer: DicomObject 1.2.840.113619.2.281.31108.160874834.1533069147.288437000 matched:
 Modality.equals("NM") 
11:47:17 INFO  [DicomPixelAnonymizer] DicomPixelAnonymizer: DicomObject 1.2.840.113619.2.170.1.2.0.31072018165959359.22755 matched:
 Modality.equals("NM") 
11:47:17 INFO  [DicomPixelAnonymizer] DicomPixelAnonymizer: DicomObject 1.2.840.113619.2.170.1.2.0.31072018170436171.23666 matched:
 Modality.equals("NM") 
11:47:17 INFO  [DicomPixelAnonymizer] DicomPixelAnonymizer: DicomObject 1.2.840.113619.2.170.1.2.0.31072018162813906.16514 matched:
 Modality.equals("NM") 
11:47:17 INFO  [DicomPixelAnonymizer] DicomPixelAnonymizer: DicomObject 1.2.840.113619.2.170.1.2.0.31072018165441078.21710 matched:
 Modality.equals("NM") 
To unsubscribe from this group and stop receiving emails from it, send an email to rsnas-ctpmirc-user-group+unsub...@googlegroups.com.
To post to this group, send email to rsnas-ctpmirc-user-group@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "RSNA MIRC CTP/TFS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rsnas-ctpmirc-user-group+unsub...@googlegroups.com.

John Perry

unread,
Aug 21, 2018, 3:07:32 PM8/21/18
to rsnas-ctpmir...@googlegroups.com
Anna:
 
If you can send me an image, I'll track it down.
 
JP
To unsubscribe from this group and stop receiving emails from it, send an email to rsnas-ctpmirc-user...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages