If anyone is interested in supporting this file:

http://forums.dcm4che.org/jiveforums...a?threadID=644

or direct link:

http://forums.dcm4che.org/jiveforums...264/GBRGB2.dcm

Amazingly dcmtk was able to parse it, without no problem.

2cts
-Mathieu

# Dicom-File-Format

# Dicom-Meta-Information-Header
# Used TransferSyntax: LittleEndianExplicit
(0002,0000) UL 182 # 4, 1
MetaElementGroupLength
(0002,0001) OB 00\01 # 2, 1
FileMetaInformationVersion
(0002,0002) UI =SecondaryCaptureImageStorage # 26, 1
MediaStorageSOPClassUID
(0002,0003) UI
[1.2.40.0.13.1.10.180.18.159.10840700.2008080412505 8319.3] # 56, 1
MediaStorageSOPInstanceUID
(0002,0010) UI =LittleEndianImplicit # 18, 1
TransferSyntaxUID
(0002,0012) UI [1.2.40.0.13.1.1] # 16, 1
ImplementationClassUID
(0002,0013) SH [dcm4che-2.0] # 12, 1
ImplementationVersionName

# Dicom-Data-Set
# Used TransferSyntax: LittleEndianImplicit
(0008,0005) CS [ISO_IR 100] # 10, 1
SpecificCharacterSet
(0008,0012) DA [20080804] # 8, 1
InstanceCreationDate
(0008,0013) TM [125058.319] # 10, 1
InstanceCreationTime
(0008,0016) UI =SecondaryCaptureImageStorage # 26, 1
SOPClassUID
(0008,0018) UI
[1.2.40.0.13.1.10.180.18.159.10840700.2008080412505 8319.3] # 56, 1
SOPInstanceUID
(0008,0060) CS [OT] # 2, 1
Modality
(0008,0064) CS [SI] # 2, 1
ConversionType
(0008,0070) LO (no value available) # 0, 0
Manufacturer
(0010,0010) PN [Glass brain RGB] # 16, 1
PatientsName
(0010,0020) LO (no value available) # 0, 0
PatientID
(0010,0030) DA (no value available) # 0, 0
PatientsBirthDate
(0010,0040) CS (no value available) # 0, 0
PatientsSex
(0020,000d) UI
[1.2.40.0.13.1.10.180.18.159.10840700.2008080412505 8319.1] # 56, 1
StudyInstanceUID
(0020,000e) UI
[1.2.40.0.13.1.10.180.18.159.10840700.2008080412505 8319.2] # 56, 1
SeriesInstanceUID
(0020,0011) IS [1] # 2, 1
SeriesNumber
(0020,0013) IS [1] # 2, 1
InstanceNumber
(0028,0002) US 3 # 2, 1
SamplesPerPixel
(0028,0004) CS [YBR_FULL_422] # 12, 1
PhotometricInterpretation
(0028,0010) US 937 # 2, 1 Rows
(0028,0011) US 651 # 2, 1
Columns
(0028,0100) US 8 # 2, 1
BitsAllocated
(0028,0101) US 8 # 2, 1
BitsStored
(0028,0102) US 7 # 2, 1
HighBit
(0028,0103) US 0 # 2, 1
PixelRepresentation
(7fe0,0010) OB (PixelSequence #=2) # u/l, 1
PixelData
(fffe,e000) pi (no value available) # 0, 1
Item
(fffe,e000) pi ff\d8\ff\e0\00\10\4a
\46\49\46\00\01\01\00\00\01\00\01\00\00\ff\db... # 69184, 1 Item
(fffe,e0dd) na (SequenceDelimitationItem) # 0, 0
SequenceDelimitationItem

On Aug 19, 11:43*am, Mathieu Malaterre
wrote:
> If anyone is interested in supporting this file:
>
> http://forums.dcm4che.org/jiveforums...a?threadID=644
>
> or direct link:
>
> http://forums.dcm4che.org/jiveforums...t/download/5-6...
>
> Amazingly dcmtk was able to parse it, without no problem.
>
> 2cts
> -Mathieu

I guess, most DICOM implementations will able to parse the file, but
interpreting the encapsulated pixel data as JPEG baseline stream would
need to apply some simple heuristic (e.g. detect JPEG SOI marker).
Fortunately, I have not (yet) seen such objects in real PACS
installations, and I hope that the possibility to create such invalid
DICOM objects by wrong usage of dcm4che's jpg2dcm utility will not
induce that such objects show up in future.

-gunter

Mathieu Malaterre wrote:
> If anyone is interested in supporting this file: [...]
> Amazingly dcmtk was able to parse it, without no problem.

DCMTK will read the file, but will refuse to write or send the file, because the pixel data is
treated as being of "unknown transfer syntax", and none of the compression/decompression codecs
in DCMTK supports a conversion from unknown to something well-defined.

We added some support for cases like that because the combination of the icon image sequence
and compression/decompression sometimes leads to strange results: compressed images with
uncompressed icons (permitted in DICOM), compressed images with compressed icons (also permitted),
decompressed images where the icon remains compressed (stupid decoder, but seems to happen).

Best regards,
Marco Eichelberg

On Aug 20, 10:28 am, gunter zeilinger wrote:
> On Aug 19, 11:43 am, Mathieu Malaterre
> wrote:
>
> > If anyone is interested in supporting this file:
>
> >http://forums.dcm4che.org/jiveforums...a?threadID=644
>
> > or direct link:
>
> >http://forums.dcm4che.org/jiveforums...t/download/5-6...
>
> > Amazingly dcmtk was able to parse it, without no problem.
>
> > 2cts
> > -Mathieu
>
> I guess, most DICOM implementations will able to parse the file, but
> interpreting the encapsulated pixel data as JPEG baseline stream would
> need to apply some simple heuristic (e.g. detect JPEG SOI marker).
> Fortunately, I have not (yet) seen such objects in real PACS
> installations, and I hope that the possibility to create such invalid
> DICOM objects by wrong usage of dcm4che's jpg2dcm utility will not
> induce that such objects show up in future.

Gunter,

Seriously, how could you blame your dcm4che user for that. If this
is so easy to create such invalid DICOM object, I'd rather think there
is a serious bug in how your write DICOM DataSet in jpg2dcm. Add
somewhere in your code that you cannot have encapsulated JPEG with
implicit dataset. This is much simpler than adding a "simple
heuristic" in every DICOM implementation to guess that a JPEG stream
is encapsulated within an implicit dataset.

Marco,

That is yet another example of why I think a list of valid/invalid
DICOM objects is becoming a necessity for DICOM implementors.

-Mathieu

On Aug 20, 11:11 am, Marco Eichelberg
wrote:

> decompressed images where the icon remains compressed (stupid decoder, but seems to happen).

Ouch ! How do you guess the original compressor then ? Any sample
dataset ?

Thanks
-Mathieu

Mathieu Malaterre wrote:
>> decompressed images where the icon remains compressed (stupid decoder, but seems to happen).
>
> Ouch ! How do you guess the original compressor then ? Any sample
> dataset ?

We don't guess the original compressor - we read the file but refuse to
write it unless the application "fixes" or removes the icon image sequence.
Display of the main image will work, however, since this does not need the icon image.

Unfortunately I cannot find a sample image right now. Must be buried somewhere in my collection
of awful things :-)

Regards,
Marco

On Aug 20, 12:27 pm, Marco Eichelberg
wrote:
> Mathieu Malaterre wrote:
> >> decompressed images where the icon remains compressed (stupid decoder, but seems to happen).
>
> > Ouch ! How do you guess the original compressor then ? Any sample
> > dataset ?
>
> We don't guess the original compressor - we read the file but refuse to
> write it unless the application "fixes" or removes the icon image sequence.
> Display of the main image will work, however, since this does not need the icon image.

AFAIK this is actually the right thing to do. I hate this guessing
heuristic game.

> Unfortunately I cannot find a sample image right now. Must be buried somewhere in my collection
> of awful things :-)

This is not that hard to produce. I'll create a fake example.

Thanks,
-Mathieu