[Dcmlib] Re: CREATIS CVS: gdcmData jpr : gdcm-MR-PHILIPS-16-Multi-Seq.dcm

[Jean-Pierre Roux]

Mathieu Malaterre wrote:

> Creatis CVS User wrote:
>
>> CVSROOT:    /cvs/public
>> Module name:    gdcmData
>> Changes by:    jpr    05/09/06 17:21:14
>>
>> Added files:
>>     .              : gdcm-MR-PHILIPS-16-Multi-Seq.README.txt
>> Log message:
>> Add a detailed description of an oddity in the header :
>>
>> PrintFile filein=gdcm-MR-PHILIPS-16-Multi-Seq.dcm level=2
>> shows :
>>
[...]

>>
>> V fffe|e000 lg :       x(2c) 44    [UL] (starts at offset x(1be2) 7138)
>> that contains ( at offset  x(1c02) 7170) the *impossible* tag :
>> V fffe|0000 lg :        x(4) 4        [UL]
>> It's taken as a group length, some oddities occur, like :
>> V 0008|0000 lg :  x(e000fffe) 3758161918 [UL]
>> but the parsing goes on, successfully.
>
>
> I am not sure I understand what this is ?
> Is it a multiframe images ?

It's a old Single Frame image, held in gdcmData for a *very* long time.
- It has an unbelievable level number of embedded Private Sequences (up 
to 7)
- It contains  the *impossible* tag fffe|0000 (not a terminator, not a 
group number )

gdcm parses and reads it without any trouble; the 'ctest' is successfull 
on it.
I just added a 'REAME.txt' file, to describe better the oddity than only 
giving a 'significant' name.

> Or is it another Big/Little endian SQ philips image ?

I think the problems of endianess switching and/or mixing 'true length' 
SQItems within 'no length' Sequences and/or 'no length' SQItems within 
'true length' Sequences is definitively solved  -hope so-
JP

>
> Mathieu
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>