[Dcmlib] Fwd: [Fwd: Re: JPEGLS / D Clunie dataset]

[Mathieu Malaterre]

Pour info...

Begin forwarded message:
>
> Mathieu Malaterre wrote:
> > Hello,
> >
> >     I am working on getting gdcm to support jpegls, and currently I 
> am
> > playing with a DICOM file from D. Clunie dataset:
> >
> >   
> http://www.creatis.insa-lyon.fr/~malaterre/gdcm/D_CLUNIE_CT1_JLSN.dcm
> >
> >     This file has two jpegls fragments where the lenght -as read by
> > gdcm- are:
> >
> > #1 65536
> > #2 19536
> > --------
> >    85072
> >
> >     So far so good, but when I read the pixel data length I find: 
> 85104.
> >
> >     Could someone confirm the values read ? Am I missreading 
> something ?
> > If not why is there a difference of 32 bytes ?
>
> Hi Mathieu
>
> I presume this is the same file as in the set of test images
> on the NEMA server, specifically IMAGES/JLSN/CT1_JLSN.
>
> A dump of the Pixel Data attribute and contents shows:
>
> @0x000019a6: (0x7fe0,0x0010) OX Pixel Data       VR=<OB>   
> VL=<0xffffffff>      []
> @0x000019b2: (0xfffe,0xe000) NONE Item   VR=<>   VL=<0x0000>    []
> @0x000019ba: (0xfffe,0xe000) NONE Item   VR=<>   VL=<0x10000>   []     
>  # skipping ...
> @0x000119c2: (0xfffe,0xe000) NONE Item   VR=<>   VL=<0x4c50>    []     
>  # skipping ...
> @0x0001661a: (0xfffe,0xe0dd) NONE Sequence Delimitation Item     VR=<> 
>   VL=<0x0000>    []
>
> When I run dctoraw to extract the bytes from the Pixel Data
> items, I get:
>
> UnencapsulatePixelData::read Item Tag length=0x0 (0 dec)
> UnencapsulatePixelData::read Item Tag length=0x10000 (65536 dec)
> UnencapsulatePixelData::read Item Tag length=0x4c50 (19536 dec)
>
> and the resulting raw binary file is 85072 bytes long, as expected,
> and starts and ends with the following bytes:
>
> 0000000 ffd8 fff7 000b 1002 0002 0001 0111 00ff
> 0000010 f800 0d01 ffff 001e 0057 0130 0040 ffda
> ...
> 0014c30 d554 a94d badc d3da 5a58 a023 ad00 c800
> 0014c40 0000 0000 010e 6423 0c61 8c52 70ff d9ff
> 0014c50
>
> I presume you are removing the Item tags and the Sequence Delimitation
> item at the end, each of which occupies 8 bytes (and four of them would
> account for your file being 32 bytes too long, if you are not removing
> them).
>
> This problem would apply to any encapsulated transfer syntax.
>
> David
>
>