Magneric Resonance Imaging, Vol. I I, pp. 857-864, 1993 Printed in the USA. All rights reserved.

0730-725X/93 $6.00 + .oO Copyright 0 I993 Pergamon Press Ltd.

l Original Contribution

VI. A SOFTWARE PROGRAM FOR EXCHANGING MR DATA

P.B. RING, J.A. JENSEN, AND 0. HENRIKSEN

Department of Magnetic Resonance, Hvidovre Hospital, Copenhagen, Denmark

In an MR multicenter project, data exchange is a problem because most MR scanners do not use the same data format or have data export facilities. In the COMAC-BME Concerted Action on Tissue Characterization by MRS and MRI, a subgroup of seven MR centers had a need for data exchange in the form of digital MR images of the human brain. Because there was no common data format, a software package was developed for data exchange. This article describes the basic features of the developed software. The software package was written in the lan- guage of C and was successfully tested on an IBM-6150 UNIX workstation. The software is currently being tested on the following series of UNIX workstations: SUN SPARC, IBM RS6000, and HP 9OOW700.

Keywords: Data exchange; MRI; Software.

INTRODUCTION

In the COMAC-BME project on Tissue Characteriza- tion by MRS and MRI, a subgroup of seven MR cen- ters from five countries in Europe cooperated in tissue characterization of MR images of the brain. A total of nine MR scanners supplied data to the project. The nine MR scanners ranged from 0.28 T to 1.5 T, in seven dif- ferent models and in four different manufacturers. As two MR scanners of the same model supplied data in different data formats, only two MR scanners in the project used the same data format. Two manufacturers had export facilities for their newest MR scanners be- ing the National Electrical Manufacturers Association (NEMA) standard.’ The first manufacturer did not supply some important information (for this project at least) in the exported data format, and the second man- ufacturer had solved the problem by adding a shadow header close to the original MR-header. The conclu- sion we made based on these facts was that some con- version software had to be written if data exchange between centers could succeed.

In the design of a conversion software package, an important choice is what data format should be used as output. Formats like the NEMA-standard or the TIFF format2 could be a choice. At this stage we rec- ognized that in future projects, objects other than im- ages (e.g., MR spectra) could be requested for exchange. As the above mentioned formats are image-oriented and not object-oriented, we chose to use our own data

format, which is object-oriented. In our format, a file is defined as a collection of objects. At the moment, three types of objects have been implemented: The image-, the region- and the set object. The image object provides storage for a single image (including header information), the region object provides storage for re- gions of interests (ROIs), and the set object groups ob- jects together so a file can contain several objects. The chosen data format is called The EC-Flexible Data Format.

THE EC-FLEXIBLE DATA FORMAT

The EC-Flexible Data Format is divided into two parts. The first part is the header, which describes what kind of objects are stored in the file and attributes at- tached to the objects. Only printable ASCII characters are allowed in the header. The second part of the file is the data part, where binary data (e.g., pixel values of an image) will be stored. The concept of dividing of a file into a header part and a data part is used by most MR manufacturers in their file format, what differs is our organization of the header part.

The header part is described by grammar listed in Appendix A. The grammatical structure allows objects to be stored together in a single file in different arrange- ments. Each object has attached a dynamic blackboard where the attributes of the object are stored. A dynamic blackboard contains a variable number of blackboard entries. Each blackboard entry is made of an identifier and the corresponding value(s). By defining attributes

RECEIVED l/6/93; ACCEPTED l/6/93. Center of Magnetic Resonance, Hvidovre Hospital, DK-2650 Address correspondence to Poul Ring, Danish Research Copenhagen, Denmark.

857

858 Magnetic Resonance lmaging 0 Volume 11, Number 6, 1993

of objects in a dynamic blackboard, objects can be given new attributes if needed later in the process, with- out a need to change running programs not knowing the newly defined attributes. This is not the case for conventional header formats with fixed entries. In ad- dition, new objects can be defined without changing old programs, as long as existing programs ignore and pass unknown objects.

Qualifiers in blackboards need not be known by a program, but a qualifier must be defined in the soft- ware for the program to be able to access or store a blackboard entry. A list of defined blackboard entries and type of their values is given in Appendix B. For a given object, some entries are mandatory while others are optional.

To illustrate the header format, a simplified exam- ple of a set of two spin-echo images stored in a file is shown:

The first line is the identification of the format; a program can then test if a given file is written in The EC-Flexible Data Format. The last line of the header aligns with this line and includes an ending brace. The second line gives the version number of the header. The third line tells at what date and time the file was created. The fourth line identifies a set object.

Inside the set, two data-objects are found. Both data-objects are images (Data-Class) of 256 * 256 pixels (Data_Xsize and Data_Ysize) with each pixel represented by a 16 bit signed integer (2 bytes).

The entry #-Data-Length tells how many bytes in the data part of the file that the current object occu- pies. Data in the data part of the file are stored in the same succession as found in the header. The first byte in the data part of the file is located immediately after the terminating token #_EndOfHeader. in the header.

#_EC_Flexible_data_Header (

#-Version 2.1.0

#_Date_of_Creation 1991.09.15 13.25.01 #-Data-set {

#-Data-Object {

#-Data-Length : 32768; Acquisition_SiteId : "Hvidovre Hospital";

Acquisition_Modality : “MR”; Data-Class : 'lImageft;

Data-Type : "Integer 16 bit"; Data_Xsize : 256;

Data_Ysize : 256; MR-Echoes-Total : 2; MR_Echo_Number : 1;

MR_TE_(sec) : 0.030; MR_TR_(sec) : 1.5; Patient-Name : "Jane Doe". , Patient-Age : 38;

1 #-Data-Object {

#-Data-Length

Acquisition_SiteId

Acquisition-Modality

Data-Class

Data-Type

Data_Xsize

Data_Ysize

MR_Echoes_Total

MR_Echo_Number

MR_TE_(sec)

MR_TR_(sec)

Patient-Name

Patient-Age

: 32768;

: "Hvidovre Hospital";

. “MR”; : "Image"; : "Integer 16 bit"; : 256;

: 256; : 2; : 2; : 0.090; : 1.5; : "Jane Doe". , : 38;

]#_kdOfHeader.

Software program for exchanging MR data0 P.B. RINCETAL. 859

THE EUROSPIN DATA CONVERSION PROGRAM

The EUROSPIN Conversion Program converts dif- ferent image data formats from various MR scanners to The EC-Flexible Data Format. The program is partly based on work by Ladon. The conversion program reads a given file format on the basis of a formal de- scription. This description is expressed grammatically and placed in an ASCII file called a stanza file. Each subsection (a stanza) describes a header entry in plain ASCII text. Each stanza is structured in the same manner as the blackboard of objects found in The EC-Flexible Data Format. To illustrate the way this concept works we will show some examples.

Example 1

ImageConversionStanza (

ObjectDataClass {

Qualifier : "Data_Class";

Type : "cnst_t"; Format : "string_t"; Value : "Image";

>

Ob

>

ectDataType {

Qualifier : "Data-Type";

Type : "cnst_t"; Format : "string_t"; Value : "FloatingPointReal 32 Bit";

HorizontalSize (

Qualifier : "Data_Xsize";

Type : "data_t"; Format : "int32_t"; Order : “Vax”. , Address : 0;

VerticalSize {

Qualifier : "Data_Ysize". >

Type : "data_t". Format : "int32_t:; Order : “Vax”.

Address :4j ’

3

PixelField (

Type : "data_t"* , Order : “Vax”. , Format : "int32_t"; Address : 8;

PixelAddress (

Type : "pixel_tp"; Order : "Vax"; Format : "rea132_t"; Address : PixelField;

>

1;

Given an image created on a VAX computer, the im- age has a header part followed by a data part. The first 12 bytes in the header are three 32-bit integers repre- senting, respectively, the horizontal image size, the ver- tical image size, and finally the byte address of pixel data relative to the start of the file. The pixel values in the image are known to be in floating point values (32- bit VAX format). A stanza file could be as in the ex- ample above.

The conversion program will perform the following steps during a conversion. In the first step it will make a list of all stanzas in the stanza file that have an entry with the qualifier of the name Qualifier. From this list the blackboard of the output-object is generated. The first two stanzas are of type cnst_t (a constant) and will generate an image in 32-bit floating point format. The horizontal size is of type data-t, which means in- formation is to be read from the header of the input- file. A stanza of this type needs three qualifiers in order to be defined-Order, Type, and Address. Address is the absolute byte address in the input file. Order will tell about the byte organization of the computer that gen- erated the input-file. Format tells if data in the header is of integer, floating point or a text string format.

The next step performed by the conversion program is to look for data to be stored in the data part of the output file. As the object has the data class of an im- age, the program will look for a stanza where the qual- ifier Type has the value “pixel_tp” (pixel pointer). In the stanza with the name PixelAddress, the entries Type and Order refer to attributes of pixel data. The quali- fier Address tells where the first byte of the first pixel is found. Up to now, values of qualifiers have been con- stants, but all values attached to qualifiers are expres- sions written close to C-syntax and all stanzas in the stanza file are functions. In Example 1, the program will look at the stanza PixelField when looking for the pixel address. The stanza PixelField will generate an in- teger value by converting a 32-bit integer located at the 8th byte in the input-file. The value generated by the statement PixelField is the address of the first byte of the first pixel in the input-file.

Example 2

EchoTime (

Qualifier : "MR Tel'* - f

‘Me : lldata_t"' ,

860 Magnetic Resonance Imaging0 Volume 11. Number 6, 1993

Format : "rea132_t"; nema(0x0028,0x0011). This function will generate a Order : "Vaxl'; scan of the NEMA file and locate the value address of Address : 2345; the given parameter identified by group- and element ReturnValue : myself / 1000; number,

Often, values in the input-header are written in other units than is required in the output-header, for exam- ple, a value of the echo time in milliseconds in the in- put-header and the requirement to convert to seconds in the output-file. A stanza that handles this problem is shown in Example 2. The qualifier ReturnValue al- lows calculation to be done on a retrieved parameter from the header. If the qualifier ReturnValue is not present in a stanza, it is identical to writing the entry : ReturnValue : myself; .

Example 3

HorizontalSize {

Qualifier

Type Format

Order

Address

"Data_Xsize"* , "data_t".

"intlb_t:;

"Intel"*

nema(0x~028,0x0011);

Example 3 shows how to retrieve data from a file written in the NEMA standard. Attributes of images are in the NEMA standard identified by a group- and an element number. By searching in the NEMA file with a given group- and element number, one can find the address of where the information is stored in the NEMA file. The group- and element numbers for the horizontal image size in the NEMA standard are, re- spectively, 28 and 11 in hexadecimal notation. Exam- ple 3 will retrieve the horizontal image size. The value of the entry with the qualifier Address is the function

The examples above show the general principles of how the conversion program is controlled by stanzas. Appendix B lists some qualifiers, their significance, and some typical values.

The concept of making a conversion program con- trolled by a stanza file is much more flexible than hard- coding a conversion program. By this concept, one can make new stanza files when new data formats are re- quired to be converted without changing the program. The stanza file also gives a clear definition of the con- version process compared to a hardcoded program. The price is a slower program, because the stanza files are interpreted, but the price is worth paying.

CONCLUSION

Addressing the problem of data exchange between MR centers in a multicenter project, we made the nec- essary definitions and tools for transfering images and also prepared exchange of other types of data if re- quired in the future. We defined a data format, The EC-Flexible Data Format, which is an object-oriented way of describing data. We implemented a conversion program controlled by stanzas in ASCII files. By just writing a new stanza file we can import a new file for- mat if required. The stanza files also give a clear defi- nition of a given data format. Some special data formats may, however, give us problems, for example, a data format with the image header in one file and pixelvalues in another file. This is a problem because the existing software expects both header data and pixelvalues to be stored in one file. The way to solve these kind of problems is to extend the library of conversion pro- grams and add new functions making them usable from the stanzas.

APPENDIX A: SYNTAX FOR THE EC-FLEXIBLE DATA FORMAT

Terminal symbols are marked as Terminal symbols

Header -> HeaderId HeaderInfo HeaderData

EndOfHeader

HeaderId -> #_EC_Flexible_Data_Header

HeaderInfo -> HeaderVersion HeaderDate

HeaderVersion -> HeaderVersionId HeaderVersionNo

HeaderVersionID -> #-Version

HeaderVersionNo -> Unsigned Dot Unsigned Dot Unsigned

HeaderDate -> HeaderCreationTime HeaderTime

HeaderTime

HeaderCreationTime -> #_Date_of_Creation

Software program for exchanging MR data 0 P.B. RING ET AL. 861

HeaderTime

HeaderData

DataSet

DataSetList

DataObject

ObjectData

-> Unsigned Dot Unsigned Dot Unsigned

-> DataObject 1 DataSet -> #-Data-Set { DataSetList } -> DataSetList DataSet 1 DataSet (

DataSetList DataObject 1 DataObject -> #-Data-Object ( ObjectData )

-> ObjectDataLength ObjectInformation

ObjectSubset ( ObjectDataLength ObjectInformation

ObjectDataLength -> #_DataLength : Integer ; ObjectInformation -> #-Blackboard { BlackboardList }

BlackboardList -> BlackboardList BlackboardEntry 1 BlackboardEntry

BlackboardEntry -> BlackboardQualifier : BlackboardValues ;

BlackboardQualifier -> QualifierString

BlackboardValues -> BlackboardValues BlackboardValue 1 BlackboardValue

BlackboardValue -> Stringvalue / Boolean 1 Integer 1 RealNumber ( ComplexNumber

Boolean -> True 1 False

The following symbols are described in LEX-notation4:

QualifierString (letter}((splchars)~{digit)((letter))n

StringValue {quo}((sp2chars))(digit}{letter)l(space})*{quo~

Integer ((sign))?{digit)+

Unsigned {digit)+

RealNumber {sign)?(digit)+\.{digit)+([Ee][+\-](digitj+)?

ComplexNumber \((real)\;(real)\)

quo \"

space 1 1 letter [A-Za-z]

digit co-91 sign [+\-I splchars [-\(\)\[\I1 sp2chars [\!\#-\)I

APPENDIX B: SOME QUALIFIERS AND THEIR VALUES

Group : Acquisition

Name

Acquisition-Date Acquisition-Modality Acquisition_SiteID Acquisition-Time

Type

String String String String

Significance

Date of object creation MR, CT, etc. Name of site producing the object Time of object creation

Group : Data

Name

Data-Class Data-Type Data_Xsize Data_Ysize Data_Zsize

Type

String String Integer Integer Integer

Significance

Class of current object (e.g. “Image”) Type of current object (e.g. “Integer 16 bit”) Primary size of an object Secondary size of an object Tertiary size of an object

862 Magnetic Resonance Imaging 0 Volume 1 I, Number 6, 1993

Group : MR

Name

MR_Echo_Number MR_Echoes_Total MR_SliceOrientation MR_SlicePosition MR_PulseSequence MR_Te_(s) MR_Ti_(s) MR_Tr_(s)

Type

Integer Integer Real Real String Real Real Real

Significance

Echo-number Total of number of echoes Slice orientation vector Slice position vector Name of pulsequence Echo time in seconds Inversion time in seconds Repitition time in seconds

Group : Patient

Name Type Significance

Patient-name Patient-Age

Qualifier : Qualifier Value : Textstring

String Integer

Name of patient Age of patient

Qualifier : Type Value : Textstring

Value Significance

cnst_t A value taken from the stanza data_ t A value taken from the header of input-file pixel_tp A pointer to pixeldata image-operation Make processing on image data

Qualifier : Format Value : Textstring

Value Significance

int8_t Integer unsigned of 8 bit intl6_t Integer signed of 16 bit int32_t Integer signed of 32 bit real32_t Real number of 32 bit rea164_t Real number of 64 bit string-t Textstring alphanumeric-t Number stored as a textstring

Qualifier : Order Value : Textstring

Value Significance

Vax Intel Motorola

Data from a VAX computer Data from an Intal based computer Data from a Motorola based computer

Qualifier : Length Value : Integer

This qualifier is used when retrieving a textstring that is not null terminated but have a known length in the header.

Software program for exchanging MR data 0 P.B. RING ET AL. 863

APPENDIX C: SYNTAX FOR CONVERTER STANZAS

Terminal symbols are marked as Terminal symbols

Stanza -> Qualifier { StanzaRecords );

StanzaRecords -> StanzaRecords StanzaRecord ( StanzaRecord

StanzaRecord -> Qualifier ( StanzaLines >

StanzaLines -> StanzaLines StanzaLine 1 StanzaLine

StanzaLine -> Qualifier : Expression ; Expression -> Expression 11 Expr_l (

Expression && Expr-1 1

Expr-1

Expr-2

Expr-3

Expr-4

Expr-5

-> Expr-1 > Expr_2

Expr-1 >= Expr-2

Expr_1 < Expr-2

Expr-1 <= Expr_2

Expr-1 == Expr_2

Expr-1 != Expr_2

Expr-2

-> Expr_2 + Expr_3

Expr-2 - Expr-3

Expr-3

-> Expr_3 * Expr_4

Expr-3 / Expr-4

Expr-3 % Expr-4

Expr_4

-> + Expr_4

- Expr_4

I Expr_4

Expr-5

-> ( Expression )

Expr-1

( Expression ? Expression : Expression )

Function

Number

HexNumber

String

Function -> Qualifier ( ) I Qualifier ( ParameterList )

ParameterList -> ParameterList , Expression ) Expression

The following symbols are described in LEX-notation4:

Qualifier (letter)((letter}~(digit))\_)x

Number (digit)+(\.(digit)+([Ee][+\-]{digit)+)?)?

Hexnumber O[xX](hexdigit)+

hexdigit ([a-fA-f]((digit))

digit LO-91 letter [a-zA-Z]

String (quo}((Stingchar))

QUO [\“I Stringchar ((letter)l(digit}(

Spchar [\!\#-\}I

*c(wol

{Spchar))

864 Magnetic Resonance Imaging 0 Volume I 1, Number 6, 1993

REFERENCES

1. ACR/NEMA Standards Publication no. 300. Digital Im- aging and Communications. Washington, DC: National

Electrical Manufacturers Association; 1989. 2. Aldus Pagemaker. Reference Manual. Seattle, WA: Aldus

Corporation; 1988.

3. Ladon, P. An adaptable method to import data from image

archiving workstation tape into a common disk format for image processing workstations. Eurospin Quarterly 26: 7-49; 1991.

4. Aho, A.V.; Sethi, R.; Ullmann, J.D. Compilers, Tech-

niques, and Tools. Reading, MA: Addison-Wesley; 1986.