DICOM Print

Questions regarding the DCMPRINT library, a DCMTK add-on that implements a DICOM Print Management SCP and SCU

Moderator: Moderator Team

Post Reply
Message
Author
vijaya
Posts: 4
Joined: Thu, 2007-12-20, 04:47

DICOM Print

#1 Post by vijaya » Wed, 2008-01-16, 05:22

The requirement is that the SCP should only print the DICOM image information and not the image header information. All the header details such as patient name, patient ID, Acquisition details are all hardcoded in the image pixel. Hence there is no need to print the DICOM header. There are three queries based on this requirement:

1. Do majority of DICOM printers have the facility to print only the image buffer and not the header information?

2. Does this violate the DICOM compliance in any manner?

3. How do we indicate to the SCP that he has to print only the DICOM image buffer and not the header?
Vijaya

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1225
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#2 Post by Marco Eichelberg » Wed, 2008-01-16, 14:01

Do majority of DICOM printers have the facility to print only the image buffer and not the header information?
Since DICOM "header information" is never sent to the printer (the DICOM Print Management Service Class protocol only transmits "naked" pixel data), there is absolutely no way the printer could ever print a "header".
Does this violate the DICOM compliance in any manner?
No, only the laws of physics :wink:
How do we indicate to the SCP that he has to print only the DICOM image buffer and not the header?
You don't. There is nothing else the printer could do.

vijaya
Posts: 4
Joined: Thu, 2007-12-20, 04:47

DICOM Print

#3 Post by vijaya » Thu, 2008-01-17, 05:01

Thanks very much for your inputs.

I have one more query regarding your response. My general understanding is that image information is always defined in terms of image header and image pixel information.
If DICOM header information is never sent to the SCP Printer, then, how else does the SCU normally communicate the header details to SCP such that it gets printed in a DICOM Image?

Please clarify.
Vijaya

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1225
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#4 Post by Marco Eichelberg » Thu, 2008-01-17, 09:25

You have to understand that in DICOM there is no such thing as a "header". Many of the proprietary file formats used by vendors before DICOM was generally accepted consisted of two parts - a header containing all the descriptive information like patient name, rows and columns of the image etc., and a body containing the raw pixel data. In DICOM, an image is a list of data elements identified by attribute tags, and one of the entries in that list contains the raw pixel data. This is usually, but not always, the last element in the list. When people refer to the "DICOM header", they usually mean "all elements from the list except the last one". Now DICOM is much more than a file format - there are also specifications for various client/server network services. All of these services use messages in which DICOM datasets (lists of elements) are exchanged, but the elements that may be present in these datasets of course vary from service to service. While the service that is used to transfer images to an image archive or back to a workstation (the Storage Service Class) transports a dataset that is largely identical to the contents of a DICOM image file and contains data about the patient, the study, the generating equipment and the image, the DICOM Print Management Service Class uses different messages. Here only pixel data and a few descriptive elements for color model, rows, columns, the position of the image on the page etc. are sent, but no patient name, no birthdate, no study, no generating equipment etc. Also in DICOM print, the image must be sent in a pre-formatted manner, while original DICOM images usually require some formatting (application of Window Level and Width) by the display application. That means it is the task of the print client to take a DICOM image, apply grayscale transformations if needed to create a pre-formatted bitmap, "burn" textual annotations into the bitmap if wanted by the user, and then use the DICOM print network protocol to send the result to the print server. The print server is rather stupid - it just receives bitmaps and some layout information and uses that to produce a hardcopy.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest