Re: [Gdcm2] Reading DICOM file with DCMTK Private Media Storage Instance ( Re: Reading DICOM with private SOP class)

[Mathieu M. <mat...@gm...>]

Andrew,

On Thu, Mar 15, 2012 at 4:27 PM, Andrew Ward
<and...@gm...> wrote:
> On 15 March 2012 11:30, Mathieu Malaterre <mat...@gm...>
> wrote:
>>
>> [Change the subject a little]
>>
>> Hi Andrew,
>>
>>  Welcome to GDCM !
>>
>> On Wed, Mar 14, 2012 at 5:36 PM, Andrew Ward
>> <and...@gm...> wrote:
>> > I am using an external build of GDCM 2.2.0 with ITK4.1, when attempting
>> > to
>> > read a DICOM that contains a private SOP class of
>>
>> Congrats for living on the edge :)
>>
>> > "1.2.276.0.7230010.3.1.0.1" GDCM fails to read the image, however this
>> > used
>> > to work with the GDCM version built into ITK.
>>
>> So you are saying this used to -magically- work with ITK 3.x with
>> default GDCM 1.x shipped in, right ?
>
>
> Yes that's right.
>
>>
>>
>> Ok. To avoid any further misunderstanding, I have to split this into
>> two different requests:
>> 1. Does gdcm::ImageReader support private SOP classes ?
>> 2. Does gdcm::ImageReader support DCMTK default
>> "1.2.276.0.7230010.3.1.0.1" instance in file meta header ?
>>
>> 1) is easy. The short answer is: no. GDCM is a DICOM implementation
>> and does not support Private SOP Classes from vendor. This would be a
>> tremedous work without much value for GDCM.
>>
>> 2) is much much more difficult to answer.  "1.2.276.0.7230010.3.1.0.1"
>> is not really a defined Private SOP Class (hence my disctinction
>> above). This is the internal mecanism used by default in dcmtk when
>> generating DICOM file when no SOPClassUID (0008,0016) is found in the
>> DataSet.
>>
>> What this means is that could be writting out an RT Struct Image,
>> forget about SOPClassUID and produce this fake
>> "1.2.276.0.7230010.3.1.0.1" instance. Since GDCM by design fallback to
>> using a ACR-NEMA 1.0 when SOPClassUID is missing, this would be a very
>> dangerous thing to add to GDCM 2.x to support this
>> "1.2.276.0.7230010.3.1.0.1" feature.
>
>
> So are you saying that there is no way in GDCM 2.x to get the GDCM 1.x
> behaviour?

To make it clear. GDCM 1.x is an ACR-NEMA implementation. It does not
care about the type of instance it is reading. On the contrary GDCM
2.x is very strong about the SOP Class it is dealing with. This is one
of the very reason for GDCM 2.x existence: handling of Enhanced CT
Image Storage vs the old CT Image Storage. Those are very distinct
instance.
GDCM 1.x does not really have per se a defined behavior, other than
treating everything as ACR-NEMA.

>>
>>
>> Unless the behavior for 1.2.276.0.7230010.3.1.0.1 is clearly described
>> somewhere, I fear I will have to refuse any patch to adding support
>> for it in GDCM.
>>
>> > I have debugged through the GDCM code and when it does not recognise the
>> > SOP
>> > class it fails and there is no way to determine what the failure was
>> > from
>> > the return value of gdcm::ImageReader::Read.
>>
>> It should print a Warning much like the one you saw in the bug report,
>> right ?
>> In gdcm 2.2 warning and error should be usable from your application
>> (see gdcm::Trace API and std::[io]stream).
>>
>
> I was meaning, there is no exception thrown, or error code returned from
> ImageReader::Read,

Another GDCM 2.x design: no exception should be thrown from the public
API. This is to cope with language binding, where target language does
not support exception.

> that can be used in production code, but I will have a look at the trace
> api.

In GDCM 2.0.x warnings and errors used to be printed to std::cout, in
GDCM 2.2.x they are now printed to a user defined std::ostream& (cout
by default).

>>
>> > I have also noticed this
>> > comment in gdcmPixmapReader.cxx PixmapReader::Read:
>> >
>> > /* Does it really make sense to check for Media Storage SOP Class UID?
>> >    * I need then to check consistency with 0008 0016 Instance SOP Class
>> > UID
>> >    * ... I don't think there is an end.
>> >    * I'd rather go the old way check a bunch of tags (From Image Plane
>> >    * Module).
>> >    */
>> >
>> > I have also noticed this bug report:
>> >
>> > http://sourceforge.net/tracker/index.php?func=detail&aid=3043123&group_id=137895&atid=739590
>>
>> In short, GDCM supports:
>> 1. old ACR-NEMA 1.0 behavior: No SOP Class , no Media Storage SOP Class
>> 2. no Media Storage SOP Class but a SOP Class (some vendor still
>> deliver such hardware)
>> 3. Both SOP Class , and Media Storage SOP Class present
>>
>> You have a case where a DICOM implementation grafted a Private Media
>> Storage SOP Class. I would suggest you use dcmtk -F mode to writing
>> out DICOM file.
>>
>> > Should GDCM be capable of reading DICOM files that contain a private SOP
>> > class?
>>
>> Same as above. GDCM cannot implement SOP Class, this is really a
>> tremendous work.
>>
>> > Or should I be warning the end-user that the DICOM file is invalid? I
>> > have tried several DICOM viewers on this particular file and they all
>> > read
>> > the file without error.
>>
>> Then they are pretty bad DICOM viewers :)
>> They assume the DICOM you throw at them correspond to a CT Image
>> Storage or maybe an MR Image Storage instance. One way to test would
>> be to add Rescale Slope/Intercept and see it this affect the viewer.
>> Viewer for MR Image Storage should not take into account the Rescale
>> Slope/Intercept.
>> Those viewer could also interpret them as Secondary Capture, in this
>> case put an Imager Pixel Spacing to test
>>
>> Hoping to be clear,
>
>
> Yes that helps. Thanks you for your comments.

2cts
-- 
Mathieu