Reputation: 61
This is in continuation with my other question:
Which DICOM UIDs should be replaced while overwriting pixel data in DICOM?
I am trying to create a new DICOM file (instance) from an existing one, where I change the pixel data.
Form other question mentioned above, I understood what UIDs I need to change.
What other tags except UIDs should I change in order to get a valid DICOM while replacing the pixel data?
UPDATE:
In this case I am working with RT Dose IOD, unfortunately I cannot provide anonymized header but the documentation is describing the attributes.
Upvotes: 2
Views: 686
Reputation: 16815
There are a number of DICOM tags that depend on the pixel data. The most common ones are probably the following:
Depending on image dimensions:
Columns
/ Rows
- defines the X/Y dimensions of the imageFrame Number
- for multi-frame images, though there are more tags to be adapted depending on the SOP ClassPixel Spacing
, Imager Pixel Spacing
, or Pixel Aspect Ratio
- basically the tag that is already present in your imageData type related:
Bits Allocated
- usually 8 or 16, depending on the number of bytes per data pointBits Stored
- the real number of used bits, usually between 8 and 16High Bit
- Bits Stored
- 1Samples Per Pixel
- usually 3 for RGB and 1 for monochrome imagesPixel Representation
- 0 for unsigned, 1 for signed dataPhotometric Interpretation
- depends on the color model, usually RGB
for uncompressed color images, and Monochrome2
for b/w images; for compressed data, there is a number of possible values, and also some compression-related tags, but I assume that you are writing uncompressed dataYou may also adapt Image Type
to be something like DERIVED\SECONDARY\...
, and of course the UIDs that are mentioned in the other question.
There are more tags to be considered depending on your SOP Class, but these are probably the basic ones.
UPDATE: This is about generic image DICOM files, as originally, the SOP class has not been given. For more specific information about RT Dose images, check out the answer by @kritzel_sw.
Upvotes: 2
Reputation: 4013
Now after the OP was updated and reveals that we are talking about the RT dose object here, I would like to come up with some additions.
This type of "image" can come in very different flavors, it may even contain no pixel data at all.
In this IOD, the Image Pixel Module is "superposed" by the RT dose module coming with a big bunch of additional attribute describing the dose values as expressed by the pixel values. Depending on what kind of pixel data replacement you are performing, their values may all become invalid.
In addition to what MrBean Bremen already wrote about generic pixel description attributes, I would recommend that you take a look at the Image Plane Module which contains information about the image geometry and the relations of images in the same frame of reference (i.e. "3D information"). Not sure if the condition for this module ("...contains grid-based doses) applies to your pixel data, but I would for sure have a look into the attributes and verify if they can be kept with their previous values, have to be updated or should be removed.
Also, look at the Frame Of Reference Module, especially the Frame Of Reference UID (0020,0052) - change it if you are not abolutely sure that the coordinates you are giving in the Image Plane Module attibutes refer to the same coordinate system as the in image that you are modifying.
Finally, an opinion-based advice: I (and probably the other posters) were assuming that you are dealing with an "ordinary image", but an RT dose object is a different beast. In terms of correctness, I think it would be easier to achieve by writing the whole object from scratch - the complexity of the matter which is fully reflected in the complexity of the Information Object Definiton makes it easy to overlook something. And the impact of wrongly encoded information on the patient is quite high in the field where these objects are used.
Upvotes: 2