[Loris-dev] LORIS Error: The target directory does not contain a single DICOM file.
Cecile Madjar
cecile.madjar at mcin.ca
Mon Dec 2 14:14:07 EST 2019
Hi Alfredo,
see below in blue for answers to the different cases.
Hope that will help,
Cécile
On Mon, Dec 2, 2019 at 1:33 PM Morales Pinzon, Alfredo <
AMORALESPINZON at bwh.harvard.edu> wrote:
> Hi Cécile,
>
> Apparently the changes we made, fixed StudyInstanceUID and StudyID, worked
> as we don’t see the error “The target directory does not contain a single
> DICOM file” anymore. However, now I am getting the following error for all
> the cases that were fixed:
>
> ----------------------------------
> Running now the following command: /xxx/bin/mri/uploadNeuroDB/
> imaging_upload_file.pl -profile prod -upload_id 20925
> /yyy/AAA10001_111222_baseline.tar.gz -verbose Spool message is: The Scan
> for the uploadID 20925 has already been run with tarchiveID: 20738. To
> continue with the rest of the insertion pipeline, please run tarchiveLoader
> from a terminal as follows: /xxx/bin/mri/uploadNeuroDB/tarchiveLoader
> -globLocation -profile prod
> /yyy/data/tarchive/DCM_2011-08-19_ImagingUpload-9-52-PPfWPd.tar -verbose
> ----------------------------------
>
The important message is "The Scan for the uploadID 20925 has already been
run with tarchiveID: 20738.". This means that there is already a study that
was inserted in the tarchive tables that is using the same StudyInstanceUID
as the one being uploaded. So you would need to generate new *unique*
StudyInstanceUID per DICOM study you wish to upload (since as I understand,
that field has been erased for ethical purposes). Each StudyInstanceUID has
to be unique otherwise the pipeline thinks you are trying to upload a
duplicate dataset.
FYI - The terminal output with the tarchiveLoader command is actually
suggesting to run the tarchiveLoader on the previous upload that was found
to have the same StudyInstanceUID (and that has tarchiveID=20738 associated
with the previous upload).
When I run the suggested command line I get the following message:
>
> ----------------------------------
> $ /xxx/bin/mri/uploadNeuroDB/tarchiveLoader -globLocation -profile prod
> /yyy/data/tarchive/DCM_2011-08-19_ImagingUpload-9-52-PPfWPd.tar -verbose
>
> md5sum /yyy/data/tarchive/DCM_2011-08-19_ImagingUpload-9-52-PPfWPd.tar
>
> PSCID is: AAA10001
> CandID id: 111222
> visit_label is: baseline
> candidate id 111222
> PSCID is: AAA10001
> CandID id: 111222
> visit_label is: baseline
> WARNING: Age was not numeric!!
> WARNING: Age was not numeric!!
> WARNING: Age was not numeric!!
> WARNING: Age was not numeric!!
> WARNING: Age was not numeric!!
> Error reading file.
> Mincinfo_wrapper: crashed while running mincinfo (termination status=256)
> Error reading file.
> Mincinfo_wrapper: crashed while running mincinfo (termination status=256)
> Error reading file.
> Mincinfo_wrapper: crashed while running mincinfo (termination status=256)
> Error reading file.
> Mincinfo_wrapper: crashed while running mincinfo (termination status=256)
> Error reading file.
> Mincinfo_wrapper: crashed while running mincinfo (termination status=256)
>
> Number of MINC files that will be considered for inserting into the
> database: 0
>
> No data could be converted into valid MINC files. Localizers will not be
> considered!
> ----------------------------------
>
> I tested the conversion of one the DICOM folder to minc and then executed
> mincinfo but I didn’t get any errors.
>
> Do you know why this might be happening?
>
Is it possible that the encoding of the DICOMs are not "little endian
explicit" by any chance? If that is the case, you would need to convert
them so that the encoding is "little endian explicit".
FYI: command to convert the encoding of the DICOMs
find <root_of_my_DICOM_files_directory> -type f | xargs -i
dcmconv --write-xfer-little {} {}
Once done, you would need to remove the partial upload and reupload. This
can be done using the delete_imaging_upload.pl script in the tools
directory. Run the -h option and you will see the explanation on how this
script can be run and detailed information about the options.
Is there an issue with the files created by LORIS in the first attempt I
> tried to upload these images (see uploadId 20925)?
>
> Let me know if you need more information from my side to help overcome
> this issue.
>
> Best regards,
> Alfredo.
>
> On Nov 25, 2019, at 10:25 AM, Morales Pinzon, Alfredo <
> AMORALESPINZON at BWH.HARVARD.EDU> wrote:
>
> Hi Cécile,
>
> Thank you for your prompt response. We will make the changes, try again,
> and report back to this thread.
>
> Best regards,
> Alfredo.
>
> On Nov 25, 2019, at 10:06 AM, Cecile Madjar <cecile.madjar at mcin.ca> wrote:
>
> External Email - Use Caution
>
> Hi Alfredo,
>
> Indeed, the StudyInstanceUID needs to have a value for the insertion
> pipeline to work so that could explain the no DICOM found error.
>
> FYI - StudyInstanceUID also needs to be unique for each uploaded study
> otherwise insertion in the tarchive tables would fail with the error: "the
> study has already been uploaded"
>
> Hope this helps,
>
> Cécile
>
> On Mon, Nov 25, 2019 at 10:02 AM Morales Pinzon, Alfredo <
> AMORALESPINZON at bwh.harvard.edu> wrote:
>
>> Dear LorisDev team,
>>
>> I am batch uploading images to imaging visits using the script
>> batch_uploads_imageuploader but for some images I get the following error:
>>
>> *The target directory does not contain a single DICOM file.*
>>
>> I had seen this error previously due to missing dicom fields like StudyID
>> (0020,0010) and ImagePositionPatient (0020,0032). However, after checking
>> these particular dicom fields and setting StudyID it to '0' I am still
>> getting the same error. What other dicom fields should I check?
>>
>> Is there a log where I can exactly find the error? Does the
>> "StudyInstanceUID" need to have a value?
>>
>> I'm pasting the dcmdump of a dicom at the end of this email in case this
>> might help figuring out what is the issue.
>>
>> I am using LORIS v at 20.1.1.
>>
>> Thank you in advance for your help.
>>
>> Best regards,
>> Alfredo.
>>
>>
>> --------------------------------------------------------------------------------------
>>
>> # Dicom-File-Format
>>
>> # Dicom-Meta-Information-Header
>> # Used TransferSyntax: Little Endian Explicit
>> (0002,0000) UL 230 # 4, 1
>> FileMetaInformationGroupLength
>> (0002,0001) OB 00\01 # 2, 1
>> FileMetaInformationVersion
>> (0002,0002) UI =MRImageStorage # 26, 1
>> MediaStorageSOPClassUID
>> (0002,0003) UI
>> [1.2.826.0.1.3680043.2.1125.1.62497394598874749597838823223385071] # 64, 1
>> MediaStorageSOPInstanceUID
>> (0002,0010) UI =LittleEndianImplicit # 18, 1
>> TransferSyntaxUID
>> (0002,0012) UI [1.2.276.0.7230010.3.0.3.6.0] # 28, 1
>> ImplementationClassUID
>> (0002,0013) SH [OFFIS_DCMTK_360] # 16, 1
>> ImplementationVersionName
>> (0002,0016) AE [GDCM/ITK 3.17.0] # 16, 1
>> SourceApplicationEntityTitle
>>
>> # Dicom-Data-Set
>> # Used TransferSyntax: Little Endian Implicit
>> (0008,0008) CS [DERIVED\SECONDARY] # 18, 2 ImageType
>> (0008,0016) UI =MRImageStorage # 26, 1
>> SOPClassUID
>> (0008,0018) UI
>> [1.2.826.0.1.3680043.2.1125.1.62497394598874749597838823223385071] # 64, 1
>> SOPInstanceUID
>> (0008,0020) DA [20000101] # 8, 1 StudyDate
>> (0008,0021) DA [20000101] # 8, 1
>> SeriesDate
>> (0008,0022) DA [20000101] # 8, 1
>> AcquisitionDate
>> (0008,0030) TM (no value available) # 0, 0 StudyTime
>> (0008,0031) TM [085517] # 6, 1
>> SeriesTime
>> (0008,0032) TM [085517] # 6, 1
>> AcquisitionTime
>> (0008,0060) CS [MR] # 2, 1 Modality
>> (0008,0070) LO [AAABBBCCC] # 6, 1
>> Manufacturer
>> (0008,0104) LO [Anonymized] # 10, 1
>> CodeMeaning
>> (0008,103e) LO [t1c] # 4, 1
>> SeriesDescription
>> (0008,1090) LO [nifti2dicom] # 12, 1
>> ManufacturerModelName
>> (0010,0010) PN [10041] # 6, 1
>> PatientName
>> (0010,0020) LO [10041] # 6, 1 PatientID
>> (0010,0021) LO [Anonymized] # 10, 1
>> IssuerOfPatientID
>> (0010,0030) DA [19650101] # 8, 1
>> PatientBirthDate
>> (0010,0040) CS [Anonymized] # 10, 1
>> PatientSex
>> (0010,1010) AS [Anonymized] # 10, 1
>> PatientAge
>> (0010,1030) DS (no value available) # 0, 0
>> PatientWeight
>> (0010,2150) LO [Anonymized] # 10, 1
>> CountryOfResidence
>> (0010,2152) LO [Anonymized] # 10, 1
>> RegionOfResidence
>> (0010,21f0) LO [Anonymized] # 10, 1
>> PatientReligiousPreference
>> (0012,0050) LO [baseline] # 8, 1
>> ClinicalTrialTimePointID
>> (0012,0062) CS [Yes] # 4, 1
>> PatientIdentityRemoved
>> (0012,0063) LO [Genentech] # 10, 1
>> DeidentificationMethod
>> (0018,0050) DS [3] # 2, 1
>> SliceThickness
>> (0018,0088) DS [3] # 2, 1
>> SpacingBetweenSlices
>> (0020,000d) UI (no value available) # 0, 0
>> StudyInstanceUID
>> (0020,000e) UI
>> [1.2.826.0.1.3680043.2.1143.2737712182581015462892759360372011946] # 64, 1
>> SeriesInstanceUID
>> *(0020,0010) SH [0] # 2, 1 StudyID*
>> (0020,0011) IS [901] # 4, 1
>> SeriesNumber
>> (0020,0012) IS [1] # 2, 1
>> AcquisitionNumber
>> (0020,0013) IS [1] # 2, 1
>> InstanceNumber
>> (0020,0020) CS [L\R] # 4, 2
>> PatientOrientation
>> (0020,0032) DS [-116.48152160645\-118.93698120117\-275.82513427734] #
>> 50, 3 ImagePositionPatient
>> (0020,0037) DS [1\0\0\0\1\0] # 12, 6
>> ImageOrientationPatient
>> (0020,0052) UI
>> [1.2.826.0.1.3680043.2.1143.263896814292546686535778822643473818] # 64, 1
>> FrameOfReferenceUID
>> (0028,0002) US 1 # 2, 1
>> SamplesPerPixel
>> (0028,0004) CS [MONOCHROME2] # 12, 1
>> PhotometricInterpretation
>> (0028,0010) US 256 # 2, 1 Rows
>> (0028,0011) US 256 # 2, 1 Columns
>> (0028,0030) DS [1\1] # 4, 2
>> PixelSpacing
>> (0028,0100) US 16 # 2, 1
>> BitsAllocated
>> (0028,0101) US 16 # 2, 1
>> BitsStored
>> (0028,0102) US 15 # 2, 1 HighBit
>> (0028,0103) US 1 # 2, 1
>> PixelRepresentation
>> (0032,1033) LO [Anonymized] # 10, 1
>> RequestingService
>> (0040,0280) ST [Anonymized] # 10, 1
>> CommentsOnThePerformedProcedureStep
>> (0400,0563) LO [Anonymized] # 10, 1
>> ModifyingSystem
>> (0400,0564) LO [Anonymized] # 10, 1
>> SourceOfPreviousValues
>> (0400,0565) CS [Anonymized] # 10, 1
>> ReasonForTheAttributeModification
>> (1110,21b0) ?? 0a\00 # 2, 1 Unknown
>> Tag & Data
>> (7fe0,0010) OW
>> 0000\0000\0000\0000\0000\0000\0000\0000\0000\0000\0000\0000\0000... #
>> 131072, 1 PixelData
>>
>> The information in this e-mail is intended only for the person to whom it
>> is
>> addressed. If you believe this e-mail was sent to you in error and the
>> e-mail
>> contains patient information, please contact the Partners Compliance
>> HelpLine at
>> http://www.partners.org/complianceline . If the e-mail was sent to you
>> in error
>> but does not contain patient information, please contact the sender and
>> properly
>> dispose of the e-mail.
>> _______________________________________________
>> Loris-dev mailing list
>> Loris-dev at bic.mni.mcgill.ca
>> https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bic.mni.mcgill.ca/pipermail/loris-dev/attachments/20191202/4f3e7fc0/attachment-0001.html>
More information about the Loris-dev
mailing list