@lassoan with regards to ITK support, the Transfer Syntax is 1.2.840.10008.1.2.4.91, which means lossy JPEG-2000 compression. OpenJPEG is the only open source library that can reliably read these images at high precision. The dcm2niix code shows how to call this library. The Python-based dicom2nifti shows a different approach - if calls gdcmconv to decode compressed DICOMs to raw DICOM (e.g. from the command line ‘gdcmconv -w IM-0001-0001.dcm raw.dcm’).
In these examples, JPEG-2000 achieves an impressive 5:1 compression ratio. However, I would personally suggest users avoid compressed DICOM transfer syntaxes: the DICOM standard only requires DICOM compliant tools to read the uncompressed data, so while one can generate a valid compressed DICOM image, there is no guarantee it will be supported by various DICOM utilities in your tool chain.
As an aside, my own personal opinion is that lossy JPEG-2000 is particularly ill-suited to medical imaging. The reason is that it is so “good” from the perspective of human observers, avoiding the blocking and other artifacts of classic JPEG. As one increases compression with JPEG-2000 the images exhibit a subtle blurring. Even highly compressed images look great to a human viewer. However, in my experience it is often the high frequency edges that are crucial to diagnoses, e.g. signs of hippocampal sclerosis. One assumes the moderate compression applied in the sample images retains such attributes, but loss in fidelity will be hard to detect.
The SlicerDcm2nii extension should help Slicer users in the rare cases where the in-built ITK library fails. The current integration of the ITK libraries in Slicer is so good that I think it would be a major engineering feat to use a different tool. My sense is Slicer users report the rare instances where the ITK library fails, yet the vast number of successful conversions are unreported.
I do not think there is any perfect DICOM converter. This is due to the inherent complexity of DICOM, the fact that different vendors have interpreted it differently, the reality that vendors are evolving their interpretations, and that over the years each vendor has released buggy DICOMs that do not strictly conform to the standard. I suspect that if Slicer relied on dcm2niix rather than ITK, you would be made aware of the instances where dcm2niix fails.