dcmpstat - Obtaining modality lut, DVPresentationState class

[chus]

Hello,

I'm working with presentation states. As stands in the DICOM standard, the first step in the grayscale pipeline tranformation is to apply the modality LUT.

I thought i could access to it with the DVPresentationState class, that is meant to deal with the presentation state files, but I don't find any method to get the modality LUT, but I can see there are protected members such modalityLUTData, modalityLUTExplanation, etc

How can I access to such information? Why there aren't no "get" methods to obtain that info? Shall I obtain that data using other classes?

[Marco Eichelberg]

class DVPresentationState always handles most of the grayscale transformation pipeline in the background. If there is a modality LUT encoded in the presentation state (or the image out of which a new presentation state is generated), then this LUT is automatically applied. This class also takes care of the VOI LUT, Presentation LUT, and, if needed, the GSDF transformation that maps P-values to display dependent DDLs. If you want to do this stuff by yourself, use lower-level classes such as DicomImage or DcmDataset.

[chus]

class DVPresentationState always handles most of the grayscale transformation pipeline in the background. If there is a modality LUT encoded in the presentation state (or the image out of which a new presentation state is generated), then this LUT is automatically applied.

But this happens when you attach a dicom image to the DVPresentationState object, am I right? if I am, It only applies the grayscale pipeline, or applies the shutter,annotations and spatial transforms too? What's the convenient way to get the transformed datasaet?

My situation right now is that I read the dicom datasets with itk libraries and then I visualize them with vtk. AFAIK itk reads only the dicom images, so then I have to apply the presentation state transformations with vtk by myself, so I need to get such info to apply to the image. dcmpstat library provides me the interface to get that information.
Maybe it would be easier to do all the reading stuff and presentation state pipeline with dcmtk and then visualize that final dataset with vtk, but it implies to make lots of changes in my code right now, even so, could be the approach I'll take in the future.

This class also takes care of the VOI LUT, Presentation LUT, and, if needed, the GSDF transformation that maps P-values to display dependent DDLs. If you want to do this stuff by yourself, use lower-level classes such as DicomImage or DcmDataset.

I supposed it was one solution, but I wanted to be sure if there were another alternatives.

Thanks for your answer

[Marco Eichelberg]

But this happens when you attach a dicom image to the DVPresentationState object, am I right?

Correct. It applies the grayscale pipeline and the spatial transformations (zooming, rotating, flipping). It does not apply the graphical annotations, including shutters. This class was developed as a support class for the DICOMscope viewer, and in this viewer the graphical annotations are implemented on the Java layer, not as part of the underlying DICOM library.

If you want to implement everything on your own, then class DVPresentationState will not be too helpful. The other classes that I mentioned might be helpful, though. Anyway, implementing the grayscale pipeline completely, correctly and efficiently is anything but trivial. If I was you, I would try to use a solution that works (such as the DicomImage class) instead of doing it on your own - just look at the complexity of module dcmimgle (which mostly implements the grayscale pipeline) and ask yourself if you really want to do that. I certainly would not

[chus]

It applies the grayscale pipeline and the spatial transformations (zooming, rotating, flipping).

Then, if it applies spatial transformations such as zooming to the resulting image, if I want to zoom out the image it would appear like it was cropped? I understand the image will mantain its dimensions (e.g. 512x512) and the zoomed zone will fit on that rectangle, or I am missing something?

Anyway, implementing the grayscale pipeline completely, correctly and efficiently is anything but trivial. If I was you, I would try to use a solution that works (such as the DicomImage class) instead of doing it on your own - just look at the complexity of module dcmimgle (which mostly implements the grayscale pipeline) and ask yourself if you really want to do that. I certainly would not

The fact is I'm using the visualization toolkit ( www.vtk.org ) to render the data and it gives me tools for handling LUT's, window levelling, rotations, masking, graphic annotations,etc, to apply to the image data and render it. So I think vtk can do the complex stuff for me. Maybe the fact I'm missing is that dcmtk probably can make a more accurate pipeline than vtk, I don't know.

My first idea was to obtain first all the information regarding the presentation state, and then give it properly to the rendering pipeline created with vtk. For example if dcmtk gives me an image with a window/level adjustment and then I want to change it, I'd have to change the window/level with some dcmtk object and generate the image again, because if i do it with vtk I would be applying the window/level to a window/levelled image but not to the original image and I think the result won't be the same. Or am I wrong? Have I missed something?

Thank you again for your help!

[Marco Eichelberg]

Then, if it applies spatial transformations such as zooming to the resulting image, if I want to zoom out the image it would appear like it was cropped? I understand the image will mantain its dimensions (e.g. 512x512) and the zoomed zone will fit on that rectangle, or I am missing something?

I had to look that up in the API -sorry, it is something like 7 years ago since I wrote that code. The code in class DVPresentationState does not do zooming/scaling, it only stores and manages the parameters for the displayed area. The scaling seems to have been implemented in the Java GUI of DICOMscope. The class does, however, implement rotate and flip.

Maybe the fact I'm missing is that dcmtk probably can make a more accurate pipeline than vtk, I don't know.

I've never use VTK for this purpose, maybe the pipeline implementation is OK, maybe not. Play with some unusual image formats (signed 13-bit CTs, for example) and see what happens. The IHE MESA tools contain a set of test images and GSPS objects for validating viewer behaviour.

vtk I would be applying the window/level to a window/levelled image but not to the original image and I think the result won't be the same.

In this case you would disable the VOI LUT transformation in DCMTK, access data in original "raw" format or possibly converted into something that is easier to handle such as unsigned 16-bit per pixel, and go on from there.