[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