dicom2 logo
 
Download | Install | Usage (1) (2) | How to | Problems | Limitations | Performances 
TOCProblemsPerformance 
Limitations
      Encapsulated syntax 
Unsupported VR 
Photometric interpretation 
Planar configuration 
Bits allocated 
Color Lookup Tables 
Multiple-frame files 
 
For now on, these limitations do not embarrass me, as I am not using files concerned about these unresolved problems. Nevertheless, report me if any of these points is vital for you, and I will see what I can do. 

Some of these limitations will also remain as long as I won't get samples containing the unsupported topics. If you own such samples, I would really appreciate working on them and maybe adding them to my medical image samples page.

Top Encapsulated syntax
Unsupported VR
  No encapsulated (compressed) syntax is supported. Sorry ;) 
 
>> [E] [21:32:56] 
   bool SbMedicalFrame::UpdateFrom( const SbDicomDataElementSet&, ... ) 
   encapsulated syntax 1.2.840.10008.1.2.4.70 is not supported!
Encapsulated syntax Unsupported VR
Photometric interpretation
    Some Value Representation are not supported. The corresponding DICOM data-elements are skipped: 
    FD (floating point double) 
    FL (floating point single) 
Multiple valued elements (VM > 1) are not supported too: the first value is read, the others are skipped. You may want to use --warn to prevent these warnings from being displayed. 
 
>> [W] [20:36:00] 
   ifbstream& SbDicomDataElementValue::Read( ifbstream& ) 
   AT length = 4, current = 12, multiple values not implemented :( 
Unsupported VR Photometric interpretation
Planar configuration
  Conversions from photometric interpretations (0x0028, 0x0004) other than MONOCHROME1, MONOCHROME2, PALETTE COLOR and RGB are not supported. Be aware that some image processing options support all photometric interpretation, as other do only support a restricted set ot them  (--acc will ignore RGB images for example).  
Photometric interpretation Planar configuration
Bits allocated
  The planar configuration item is required when "Samples per Pixel" has a value greater than 1 (RGB files for example). Planar configuration values 0 (color-by-pixel) and 1 (color-by-plane) are supported, but color-by-plane data are automatically converted and reorganized to color-by-pixel (this might be important to say if you are converting back to DICOM).
Planar configuration Bits allocated
Color Lookup Tables
  Bits allocated (0x0028, 0x0100) > 16 are not fully supported (this number of bits is the size of the cell that is used to store a pixel sample and optionally additional bits, see option -r for diagrams). Nevertheless,  I don't know if a such big size has been ever used. 
 
>> [E] [14:21:50] 
   bool SbMedicalFrame::UpdateFrom( const SbDicomDataElementSet&, ... ) 
   bits allocated 18 > 16 are not fully supported... (email me)
Bits allocated Color Lookup Tables
Multiple-frame files
  When using PALETTE COLOR images, the color lookup table descriptors (red (0x0028,0x1101), green (0x0028, 0x1102), blue (0x0028, 0x1103)) must have the same structure (size, number of entries and depth), so that the whole clut could be rebuilt (red/green/blue). CLUT entries (red (0x0028,0x1201), green (0x0028, 0x1202), blue (0x0028, 0x1203)) shall be "upsampled" to 16 bits (i.e. 0xFF => 0xFF00).
 
>> [E] [14:21:50] 
   bool SbMedicalFrame::UpdateFrom( const SbDicomDataElementSet&, ... ) 
   different clut descriptors are not allowed!
Color Lookup Tables Multiple-frame files
Bottom
  dicom2 is unfortunately not able to read all types of multiple-frame files: to be honnest, it is not even able to read the recommended DICOM organization (!), which states (see DICOM Part 5, section A.4c) that value representations OB or OW of files made of multiple fragments shall meet some specific requirements (more or less a SQ organization): 
  • [...] every fragment (within the pixel data stream) shall be  encapsulated as a DICOM Item with a specific Data Element Tag of Value (FFFE, 0000), [...] 
  • [...] all fragments shall be made of an even number of bytes [...] 
  • [...] the first Item before the Encoded Pixel Data Stream shall be a (nice) Basic Offset Table item (not required), which contains concatenated 32-bit unsigned integer values that are bytes offsets leading to the beginning of each frame [...]
Nevertheless, I have been unable to get any multiple-frame file following that standard, except one or two which used an encapsulated syntax that dicom2 did not support... 

But I have found a lot of multiple-frame files structured in a much simpler manner: the OB or OW value is made of the raw concatenation of each frame, one after the another, and that's what dicom2 is actually supporting. I you want to have a look at one of these multiple-frame files, check out my medical image samples page.

 
Download | Install | Usage (1) (2) | How to | Problems | Limitations | Performances  TOCProblemsPerformance 
 
Medical Imaging / Sébastien Barré / Jan. 1998