[Dcmlib] Re: some bugs with "MONOCHROM1 " and "MONOCHROM2 "
Mathieu Malaterre
mathieu.malaterre at kitware.com
Thu Nov 11 23:21:57 CET 2004
Dennis,
I am really suspicious. I only know one image that had odd lenght, and
it was an image written by an old gdcm version. Two options here:
- Can you send me the DICOM image (what are the right on the image,
license ?)
- If you are not allowed to send this image, please send me the output
of PrintHeader:
You have to execute:
$ ./bin/PrintHeader ~/Creatis/gdcmData/test.acr
Thanks
Mathieu
derong wrote:
> Hi, Mathieu
>
> It seems i have found a serious bug after i do some testing.
>
> In the file gdcmHeader.cxx, there are some codes as follows:
>
> // beware of trailing space at end of string
> // DICOM tags are never of odd length
> if ( strPhotometricInterpretation == GDCM_UNFOUND ||
> strPhotometricInterpretation == "MONOCHROME1 " ||
> strPhotometricInterpretation == "MONOCHROME2 " )
> {
> return 1;
> }
>
> there is a space added to the tail of "MONOCHROM1 " and "MONOCHROM2 ".
> I have read some file that there is no space added the tail, that will
> cause crash when we set component number to 3.
>
> I think that component number is important to read DICOM file, we can
> not just set it to 3 if we can not identify it.(it is dangerous to
> do memcpy)
>
> And we can compare the string value by following.
>
> std:string strPINoSpace(strPhotometricInterpretation, 0,
> strPhotometricInterpretation.find_first(' '));
>
> if ( strPhotometricInterpretation == GDCM_UNFOUND ||
> strPINoSpace == "MONOCHROME1" ||
> strPINoSpace == "MONOCHROME2" )
> {
> return 1;
> }
>
> I think that is more robust. maybe that dicom file violates the DICOM
> conformance."DICOM tags are never of odd length".
>
> How do you think about it?
>
> thx,
>
> Dennis
>
>
More information about the Dcmlib
mailing list