Issues with DICOM image quality after burnt-in text redaction

17 views
Skip to first unread message

Ezequiel Gioia

unread,
Aug 26, 2025, 2:34:25 PMAug 26
to GCP Healthcare Discuss

Hi everyone,

I'm working on a project using the Cloud Healthcare API and am running into some challenges with the de-identification functionality for DICOM data. Specifically, I'm trying to de-identify a DICOM burnt-in text redaction, but I'm finding that the quality of the de-identified images decreases significantly.

The configuration I'm using for the de-identify job is to DEIDENTIFY_TAG_CONTENTS and REDACT_SENSITIVE_TEXT.

Has anyone encountered a similar problem or can offer some insight into what might be misconfigured in my request? Any advice on how to improve the quality of the de-identified image would also be greatly appreciated.

Thank you, 
Ezequiel

Truc Le

unread,
Aug 26, 2025, 2:39:00 PMAug 26
to GCP Healthcare Discuss
Hello Ezequiel,

Could you please provide the transfer syntax of the source DICOM instance?

If you have a sample file without PHI, you can open a support ticket and attach it here: https://cloud.google.com/support/docs/issue-trackers

Thanks,
Truc

Ezequiel Gioia

unread,
Aug 26, 2025, 3:36:30 PMAug 26
to GCP Healthcare Discuss
This is what I found on the original image. Thanks. 

>dcmdump IMG00002.dcm

# Dicom-File-Format

# Dicom-Meta-Information-Header
# Used TransferSyntax: Little Endian Explicit
...
(0002,0010) UI =JPEG2000LosslessOnly                    #  22, 1 TransferSyntaxUID
...

Truc Le

unread,
Aug 26, 2025, 4:32:47 PMAug 26
to GCP Healthcare Discuss
Thanks for the details.

You've correctly identified the issue: we have limited support for JPEG Lossless encoding, which is causing the quality degradation.

We are working a fix to enhance our transfer syntax capabilities, which is targeted for release by the end of this year.

Thanks,
Truc

Ezequiel Gioia

unread,
Aug 26, 2025, 5:20:01 PMAug 26
to GCP Healthcare Discuss
Thank you, Truc, for your prompt response. I had some bad luck too—the first image I tested happened to be JPEG Lossless encoded. It works well with the other encodings. Also, I found the following  in the documentation that looks related to what you mentioned:

     " Warning: The default transfer-syntax for image/jpeg (JPEG Lossless, 1.2.840.10008.1.2.4.70) is not supported, so if image/jpeg is requested without specifying a transfer syntax, an error will be returned."
Reply all
Reply to author
Forward
0 new messages