- guint16 element = ElVal->GetElement();
- string vr = ElVal->GetVR();
- guint16 length16;
-
- if ( (filetype == ExplicitVR) && ! ElVal->IsImplicitVr() ) {
-
- if ( (vr=="OB") || (vr=="OW") || (vr=="SQ") || (vr=="UN") ) {
- // The following reserved two bytes (see PS 3.5-2001, section
- // 7.1.2 Data element structure with explicit vr p27) must be
- // skipped before proceeding on reading the length on 4 bytes.
- fseek(fp, 2L, SEEK_CUR);
- guint32 length32 = ReadInt32();
- if ( (vr == "OB") && (length32 == 0xffffffff) ) {
- ElVal->SetLength(FindLengthOB());
- return;
- }
- FixFoundLength(ElVal, length32);
- return;
- }
-
- // Length is encoded on 2 bytes.
- length16 = ReadInt16();
-
- // We can tell the current file is encoded in big endian (like
- // Data/US-RGB-8-epicard) when we find the "Transfer Syntax" tag
- // and it's value is the one of the encoding of a big endian file.
- // In order to deal with such big endian encoded files, we have
- // (at least) two strategies:
- // * when we load the "Transfer Syntax" tag with value of big endian
- // encoding, we raise the proper flags. Then we wait for the end
- // of the META group (0x0002) among which is "Transfer Syntax",
- // before switching the swap code to big endian. We have to postpone
- // the switching of the swap code since the META group is fully encoded
- // in little endian, and big endian coding only starts at the next
- // group. The corresponding code can be hard to analyse and adds
- // many additional unnecessary tests for regular tags.
- // * the second strategy consist in waiting for trouble, that shall appear
- // when we find the first group with big endian encoding. This is
- // easy to detect since the length of a "Group Length" tag (the
- // ones with zero as element number) has to be of 4 (0x0004). When we
- // encouter 1024 (0x0400) chances are the encoding changed and we
- // found a group with big endian encoding.
- // We shall use this second strategy. In order make sure that we
- // can interpret the presence of an apparently big endian encoded
- // length of a "Group Length" without committing a big mistake, we
- // add an additional check: we look in the allready parsed elements
- // for the presence of a "Transfer Syntax" whose value has to be "big
- // endian encoding". When this is the case, chances are we got our
- // hands on a big endian encoded file: we switch the swap code to
- // big endian and proceed...
- if ( (element == 0x000) && (length16 == 0x0400) ) {
- if ( ! IsExplicitVRBigEndianTransferSyntax() )
- throw Error::FileReadError(fp, "gdcmHeader::FindLength");
- length16 = 4;
- SwitchSwapToBigEndian();
- // Restore the unproperly loaded values i.e. the group, the element
- // and the dictionary entry depending on them.
- guint16 CorrectGroup = SwapShort(ElVal->GetGroup());
- guint16 CorrectElem = SwapShort(ElVal->GetElement());
- gdcmDictEntry * NewTag = IsInDicts(CorrectGroup, CorrectElem);
- if (!NewTag) {
- // This correct tag is not in the dictionary. Create a new one.
- NewTag = new gdcmDictEntry(CorrectGroup, CorrectElem);
- }
- // FIXME this can create a memory leaks on the old entry that be
- // left unreferenced.
- ElVal->SetDictEntry(NewTag);
- }
-
- // Heuristic: well some files are really ill-formed.
- if ( length16 == 0xffff) {
- length16 = 0;
- dbg.Verbose(0, "gdcmHeader::FindLength",
- "Erroneous element length fixed.");
- }
- FixFoundLength(ElVal, (guint32)length16);
- return;
- }
-
- // Either implicit VR or a non DICOM conformal (see not below) explicit
- // VR that ommited the VR of (at least) this element. Farts happen.
- // [Note: according to the part 5, PS 3.5-2001, section 7.1 p25
- // on Data elements "Implicit and Explicit VR Data Elements shall
- // not coexist in a Data Set and Data Sets nested within it".]
- // Length is on 4 bytes.
- FixFoundLength(ElVal, ReadInt32());
+ guint16 element = ElVal->GetElement();
+ string vr = ElVal->GetVR();
+ guint16 length16;
+
+ if ( (filetype == ExplicitVR) && ! ElVal->IsImplicitVr() ) {
+
+ if ( (vr=="OB") || (vr=="OW") || (vr=="SQ") || (vr=="UN") ) {
+ // The following reserved two bytes (see PS 3.5-2001, section
+ // 7.1.2 Data element structure with explicit vr p27) must be
+ // skipped before proceeding on reading the length on 4 bytes.
+ fseek(fp, 2L, SEEK_CUR);
+ guint32 length32 = ReadInt32();
+ if ( (vr == "OB") && (length32 == 0xffffffff) ) {
+ ElVal->SetLength(FindLengthOB());
+ return;
+ }
+ FixFoundLength(ElVal, length32);
+ return;
+ }
+
+ // Length is encoded on 2 bytes.
+ length16 = ReadInt16();
+
+ // We can tell the current file is encoded in big endian (like
+ // Data/US-RGB-8-epicard) when we find the "Transfer Syntax" tag
+ // and it's value is the one of the encoding of a big endian file.
+ // In order to deal with such big endian encoded files, we have
+ // (at least) two strategies:
+ // * when we load the "Transfer Syntax" tag with value of big endian
+ // encoding, we raise the proper flags. Then we wait for the end
+ // of the META group (0x0002) among which is "Transfer Syntax",
+ // before switching the swap code to big endian. We have to postpone
+ // the switching of the swap code since the META group is fully encoded
+ // in little endian, and big endian coding only starts at the next
+ // group. The corresponding code can be hard to analyse and adds
+ // many additional unnecessary tests for regular tags.
+ // * the second strategy consists in waiting for trouble, that shall
+ // appear when we find the first group with big endian encoding. This
+ // is easy to detect since the length of a "Group Length" tag (the
+ // ones with zero as element number) has to be of 4 (0x0004). When we
+ // encouter 1024 (0x0400) chances are the encoding changed and we
+ // found a group with big endian encoding.
+ // We shall use this second strategy. In order to make sure that we
+ // can interpret the presence of an apparently big endian encoded
+ // length of a "Group Length" without committing a big mistake, we
+ // add an additional check: we look in the allready parsed elements
+ // for the presence of a "Transfer Syntax" whose value has to be "big
+ // endian encoding". When this is the case, chances are we have got our
+ // hands on a big endian encoded file: we switch the swap code to
+ // big endian and proceed...
+ if ( (element == 0x000) && (length16 == 0x0400) ) {
+ if ( ! IsExplicitVRBigEndianTransferSyntax() ) {
+ dbg.Verbose(0, "gdcmHeader::FindLength", "not explicit VR");
+ errno = 1;
+ return;
+ }
+ length16 = 4;
+ SwitchSwapToBigEndian();
+ // Restore the unproperly loaded values i.e. the group, the element
+ // and the dictionary entry depending on them.
+ guint16 CorrectGroup = SwapShort(ElVal->GetGroup());
+ guint16 CorrectElem = SwapShort(ElVal->GetElement());
+ gdcmDictEntry * NewTag = GetDictEntryByKey(CorrectGroup, CorrectElem);
+ if (!NewTag) {
+ // This correct tag is not in the dictionary. Create a new one.
+ NewTag = new gdcmDictEntry(CorrectGroup, CorrectElem);
+ }
+ // FIXME this can create a memory leaks on the old entry that be
+ // left unreferenced.
+ ElVal->SetDictEntry(NewTag);
+ }
+
+ // Heuristic: well some files are really ill-formed.
+ if ( length16 == 0xffff) {
+ length16 = 0;
+ dbg.Verbose(0, "gdcmHeader::FindLength",
+ "Erroneous element length fixed.");
+ }
+ FixFoundLength(ElVal, (guint32)length16);
+ return;
+ }
+
+ // Either implicit VR or a non DICOM conformal (see not below) explicit
+ // VR that ommited the VR of (at least) this element. Farts happen.
+ // [Note: according to the part 5, PS 3.5-2001, section 7.1 p25
+ // on Data elements "Implicit and Explicit VR Data Elements shall
+ // not coexist in a Data Set and Data Sets nested within it".]
+ // Length is on 4 bytes.
+ FixFoundLength(ElVal, ReadInt32());