DICOM @ OFFIS

Hi!

I found:

Some of length of tags defined by the dcmtk are different the length defined dicom standard,


the dcmtk:
#define AE_MAX_LENGTH 128 /* Application Entity */
#define AS_MAX_LENGTH 32 /* Age String */#define AT_MAX_LENGTH 32 /* Attribute Tag */
#define CS_MAX_LENGTH 128 /* Code String */
#define DA_MAX_LENGTH 80 /* Date */
#define DS_MAX_LENGTH 128 /* Decimal String */
#define DT_MAX_LENGTH 208 /* Date Time */
#define FL_MAX_LENGTH 32 /* FLoating point single */
#define FD_MAX_LENGTH 64 /* Floating point Double */
#define IS_MAX_LENGTH 96 /* Integer String */
#define LO_MAX_LENGTH 64 /* Long String */
#define LT_MAX_LENGTH 10240 /* Long Text */
#define PN_MAX_LENGTH 64 /* Person Name */
#define SH_MAX_LENGTH 16 /* Short String */
#define SL_MAX_LENGTH 32 /* Signed Long */
#define SS_MAX_LENGTH 16 /* Signed Short */
#define ST_MAX_LENGTH 1024 /* Short Text */
#define TM_MAX_LENGTH 128 /* Time */
#define UI_MAX_LENGTH 64 /* Unique Identifier */
#define UL_MAX_LENGTH 32 /* Unsigned Long */
#define US_MAX_LENGTH 16 /* Unsigned Short */

struct IdxRecord
{
/// default constructor
IdxRecord();

char filename [DBC_MAXSTRING+1] ;
char SOPClassUID [UI_MAX_LENGTH+1] ;
double RecordedDate ;
int ImageSize ;

DB_SmallDcmElmt param [NBPARAMETERS] ;

char PatientsBirthDate [DA_MAX_LENGTH+1] ;
char PatientsSex [CS_MAX_LENGTH+1] ;
char PatientsName [PN_MAX_LENGTH+1] ;
char PatientID [LO_MAX_LENGTH+1] ;
char PatientsBirthTime [TM_MAX_LENGTH+1] ;
char OtherPatientIDs [LO_MAX_LENGTH+1] ;
char OtherPatientNames [PN_MAX_LENGTH+1] ;
char EthnicGroup [SH_MAX_LENGTH+1] ;
char NumberofPatientRelatedStudies [IS_MAX_LENGTH+1] ;
char NumberofPatientRelatedSeries [IS_MAX_LENGTH+1] ;
char NumberofPatientRelatedInstances [IS_MAX_LENGTH+1] ;

char StudyDate [DA_MAX_LENGTH+1] ;
char StudyTime [TM_MAX_LENGTH+1] ;
char StudyID [CS_MAX_LENGTH+1] ;
char StudyDescription [LO_MAX_LENGTH+1] ;
char NameOfPhysiciansReadingStudy [PN_MAX_LENGTH+1] ;

char AccessionNumber [CS_MAX_LENGTH+1] ;
char ReferringPhysiciansName [PN_MAX_LENGTH+1] ;
char ProcedureDescription [LO_MAX_LENGTH+1] ;
char AttendingPhysiciansName [PN_MAX_LENGTH+1] ;
char StudyInstanceUID [UI_MAX_LENGTH+1] ;
char OtherStudyNumbers [IS_MAX_LENGTH+1] ;
char AdmittingDiagnosesDescription [LO_MAX_LENGTH+1] ;
char PatientsAge [AS_MAX_LENGTH+1] ;
char PatientsSize [DS_MAX_LENGTH+1] ;
char PatientsWeight [DS_MAX_LENGTH+1] ;
char Occupation [SH_MAX_LENGTH+1] ;
char NumberofStudyRelatedSeries [IS_MAX_LENGTH+1] ;
char NumberofStudyRelatedInstances [IS_MAX_LENGTH+1] ;

char SeriesNumber [IS_MAX_LENGTH+1] ;
char SeriesInstanceUID [UI_MAX_LENGTH+1] ;
char Modality [CS_MAX_LENGTH+1] ;

char ImageNumber [IS_MAX_LENGTH+1] ;
char SOPInstanceUID [UI_MAX_LENGTH+1] ;

char SeriesDate [DA_MAX_LENGTH+1] ;
char SeriesTime [TM_MAX_LENGTH+1] ;
char SeriesDescription [LO_MAX_LENGTH+1] ;
char ProtocolName [LO_MAX_LENGTH+1] ;
char OperatorsName [PN_MAX_LENGTH+1] ;
char PerformingPhysiciansName [PN_MAX_LENGTH+1] ;
char PresentationLabel [CS_LABEL_MAX_LENGTH+1] ;

DVIFhierarchyStatus hstat;

// Not related to any particular DICOM attribute !
char InstanceDescription [DESCRIPTION_MAX_LENGTH+1] ;

private:
/* undefined */ IdxRecord(const IdxRecord& copy);
/* undefined */ IdxRecord& operator=(const IdxRecord& copy);
};


the dicom:

VR : Age String Length of Value : 4 bytes

VR : Date Length of Value : 8 bytes

why ?
How the dcmtk to calculate length of value of VR ?

Hey,



Without looking into the code, I would tend to say DCMTK talks about bits and not bytes for those two VRs:

• Age String: 4 bytes = 32 Bits
• Date: 8 Bytes = 64 Bits. However, there is the deprecated date format from ACR/NEMA that DICOM should be able to cope with. That format adds dots between the components, i.e. 1977.12.24 which adds just two characters = two bytes = 16 Bit more, i.e. 64 + 16 = 80 Bits in total.

Sounds reasonable to me!

Best regards,
Michael

Well, sounded reasonable But after actually looking into the code and since this is from the PACS server module dcmqrdb, I tend for another interpretation which is also commented in the header file you pointed out:



So some fields may be requested with a VM greater than one. Someone back in 1993 or so went through the standard and looked at the maximum VM that could be encountered and that seemed to end up in the values you found, i.e. for Age String there seem to be a maximum of 8 (8*4=32) and for Date a maximum of 10 (10*8 = 80). The latter being not that nice because it will not cope with the old date "dot" format, but that should be very uncommon in a q/r-request anyway.

Best regards,
Michael

The above mentioned length definitions are to be used for the "index.dat" file only. So, please don't use them for anything else!


What do you mean by that?

Hi! Jörg Riesmeier

I mean :

Without looking into the code, I would tend to say DCMTK talks about bits and not bytes for those two VRs:



Age String: 4 bytes = 32 Bits

Date: 8 Bytes = 64 Bits. However, there is the deprecated date format from ACR/NEMA that DICOM should be able to cope with. That format adds dots between the components, i.e. 1977.12.24 which adds just two characters = two bytes = 16 Bit more, i.e. 64 + 16 = 80 Bits in total.

Thank for reply!

Dear Michael Onken

I get

I think this problem a long time!

Thank you very much!