Closed Svdvoort closed 5 years ago
Hi
Just a comment – Philips changed its name from “Medical Systems” to “Heathcare” some years ago so these will be different machines or at least different vintages of software.
If they are DWI rather than DTI, then the data can isotropic with no defined direction and will be represented with a 0 b vector.
Matthew
From: Chris Rorden [mailto:notifications@github.com] Sent: 13 February 2019 14:54 To: rordenlab/dcm2niix dcm2niix@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [rordenlab/dcm2niix] bvec values incorrectly recognized as ADC in Philips scan (#270)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frordenlab%2Fdcm2niix%2Fissues%2F270%23issuecomment-463228372&data=02%7C01%7C%7C99c1dcc180784d22fedf08d691c30dc6%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C636856664266933922&sdata=hQqfTaXoNCqvvO2J15JRorr5Uwv1%2Bxt1IfISTmBrgsk%3D&reserved=0, or mute the threadhttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAiJgTw8NnmoaDsiGLWXmMXnH5PXLtnTGks5vNCb2gaJpZM4a5gHV&data=02%7C01%7C%7C99c1dcc180784d22fedf08d691c30dc6%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C636856664266943931&sdata=qsC7fLgVuvQRqWX%2BtC5jWG5rLNEA4bLbLU2838H8yts%3D&reserved=0.
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
Yes, tried it just now by compiling the latest development branch. Problem still exists with the same error message.
I've just send you the dataset
They are classic format DICOMs.
@Svdvoort dcm2niix converts these images correctly. This series is for derived images (from visual inspection it looks like a mean B=0, trace and isotropic) rather than the raw DWI data. Therefore, there are no single b-vectors associated with these images (these are a composite of the raw b-weighted images). It is unfortunate that the Philips convention is to list the image type (0008,0008) as ORIGINAL
rather than DERIVED
. If they were correctly reported as derived, dcm2niix could automatically skip these if you specified the ignore derived parameter (-i y
).
I would suggest you ignore these images and work with the raw DWI data where dcm2niix will generate bvec/bval files. You will be able to get much better quality derived files after you apply the appropriate processing (e.g. dwidenoise, deGibbs, eddy, TOPUP).
You can clearly see the issue by viewing the DICOM header of these files with your favorite viewer (e.g. dcmdump, Horos). Note that the images all report a gradient vector orientation of 0/0/0:
(0018,9087) FD 1000 # 8, 1 DiffusionBValue (0018,9089) FD 0\0\0 # 24, 3 DiffusionGradientOrientation
Hi
Just as a comment, these images are original. I ts an isotropically weighted acquistion for clinical DWI.
Matthew
Get Outlook for Androidhttps://aka.ms/ghei36
From: Chris Rorden notifications@github.com Sent: Wednesday, February 13, 2019 6:34:49 PM To: rordenlab/dcm2niix Cc: Clemence, Matthew; Comment Subject: Re: [rordenlab/dcm2niix] bvec values incorrectly recognized as ADC in Philips scan (#270)
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frordenlab%2Fdcm2niix%2Fissues%2F270%23event-2137575248&data=02%7C01%7C%7C69abe093e5cb456b297a08d691e1f135%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C636856796927924781&sdata=hYuJYvrgcArZ%2BM8eIMADYNQM9gSBo25kvhP2SKE0mX8%3D&reserved=0, or mute the threadhttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAiJgT66o9dur79qQhRO7AzBdhrDAwyXaks5vNFrJgaJpZM4a5gHV&data=02%7C01%7C%7C69abe093e5cb456b297a08d691e1f135%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C636856796927924781&sdata=ocrsECQqaogmICShamupnzEfx8mRwpsPZJAgDxdP%2Bfg%3D&reserved=0.
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
@drmclem thanks for the clarification - that makes sense. Regardless, this series does not have individual directional diffusion images that would generate bvec/bval files.
I do not understand why it should not generate bvec/bval files? From what I understand these are a b=0, b=500 and b=1000 images from a DWI acquisition. Granted they are already averaged probably by the machine, and therefore there bvecs are all 0 (and thus it is not a DTI). However, the bval files can still be written I imagine.
The behavior at least seems to be inconsistent within dcm2niix, as a scan that has 'Philips Medical Systems' as manufacturer and the same parameters (b=0,500,1000 with bvecs of 0) does generate bvec/bval files. In these case the bvec files of course only contains 0 vectors. (I can supply these files as well if requested)
Would it be a possibility to make an extra flag which defaults to the current behavior, but can be set to generate the bvals/bvecs in any case? I can submit a pull requested for this if desired.
The sequence you sent me have B=0, Isotropic and Trace images, but does not have any volumes with selective gradient vectors. You can see this yourself by viewing the DICOM headers: no images report gradient vectors, they all report (0018,9089) FD 0\0\0 # 24, 3 DiffusionGradientOrientation While I have not seen your other dataset, if you look at the DICOM headers you will find that they report volumes that have gradient vectors.
Visual inspection of the images also reveals that the B=0, isotropic and Trace images are not selective for specific fiber tracks. This has nothing to do with the headers reporting 'Philips Healthcare' versus 'Philips Medical Systems'. Rather, it reflects that one of your series recorded images that were selective to different diffusion directions and the other did not. Please see this page for more details on these different forms of diffusion images.
Hi, running into the same issue here. Would it be possible to still generate at least the .bval files? We're not doing anything with DTI/Fiber analysis, but it would help generating ADC maps ourselves a lot easier (for which we won't need the vectors).
@Markus92 am I correct that you want dcm2niix to create a .bval file but not a .bvec file when it converts a DICOM image that has variable B-values but no images with anisotropic b-vectors? I do not have access to Philips hardware. Can you send me a link (Box, DropBox, GoogleDrive) to a sample dataset? My email is in my avatar.
@neurolabusc That's exactly what would help me out, yes! Unfortunately I'm not at liberty to share (part of) the dataset due to restrictions set by our IRB as it is patient data, sorry about that. I can give you some DICOM tag information, however. Here an example for b 150:
(0018,9087) DiffusionBValue 150 (0018,9089) DiffusionGradientOrientation 0\0\0
(0018, 9075) is not set, neither are the proprietary (2005,1xxx) tags, nor any (2001,xxxx) tags. DICOMs we got are normal ones (one 2d slice per file), not the Philips enhanced format. They do use JP2k compression, our main reason for using this tool.
It seems patching out this function - however ugly it is - may lead to our desired result, however I cannot confirm as I have some trouble compiling dcm2niix with OpenJP2K on Windows.
I suggest you make a fork of the project. I would not want to add features without a validation and regression dataset. The fork will use AppVeyor to compile Windows executables, and you can look at the AppVeyor Artifacts
tab to download an executable. AppVeyor will build with JPEG2000 support (USE_OPENJPEG) enabled:
cmake -Wno-dev -G "Visual Studio 14 2015 Win64" -DBATCH_VERSION=ON -DUSE_OPENJPEG=ON -DUSE_JPEGLS=true ..
I would edit the code below, so that rather then returning it sets a flag to return after the .bval file is created but before the .bvec file is created:
if ((*numADC == numDti) || (numGEwarn == numDti)) {
//all isotropic/ADC images - no valid bvecs
*numADC = 0;
free(bvals);
free(vx);
return NULL;
}
@neurolabusc after some messing with CMake, I patched out IsADCnotDTI to always return False. Very ugly solution and I understand why you would stay clear from it, but it works for me for now (we only need to process this dataset once). Thanks for your help and quick responses!
I a philips DWI scan with b-values of 0, 500 and 1000 with bvecs of 0. When running dcm2niix, it comes back with the message:
However, there is no ADC in these scans. Issues seems to be here, where it looks for non-zero b-values with 0 bvecs, which it regards as ADC in the case of Philips system.
Interesting note: I have two DWIs that are almost identical, however in one manufacturer is specified as 'Philips Healthcare' and the other 'Philips Medical Systems'. Only with the former this issue occurs.
I'm not sure where this rule comes from? Or how to nicely edit it, as if this is indeed the case for some scans then would not like to submit a pull request where the line is just removed.