 |
Download | Install | Usage (1) (2) | How to | Problems | Limitations | Performances |
   |
||
 |
||||
 |
 |
 |
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. |
||||
|
 |
|
Encapsulated syntax | |
 |
||||
| 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! |
||||
|
 |
|
Unsupported VR | |
|
||||
| Some Value Representation are not supported.
The corresponding DICOM data-elements are skipped:
FD
(floating point double) FL
(floating point single)
>> [W] [20:36:00] ifbstream& SbDicomDataElementValue::Read( ifbstream& ) AT length = 4, current = 12, multiple values not implemented :( |
||||
|
|
|
Photometric interpretation | |
|
||||
| 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). | ||||
|
|
|
Planar configuration | |
|
||||
| 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). | ||||
|
|
|
Bits allocated | |
|
||||
| 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) |
||||
|
|
|
Color Lookup Tables | |
|
||||
| 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! |
||||
|
|
|
Multiple-frame files | |
 |
||||
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):
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 | |
||