Philips DICOM conversion "corrupted" files (XX_####)

[hippocampo]

Hello,
I am hoping for some help with DCM2NIIx conversion of certain Philips DICOM files, which are reported as corrupted and interrupt the process with an error code 4. This may be related to the XX_#### (and PS_#### files), which are identified as corrupted. I suspect this may be specifically related to a QSM data collection, I'm not sure. Here is the DCM2NIIx code that throws the error:

//20190524: Philips MR 55.1 creates non-image files that report kDim1/kDim2 - we can detect them since 0008,0016 reports “RawDataStorage”
printError(“Conversion aborted due to corrupt file: %s %d %d\n”, fname, d.xyzDim[1], d.xyzDim[2]);

Thanks very much,
Chris

[neurolabusc]

@hippocampo would it be possible to send a sample dataset (via DropBox, Box, GoogleDrive) to me (email in my avatar). I work at a Siemens only center, so rely on users to reverse engineer Philips interpretation of the DICOM standard.

I wonder if the latest commits to the development branch resolve your issue. If you have a Linux/Mac you can test this by building the development build - if you are successful the software report version v1.0.20190808:

git clone --branch development https://github.com/rordenlab/dcm2niix.git
cd dcm2niix/console
make
./dcm2niix

[captainnova]

@hippocampo, I think those are exam card type files, and not images. You could check whether the PixelData tag is present. Rob

…

On Wed, Aug 28, 2019, 7:16 AM Chris Rorden ***@***.***> wrote: @hippocampo <https://github.com/hippocampo> would it be possible to send a sample dataset (via DropBox, Box, GoogleDrive) to me (email in my avatar). I work at a Siemens only center, so rely on users to reverse engineer Philips interpretation of the DICOM standard. I wonder if the latest commits to the development branch resolve your issue. If you have a Linux/Mac you can test this by building the development build - if you are successful the software report version v1.0.20190808: git clone --branch development https://github.com/rordenlab/dcm2niix.git cd dcm2niix/console make ./dcm2niix — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#328?email_source=notifications&email_token=ADY6J2PAFUPBGCX3OK67SP3QGZUDJA5CNFSM4IREZ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5K5IYQ#issuecomment-525718626>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADY6J2JWJ4H3A2E76AZMVFDQGZUDJANCNFSM4IREZ6MA> .

[neurolabusc]

Agreed. The question is whether the current dcm2niix algorithm correctly rejects these non-images, does not report them as corrupt images (terminating with an error), and does not falsely skip real DICOM images. I think the current development build does this, but it would be nice to confirm this. It is unfortunate that Philips made these non-image files so similar to DICOM images, a quick web search will show this had a lot of unintended consequences on tools that mistook these for being DICOM images.

[drmclem]

Hi Xx and ps are auxiliary data and presentation states respectively - also XX is used to store spectrosccopy time domain data - images are always in IM_ files. The auxillary data is to allow the scan to be repeated on the philips systems and contains sufficient acquisition details and examcards to do this but are not needed for image viewing. You should not need to check for pixel data - tag 0002,0002 should be sufficient to discriminate - the public ones are decoded correctly by dcmtk. MR Image Storage = 1.2.840.10008.5.1.4.1.1.4 Enhanced MR Image Storage = 1.2.840.10008.5.1.4.1.1.4.1 MR Spectroscopy Storage = 1.2.840.10008.5.1.4.1.1.4.2 Secondary Capture Image Storage = 1.2.840.10008.5.1.4.1.1.7 Grayscale Softcopy Presentation State = 1.2.840.10008.5.1.4.1.1.11.1 Raw Data Storage = 1.2.840.10008.5.1.4.1.1.66 Older classic tags Private MR Spectrum Storage = 1.3.46.670589.11.0.0.12.1 Private MR Series Data Storage = 1.3.46.670589.11.0.0.12.2 Private MR Examcard Storage = 1.3.46.670589.11.0.0.12.4 Matthew

________________________________ From: Rob Reid <notifications@github.com> Sent: Wednesday, August 28, 2019 7:15:02 PM To: rordenlab/dcm2niix <dcm2niix@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [rordenlab/dcm2niix] Philips DICOM conversion "corrupted" files (XX_####) (#328) @hippocampo, I think those are exam card type files, and not images. You could check whether the PixelData tag is present. Rob

On Wed, Aug 28, 2019, 7:16 AM Chris Rorden ***@***.***> wrote: @hippocampo <https://github.com/hippocampo> would it be possible to send a sample dataset (via DropBox, Box, GoogleDrive) to me (email in my avatar). I work at a Siemens only center, so rely on users to reverse engineer Philips interpretation of the DICOM standard. I wonder if the latest commits to the development branch resolve your issue. If you have a Linux/Mac you can test this by building the development build - if you are successful the software report version v1.0.20190808: git clone --branch development https://github.com/rordenlab/dcm2niix.git cd dcm2niix/console make ./dcm2niix - You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#328?email_source=notifications&email_token=ADY6J2PAFUPBGCX3OK67SP3QGZUDJA5CNFSM4IREZ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5K5IYQ#issuecomment-525718626>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADY6J2JWJ4H3A2E76AZMVFDQGZUDJANCNFSM4IREZ6MA> .

- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frordenlab%2Fdcm2niix%2Fissues%2F328%3Femail_source%3Dnotifications%26email_token%3DAIRGAT6XNH6WEFOT3JU24WTQG26CNA5CNFSM4IREZ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5MAG2Q%23issuecomment-525861738&data=02%7C01%7C%7Cd89d35ba5fc84a738f0f08d72be3a602%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C637026129052077368&sdata=Ut9ZRS077utYwIFJExMHZBdgtHB8cmLzHBZCPrTXgOg%3D&reserved=0>, or mute the thread<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAIRGAT2BQDEUZ7UU7NH5HSTQG26CNANCNFSM4IREZ6MA&data=02%7C01%7C%7Cd89d35ba5fc84a738f0f08d72be3a602%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C637026129052087363&sdata=JxpyqPnCzJPDcG9KL4Bw28eCf7B2JHzEOnukQWrf%2F3A%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]

Hi Just to follow up on the previous post – the SOP 0002,0002 should differentiate them and any “similarity” is to allow DICOM transport to correctly route and store them. Matthew From: Chris Rorden [mailto:notifications@github.com] Sent: 28 August 2019 19:38 To: rordenlab/dcm2niix <dcm2niix@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [rordenlab/dcm2niix] Philips DICOM conversion "corrupted" files (XX_####) (#328) Agreed. The question is whether the current dcm2niix algorithm correctly rejects these non-images, does not report them as corrupt images (terminating with an error), and does not falsely skip real DICOM images. I think the current development build does this, but it would be nice to confirm this. It is unfortunate that Philips made these non-image files so similar to DICOM images, a quick DICOM search will show this had a lot of unintended consequences on tools that mistook these for being DICOM images. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frordenlab%2Fdcm2niix%2Fissues%2F328%3Femail_source%3Dnotifications%26email_token%3DAIRGAT7CBXGZRYLRVBFLZO3QG3AZJA5CNFSM4IREZ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5MCKSI%23issuecomment-525870409&data=02%7C01%7C%7Cf0193243186147fc254608d72be6e20c%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C637026142944749549&sdata=ge0rV5g8bcYSwSSIIPt7Yz7Sp6QtiY4ApaRIYvXxITs%3D&reserved=0>, or mute the thread<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAIRGATYRZ63OPH4MFU3Q2RLQG3AZJANCNFSM4IREZ6MA&data=02%7C01%7C%7Cf0193243186147fc254608d72be6e20c%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C637026142944759544&sdata=%2BBAXKQx65hUMjHoMOGAnP0Kwht0EUe5fz%2FydqrvIA9Q%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.

[neurolabusc]

@drmclem - dcm2niix does use 0002,0002 to discriminate these files. It would be nice to have Philips users confirm it is a robust solution.

[hippocampo]

Hi all, Thanks for your help on this- I just emailed Chris separately; happy to share phantom data I just acquired (Philips, MPRAGE and QSM), and can confirm it yields this error with the July/August 2019 dcm2niix release. Would like to help in case others are having the same issue. Best regards, Chris

…

On Wed, Aug 28, 2019 at 2:51 PM Chris Rorden ***@***.***> wrote: @drmclem <https://github.com/drmclem> - dcm2niix does use 0002,0002 to discriminate these files. It would be nice to have Philips users confirm it is a robust solution. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#328?email_source=notifications&email_token=ANAY3OXYVNLWZG3UIUNFYNDQG3CKPA5CNFSM4IREZ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5MDQWA#issuecomment-525875288>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANAY3ORHTIG4MIAYXYHJBL3QG3CKPANCNFSM4IREZ6MA> .

[captainnova]

Hi, dcm2niix handles them perfectly well. They had coincidentally popped up as a problem for me a couple of weeks ago, but it was in the dicom classification and storage part of our pipeline, not dcm2niix. Both the IM and XX files had been renamed to MR.(SOPinstanceUID), making the XX files only stand out by being RawImages that weren't images, because they have no pixel data. The local Phillips scientist soon confirmed that they were just XX files, though. I agree that 0002,0002 is sufficient for separating them out, but it's too vague to explain what they are when there's no context. Rob

…

On Wed, Aug 28, 2019, 1:51 PM Chris Rorden ***@***.***> wrote: @drmclem <https://github.com/drmclem> - dcm2niix does use 0002,0002 to discriminate these files. It would be nice to have Philips users confirm it is a robust solution. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#328?email_source=notifications&email_token=ADY6J2KZSFUFTMVU6X6OPHTQG3CKPA5CNFSM4IREZ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5MDQWA#issuecomment-525875288>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADY6J2ONBTLXOCDON7RIFX3QG3CKPANCNFSM4IREZ6MA> .q

[neurolabusc]

Thanks @hippocampo for the examples. The upcoming release does fine with these.