Is compressed pixel data in unencapsulated format valid?
Michael Doppler
using JPEG lossless non hierarchical 1st order prediction transfer
syntax and includes the pixel data in unencapsulated format, without
encoding it in a fragment. Is this valid according to the DICOM
Standard?
In chapter 8.2 of DICOM Standard 2008, Part 5 [1] it sounds as if
compressed pixel data shall be encoded in at least one fragment in
encapsulated format and not present in unencapsulated format. Is this
correct?
Thanks in advance,
Michael
[1]
ftp://medical.nema.org/medical/dicom/2008/08_05pu.pdf#page=47
8.2 NATIVE OR ENCAPSULATED FORMAT ENCODING
Pixel data conveyed in the Pixel Data Element (7FE0,0010) may be sent
either in
a Native (uncompressed) Format or in an Encapsulated Format (e.g.
compressed)
defined outside the DICOM standard.
...
The encapsulated pixel stream of encoded pixel data is segmented in
one or
more Fragments which convey their explicit length.
Mathieu Malaterre
No you need at least two items. The first one is the Basic Offset
Table (may be empty), the second one is indeed the jpeg stream. Anyway
simply storing the JPEG stream within Pixel Data element (7fe0,0010)
is a *very* bad idea. This is really a bad implementation of the DICOM
standard, just run away quick !
One way to check is run gdcmconv --raw or dcmtk: dcmconv +ti on the
file.
As a side note, I have seen people doing this kind of things, but they
were storing the JPG in a Raw Data Storage.
HTH
-Mathieu
Ref:
http://gdcm.sourceforge.net/html/gdcmconv.html
Michael Doppler
wrote:
> Anyway
> simply storing the JPEG stream within Pixel Data element (7fe0,0010)
> is a *very* bad idea. This is really a bad implementation of the DICOM
> standard, just run away quick !
Thanks Mathieu, this is what I suspected.
I called gdcmconv 2.0.13 as suggested, this is the output it produced:
gdcmconv.exe --raw -i 4ADEC7AA.dcm -o out.raw
Not a JPEG file: starts with 0xfe 0xff
Not a JPEG file: starts with 0xfe 0xff
Could not change the Transfer Syntax: 4ADEC7AA.dcm
Michael