Hello,

I am getting an "Unsupported transfer syntax '1.2.840.10008.1.2.4.90'" error when trying to convert some PET and T2-weighted MRI's using dcm2niix (dcm2niiX version v1.0.20170207 (64-bit MacOS) compiled using cmake). According to the documentation lossless JPEG2000 (1.2.840.10008.1.2.4.90) should be supported, correct?

However, it does work when using the MriCro gui (Version 1.8.4) with the warning "Image Decompression is new: please validate conversions".

Thanks,
Michael

Looks like you have built dcm2niix without adding in a JPEG2000 library (you can compile to OpenJPEG, Jasper or without one). If you compile to OpenJPEG, you will see this listed in the version name, e.g. "Chris Rorden's dcm2niiX version v1.0.20170207 (openJPEG build) (64-bit MacOS)". One solution would be to get a relatively recent version I have compiled, e.g. 
   https://github.com/neurolabusc/MRIcroGL/releases/tag/v1.0.20170130
alternatively, you may want to wait a few days and get the imminent release of the next version of MRIcroGL/dcm2niix from github. Yet another alternative would be to use dcmdjp2k to save these images in the more common uncompressed format.
  http://support.dcmtk.org/docs-products/dcmdjp2k.html
If you look at the version string from dcm2niix embedded in my Mac GUI software, you will see it was compiled with OpenJPEG support (historically this was the "o" after the version, for upcoming versions it is "(openJPEG build)"

Chris, thanks a lot for the fast and excellent reply. I downloaded your pre-compiled version and that works, but will keep an eye on the upcoming release.

Hi Chris,
I run the dcm2niix.exe from matlab, and not from the GUI of MRIcroGL. Does it have also any solution or update version for the error of unsupported transfer syntax?
Thanks

And- I saw now another thread here about the difference of results in the new version software, related to Philips scaling. Does the new version exist only on GitHub, or it has any exe, or stand alone version to download?

Adiel-

Can you tell me which transfer syntax you are hoping to support. DICOM can encode the raw image data in many different formats (known as transfer syntaxes) and my software can decode all of the popular ones.
https://www.nitrc.org/plugins/mwiki/inde...
In the case of JPEG-2000, dcm2niix can be compiled with or without support for this transfer syntax. So if you want to have support for this you may need to recompile the software (at the moment, I only distribute the macOS version supporting this, as it is only really seen in Osirix). If you want to add support for additional transfer syntaxes, the code is available on Github and you can share your solutions with others by issuing a pull request. Another good solution would be to convert your DICOM data to a popular transfer syntax (e.g. using dcmdjpeg).

Hi, thank for the fast reply!

dcmdjpeg could be a nice solution, but my data is JPEG-2000, so seems that it doesn't support it.
So about the dcm2niix version that supports this transfer syntax, how actually do I re-compile it? And if I work on Windows, this version is not relevant to me anyway? Does the full tool with MRIcroGL can manage with windows+JPEG-2000...?

See the  "JPEG2000 BUILD" section of https://github.com/rordenlab/dcm2niix
if you want to build a version of dcm2niix that supports JPEG-2000. I have never tried this on Windows, so it is not included with MRIcroGL.

I use windows so I'll have to find another solution...
Anyway, thanks for the answers!

Ninfei Li has provided a version compiled for Windows that includes the OpenJPEG library. In the future, he hopes to add AppVeyor support for this to automate the builds. 

https://github.com/rordenlab/dcm2niix/re...

Thanks!
Actually I've got already the data in a regular transfer syntax from the research center where it been acquired, so I don't need it for meanwhile, but I definitely will save it.

Now I have a problem with other data- I have a sequence of 26 slices, and the dcm2niix produce two nii files- one with 25 slices and one with 1, and I get an error "check that 2D images are not mirrored". All the parameters are identical, as it shown also when I run it in the -v y mode. What can cause it? Is there a way to define that I want it in a single file?

Adiel

The verbose output should show reveal that the files differ in some way that precludes stacking them (e.g. differences in TE, Series number, etc). You could see if the option "m -y" (which merges images despite these differences) does stack the slices.

Thank you for your sample image. The bad news is that this is a problem with your DICOM images, and not my software. Specifically, when these scans were generated, one DICOM image lists a different slice orientation tag (0020:0037) relative to the other slices, suggesting it is not co-linear with the other slices and therefore should not be stacked. Inspection of this variance suggests it is very small, reflecting a rounding error when converting these values to strings ([1 -0 0 -0 0.926183 -0.377074] != [1 -0 0 -0 0.926183 -0.377073]). This is an error we see with files generated by GE scanners, and you should contact the vendor to have them fix this: all slices from a series should have identical 0020:0037 if they are co-planar, we should only see differences when the slices are not parallel to each other (e.g. scout localizer scans where coronal, sagittal and axial slices are part of the same series). The good news is that if you upgrade to a recent version of dcm2niix it is aware of this bug in GE output, and provides a tolerance that allows it to determine that these slices are "close enough" to be stacked together.

Hi Chris,
    Our data is DTI scheme, 3 b-values of 1000 and 2000 (including b=0) , 30 directions (i.e. every b-value have 15 directions). The Dicom data comes from 3 T GE-750. But I get 2 b-values of 2000 and 0 only from the transformation files, I want to know what the reason for this condition. Maybe this software cannot support this data, or others reasons. If it possible, please give me some suggestion. Any reply will be appreciated.
Best regards,
liu