Inconsistent Equalizer: Eq file not produced.

[muschellij2]

I sent you 2 datasets: clean_test_success and clean_test_failure. These are 2 different studies.

The "success" produces 2 nii.gz files (one for the converted and one for the equalized pixel spacing converted). The "fail" identifies inconsistent spacing, but only produces 1 nii.gz. Tried both on OS X and Linux (Red Hat). Bolded below is where you see 2 vs. 1 nii produced.

MacBook-Pro-3:clean_test_success johnmuschelli$ dcm2niix . Chris Rorden's dcm2niiX version 5May2016 (64-bit) Version 5May2016 (64-bit) Found 44 DICOM image(s) Dims 512 512 44 1 1 Warning: interslice distance varies in this volume (incompatible with NIfTI format). Distance from first slice: dx=[0 2.5 5 7.5 10 12.5 15 17.5 20 22.5 25 27.5 30 32.5 35 37.5 40 42.5 45 47.5 50 52.5 55 57.5 60 62.5 65 67.5 70 72.5 75 77.5 77.75 85.25 92.75 100.25 107.75 115.25 122.75 130.25 137.75 145.25 152.75 160.25] Convert 44 DICOM as ./1.1_Head_UPDATED_2_3_09_19000101133622_2 (512x512x44x1) compress: "/usr/local/bin/pigz" -n -f "./1.1_Head_UPDATED_2_3_09_19000101133622_2.nii" compress: "/usr/local/bin/pigz" -n -f "./1.1_Head_UPDATED_2_3_09_19000101133622_2_Eq_1.nii" Conversion required 0.441054 seconds. MacBook-Pro-3:clean_test_success johnmuschelli$ cd ../clean_test_fail/ MacBook-Pro-3:clean_test_fail johnmuschelli$ dcm2niix ./ Chris Rorden's dcm2niiX version 5May2016 (64-bit) Version 5May2016 (64-bit) Found 44 DICOM image(s) Dims 512 512 44 1 1 Warning: interslice distance varies in this volume (incompatible with NIfTI format). Distance from first slice: dx=[0 2.5 5 7.5 10 12.5 15 17.5 20 22.5 25 27.5 30 32.5 35 37.5 40 42.5 45 47.5 50 52.5 55 57.5 60 62.5 65 67.5 70 72.5 75 77.5 77.25 84.75 92.25 99.75 107.25 114.75 122.25 129.75 137.25 144.75 152.25 159.75] Convert 44 DICOM as ./1.1_Head_UPDATED_2_3_09_19000101172043_2 (512x512x44x1) compress: "/usr/local/bin/pigz" -n -f "./1.1_Head_UPDATED_2_3_09_19000101172043_2.nii" Conversion required 0.065939 seconds.

[neurolabusc]

John- I am afraid the problem is with your images, not my software. The image numbers do not correspond with the sequential spatial position of the slices. The first 32 slices [image numbers 1..32] are separated by 2.5mm, and there is a slice separation of 7.5mm between images 33 and 44. However, image 32 is actually closer to slice 34 than slice 33. You can see this in the distance (dx) array where 77.25 < 77.5. ....72.5 77.5 77.25 84.75... My software will convert your images if you remove either slice 32 (interpolating slices every 2.25mm) or slice 33 (interpolating slices every 2.5mm).

My strong preference is that you contact the vendor (GE medical systems) and have them sort this out. This issue does not just interfere with my software, but it also interferes with other tools, for example if you view these images with the popular Osirix, you will see the position jitter as you cycle between slices 32-34. I assume this issue is specific to the GE CT image acquisition - with MRI we tend to always use equidistant slice separation to keep interference equal across slices.

I am in two minds regarding how to deal with this. I have adapted my software's "nii_saveNII3Deq" function to deal with these images, but the resulting code is harder to comment, understand and maintain. Further, I worry that it may have unintended consequences. If you look at the latest code you will see the two lines that allow you to switch between old and new behavior:

    //if ((dx < mn) // <- only allow consistent slice direction
    if ((dx < mn) && (dx > 0.0)) // <- allow slice direction to reverse

I have also added a warning to provide the user with a clear explanation for why the slice distance could not be equalized.

if (mn <= 0.0f) {
    printf("Unable to equalize slice distances: slice number not consistent with slice position.\n");
    return EXIT_FAILURE;
}

[muschellij2]

I agree that is with the vendor. I have seen this happen before, and have also seen "double heads" in CT - in the same session they will scan the head and then also include in the same study a different portion of the brain to be scanned again. I am looking into why this happens, and our protocol is trying to make sure it's not done. I have multi-center data and we don't have a GE at our site, so I will try to deal with these as they come. I think the edits you propose are very reasonable and make sense.

So the image will convert (not fail) and a warning will be given in stdout, correct? I was wondering what your thoughts would be to putting a suffix (such as UnEq) on the .nii.gz. For me, I tend to batch process the images from DICOMs after exporting (from OsiriX) and then view them for any oddities/errors. If you don't agree a suffix should be imposed, that's fine, but it'd be easier for me to indicate this condition by searching the string for this suffix.

Thanks for looking into this and I'll update with a new build from the GH branch.

[neurolabusc]

With the latest (19May2016) version, images like yours will convert without warning. In this example the image will be converted with 2.5mm slice separation (the smallest POSITIVE distance increment). I assume these issues are only seen when there are two slabs of slices that have a negative slice gap. Please do test this - I can not think of any unintended consequences, but I have missed some. I can think of some how one could do a slightly better interpolation (e.g. using higher-order interpolation instead of linear), but the resulting code would be a lot more complex and in the real world the benefits would be very small. Further, while higher order interpolation does preserve higher frequencies it can generate some ringing artifacts.

Images with non-equidistant slices (not legal in NIfTI) get the _Eq suffix. CT scans acquired with a gantry tilt (which in theory could be supported in the NIfTI spatial transform, but would disrupt most tools) will gain the _Tilt suffix.

I would like to think that you could run dcm2niix directly on the raw DICOMs without using Osirix in between. I would have thought my software accurately detects and segments images based on features like patient ID, series number, acquisition number, protocol name, etc. In general OsiriX tends to be really robust (leveraging the terrific dcmtk), but I am not sure what role it plays in your pipeline.

[muschellij2]

Use it for folder parsing mostly, DICOM decompression (usu JPEG2000, which is now obsolete for your software but not others). The real reason I use it is that those that segment the images use it and save the segmentations in the rois_series format.

On Thu, May 19, 2016 at 9:52 AM, Chris Rorden notifications@github.com wrote:

With the latest (19May2016) version images like your will convert without warning. In this example the image will be converted with 2.5mm slice separation (the smallest POSITIVE distance increment). I assume these issues are only seen when there are two slabs of slices that have a negative slice gap. Images with non-equidistant slices (not legal in NIfTI) get the _Eq suffix. CT scans acquired with a gantry tilt (which in theory could be supported in the NIfTI spatial transform, but would disrupt most tools) will gain the _Tilt suffix.

I would like to think that you could run dcm2niix directly on the raw DICOMs without using Osirix in between. I would have thought my software accurately detects and segments images based on features like patient ID, series number, acquisition number, protocol name, etc. In general OsiriX tends to be really robust (leveraging the terrific dcmtk), but I am not sure what role it plays in your pipeline.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/neurolabusc/dcm2niix/issues/22#issuecomment-220330390

[neurolabusc]

OK, I understand.

By the way, you can compile my software to support JPEG2000 using either the Jasper or OpenJPEG libraries. I strongly recommend the latter. The version name tells you about the support, for example the current version will report version "19May2016", "19May2016j", and "19May2016o" depending on non, jasper or openJpeg support.

I wouldn't call JPEG2000 is obsolete - it is very clever. However, I personally would not recommend it for medical imaging: the high-precision variant of JPEG2000 used by JPEG2000 is not supported by most libraries or can cause odd artifacts with some libraries (see wiki article on Jasper library) and this makes it less than ideal for archival studies, especially as disk space is increasingly inexpensive. Another very minor concern I have is that JPEG 2000's artifacts are subtle blurring that looks to the human eye much better than classic JPEG, but these might erode the high frequency boundaries that are actually the key to reading a scan.

[muschellij2]

Sorry if I was unclear - I don't think the compression is obsolete, but the need to decompress the files in OsiriX as dcm2niix takes care of that. Other software that try to read DICOMs without JPEG2000 support sometimes fail. In most of those cases I'm just trying to read header information not pixel data, but not all allow you to do that.

On Thu, May 19, 2016 at 10:11 AM, Chris Rorden notifications@github.com wrote:

OK, I understand.

By the way, you can compile my software to support JPEG2000 using either the Jasper or OpenJPEG libraries. I strongly recommend the latter. The version name tells you about the support, for example the current version will report version "19May2016", "19May2016j", and "19May2016o" depending on non, jasper or openJpeg support.

I wouldn't call JPEG2000 is obsolete - it is very clever. However, I personally would not recommend it for medical imaging: the high-precision variant of JPEG2000 used by JPEG2000 is not supported by most libraries or can cause odd artifacts with some libraries (see wiki article on Jasper library) and this makes it less than ideal for archival studies, especially as disk space is increasingly inexpensive. Another very minor concern I have is that JPEG 2000's artifacts are subtle blurring that looks to the human eye much better than classic JPEG, but these might erode the high frequency boundaries that are actually the key to reading a scan.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/neurolabusc/dcm2niix/issues/22#issuecomment-220336264