DICOM @ OFFIS

Hi OFFIS team,

I am not sure if these are DicomScope or general GSPS issues.

I am currently validating my self-created GSPS objects with DicomScope and found some unclear behaviour which you hopefully could clarify:

1. I have a GSPS file containing a ReferencedSeriesSequence with a single item containing a specific SeriesInstanceUID and a Softcopy VOI LUT sequence containing a single item with WindowWidth and WindowCenter values but WITHOUT a ReferencedImageSequence. Afaik these values should be applied to all images of the specified series. When I load an image of a different series of the same study into DicomScope and load the above GSPS, then DicomScope applies this value anyway (but ignores the RescaleSlope and RescaleIntercept values specified in the GSPS and the image). Shouldn't it ignore the GSPS at all since the SeriesInstanceUID was not specified?

2. Why does DicomScope use RescaleSlope and RescaleIntercept values of 1 resp. 0 if theses attributes are not available in the GSPS and ignores the original values in the image header? There are for instance some older Siemens scaners that produce CT series with inhomogenious RescaleIntercept values. This would force an application to produce a GSPS for every single image since RescaleSlope and Intercept only apply to the General Relationship Module.

3. If I specify a certain anchor point for an unformated text then DicomScope will allways display this text with a certain distance from the anchor point. With "Anchor point visible" it will draw a connection line. Why doesn't it simply draw the text starting at the specified anchor point? My intention is to display measurement values of e.g. distance or angle measurments (without a visible bounding box) in a clearly specified region of the image (e.g in a region outside the area of interest for the reading physician). Is this possible with GSPS?

Thank's for your help,

Regards,
Andreas

I would say that this is a case of undefined behaviour. You should never apply a GSPS to an image for which it is not applicable. If you do, strange things may happen, as in this case. In our DICOMscope application, the GUI will not permit you to apply a GSPS to a "wrong" image (e.g. from a wrong series), so this case never happens. Well possible that the C++ code from module dcmpstat "underneath" this implementation is not protected from this case. Instead of partially applying the GSPS it should probably just return an error code and refuse to do anything.

Because this is required behaviour of a GSPS. See DICOM Part 4, N.2.2: If the Modality LUT is not present in the Presentation State it shall be assumed to be an identity transformation.

The way text is rendered with GSPS leaves much implementation choice. My interpretation is that the bounding box (if present) describes the location where the text should be painted, while the anchor point describes the location in the image that is annotated by the text. Note that a bounding box is never "visible" - it is just a rectangle that provides a (rough) guidance to the viewer where to put the text. When there is no bounding box, the application has to place the text somewhere. Putting it exactly at the anchor point is a stupid idea because then the text will most likely hide the image feature you want to describe with the text. So as a very simple (and certainly not perfect) solution, we just render the text with some offset to the anchor point. If anchor point is visible, we draw a line (also that is implementation choice, there are no precise rules how an anchor point should be represented), if anchor point is invisible, then the rendering is probably very difficult to explain. If you want to have your text rendered in a specific "safe" region of the image, use a bounding box and hope for the best

Thank you very much for your answers!



Are you sure? I was actually talking about the DicomScope behaviour. When I load an image from filesystem (not from database) and then load a PR file from filesystem that actually "belongs" to a different series of the same study, DicomScope changes W/L values nevertheless (everything else will be ignored, including VOI LUT function).


Thank's, I will try that and see what happens

Regards,
Andreas

In that case: congratulations, you have discovered a new bug

I don't think that this is a bug. In my opinion, it's a feature

Images and GSPS objects are usually loaded from the study browser that represents the content of the local "database". But if the GSPS object is loaded from file, you can apply any GSPS object to an image. As far as I remember, this was mainly intended for testing purposes ... however, this doesn't seem to work 100% correct.