From waveflux at gmail.com Thu Sep 10 19:48:55 2020 From: waveflux at gmail.com (Tom Beaudry) Date: Thu, 10 Sep 2020 19:48:55 -0400 Subject: [Loris-dev] module / feature request Message-ID: Hi Everyone, I was wondering if anyone had interest in creating a module / test page that would be used for when people create instruments with php. Currently it's cumbersome to make them since i have to assign them to a fake project, and then add it to the DB, and then update the table every time i add a few lines to it to make sure i like the formatting. i'd be more than happy to do the testing / code review. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From ioannis at berkeley.edu Mon Sep 14 13:32:29 2020 From: ioannis at berkeley.edu (Ioannis Pappas) Date: Mon, 14 Sep 2020 10:32:29 -0700 Subject: [Loris-dev] Additional users, loris admin Message-ID: Dear Loris support. I hope this finds you well. I would like to ask you a question about creating and managing additional users. We would like to add a research assistant to help us with our project, specifically with the loris mysql operations. We already have a lorismysql user that handles parts of the operations but we would like to add another person to handle the day to day operations. What is the best way for the loris admin to do so? Should we create another lorisdbuser with basic rights granted e.g. (like in the website): GRANT ALTER, DROP, CREATE, UPDATE, INSERT, SELECT, DELETE, CREATE TEMPORARY TABLES, LOCK TABLES on $dbname.* to ?lorisdbuser'@'$dbhost' IDENTIFIED BY '$newpassword' WITH GRANT OPTION ; If this is the case can the loris admin check logs or undo changes made by a particular user? Are there problems if two loris users are signed in the same time? Best wishes, Ioannis -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogers at bic.mni.mcgill.ca Mon Sep 14 14:30:28 2020 From: rogers at bic.mni.mcgill.ca (Christine Rogers) Date: Mon, 14 Sep 2020 14:30:28 -0400 Subject: [Loris-dev] Additional users, loris admin In-Reply-To: References: Message-ID: Hi Ioannis, For multiple admins modifying the database back-end, we recommend making database "patch" files - typically several MySQL commands compiled in a single file - which can be reviewed and executed by a senior admin. These database patches can be committed in a github repo so that your project keeps a central record of them. We find this helps with transparency and trouble-shooting, in addition to giving additional oversight and allowing you to replicate a database configuration easily. Best practices also include creating and committing an additional "undo" patch alongside every database patch. If it's truly necessary to give both admins access to the same MySQL back-end, the setup you suggested is fine. As with any MySQL database, there's no real "undo" feature, and there shouldn't be any problem with 2 users logged in at the time, though coordinating to avoid modifying the same records/tables at the same time is probably a good idea. Best, Christine On Mon, Sep 14, 2020 at 1:32 PM Ioannis Pappas wrote: > Dear Loris support. > I hope this finds you well. > > I would like to ask you a question about creating and managing additional > users. > > We would like to add a research assistant to help us with our project, > specifically with the loris *mysql* operations. We already have a > lorismysql user that handles parts of the operations but we would like to > add another person to handle the day to day operations. > > What is the best way for the loris admin to do so? Should we create > another lorisdbuser with basic rights granted e.g. (like in the website): > > GRANT ALTER, DROP, CREATE, UPDATE, INSERT, SELECT, DELETE, CREATE > TEMPORARY TABLES, LOCK TABLES on $dbname.* to ?lorisdbuser'@'$dbhost' IDENTIFIED > BY '$newpassword' WITH GRANT OPTION ; > > If this is the case can the loris admin check logs or undo changes made by > a particular user? Are there problems if two loris users are signed in the > same time? > > Best wishes, > Ioannis > _______________________________________________ > Loris-dev mailing list > Loris-dev at bic.mni.mcgill.ca > https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev > -- christine.rogers at mcgill.ca McGill Centre for Integrative Neuroscience | MCIN.ca Montreal Neurological Institute McGill University | Montreal | Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: From ioannis at berkeley.edu Tue Sep 15 16:22:41 2020 From: ioannis at berkeley.edu (Ioannis Pappas) Date: Tue, 15 Sep 2020 13:22:41 -0700 Subject: [Loris-dev] upload_file.pl issue Message-ID: <824AFC06-675B-4939-9BD0-A37523EF8618@berkeley.edu> Hi Loris support. Another quick question (hopefully I don?t occupy a lot of your time during this pandemic). I am running the simple imaging upload pearl script like this: sudo -i -u lorisadmin /data/loris-mri/bin/mri/uploadNeuroDB/imaging_upload_file.pl -profile prod -upload_id 2 /data/loris/incoming/BR013_243782_V1.zip -verbose I think the script involves creating some directories because it leads to an error. The error is this: mkdir /tmp/ImagingUpload-13-7-7Z_JFF/BR013_243782_V1/BIAS_12ch_22: Permission denied at /usr/local/share/perl5/Archive/Zip/DirectoryMember.pm Do you guys think it has to do with my permission at /tmp or there is something else more sneaky? The /tmp folder doesn?t seem to have anything related to ImagingUpload[..] Thank you very much. Hopefully I don?t see more errors in the script. Best wishes, Ioannis -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolasbrossard.mni at gmail.com Tue Sep 15 16:44:04 2020 From: nicolasbrossard.mni at gmail.com (Nicolas Brossard) Date: Tue, 15 Sep 2020 16:44:04 -0400 Subject: [Loris-dev] upload_file.pl issue In-Reply-To: <824AFC06-675B-4939-9BD0-A37523EF8618@berkeley.edu> References: <824AFC06-675B-4939-9BD0-A37523EF8618@berkeley.edu> Message-ID: Hi Ioannis, No worries, we're here to help! On Unix systems, all users usually have permission to create directories in /tmp but just to be sure it'd be good idea to test that: just try % mkdir /tmp/hello and see if that works. If it does, then it means there's something more "sneaky" going on. You can try specifying an alternate temporary directory in which the upload script will write files: just type the following line in your environment file (located in the LORIS-MRI root directory): export TMPDIR=/my/alternate/temporary/dir Let me know if that helps. Cheers, Nicolas On Tue, Sep 15, 2020 at 4:23 PM Ioannis Pappas wrote: > Hi Loris support. > > Another quick question (hopefully I don?t occupy a lot of your time during > this pandemic). > > I am running the simple imaging upload pearl script like this: > > *sudo -i -u lorisadmin > /data/loris-mri/bin/mri/uploadNeuroDB/imaging_upload_file.pl > -profile prod -upload_id 2 > /data/loris/incoming/BR013_243782_V1.zip -verbose* > > I think the script involves creating some directories because it leads to > an error. The error is this: > > *mkdir /tmp/ImagingUpload-13-7-7Z_JFF/BR013_243782_V1/BIAS_12ch_22: > Permission denied at /usr/local/share/perl5/Archive/Zip/DirectoryMember.pm * > > Do you guys think it has to do with my permission at /tmp or there is > something else more sneaky? The /tmp folder doesn?t seem to have anything > related to *ImagingUpload*[..] > > Thank you very much. Hopefully I don?t see more errors in the script. > > Best wishes, > Ioannis > _______________________________________________ > 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: From ioannis at berkeley.edu Thu Sep 17 21:54:47 2020 From: ioannis at berkeley.edu (Ioannis Pappas) Date: Thu, 17 Sep 2020 18:54:47 -0700 Subject: [Loris-dev] upload_file.pl issue In-Reply-To: References: <824AFC06-675B-4939-9BD0-A37523EF8618@berkeley.edu> Message-ID: <34F068C0-4FD2-48F9-BFF6-E96892CDDF4D@berkeley.edu> Hi Nicolas. Apologies for the late reply but I wanted to look into it more with the kind help of Julie (our sys admin). For your information the exact error is this: Can't cd to (/tmp/ImagingUpload-15-8-Z8Hax5/) BR013_243782_V1: Permission denied at /data/loris-mri/bin/mri/uploadNeuroDB/NeuroDB/ImagingUpload.pm line 202. However, I can write in /tmp no problem e.g. [lorisadmin at loris ~]$ mkdir /tmp/ImagingUpload-15-8-Z8Hax5/ [lorisadmin at loris ~]$ ls -ld /tmp/ImagingUpload-15-8-Z8Hax5/ drwxrwxr-x 2 lorisadmin lorisadmin 4096 Sep 17 15:14 /tmp/ImagingUpload-15-8-Z8Hax5/ I think that the problem is that the perl script doesn?t make the temporary directory after unzipping in /tmp and then all of sudden it wants to cd there (that?s why I get ?permission denied? it just doesn?t exist). My .zip (BR013_243782_V1.zip) contains one folder (BR013_243782_V1) of .dcm files for simplicity. Should there be some internal structure there (or something else in terms of naming)? Thank you very much. Best wishes, Ioannis > On Sep 15, 2020, at 1:44 PM, Nicolas Brossard wrote: > > Hi Ioannis, > > No worries, we're here to help! > > On Unix systems, all users usually have permission to create directories in /tmp but just to be sure it'd be good idea to test that: just try > > % mkdir /tmp/hello > > and see if that works. If it does, then it means there's something more "sneaky" going on. > > You can try specifying an alternate temporary directory in which the upload script will write files: just type the following line in your environment file (located in the LORIS-MRI root directory): > > export TMPDIR=/my/alternate/temporary/dir > > > Let me know if that helps. > > > Cheers, > Nicolas > > > On Tue, Sep 15, 2020 at 4:23 PM Ioannis Pappas > wrote: > Hi Loris support. > > Another quick question (hopefully I don?t occupy a lot of your time during this pandemic). > > I am running the simple imaging upload pearl script like this: > > sudo -i -u lorisadmin /data/loris-mri/bin/mri/uploadNeuroDB/imaging_upload_file.pl -profile prod -upload_id 2 /data/loris/incoming/BR013_243782_V1.zip -verbose > > I think the script involves creating some directories because it leads to an error. The error is this: > > mkdir /tmp/ImagingUpload-13-7-7Z_JFF/BR013_243782_V1/BIAS_12ch_22: Permission denied at /usr/local/share/perl5/Archive/Zip/DirectoryMember.pm > > Do you guys think it has to do with my permission at /tmp or there is something else more sneaky? The /tmp folder doesn?t seem to have anything related to ImagingUpload[..] > > Thank you very much. Hopefully I don?t see more errors in the script. > > Best wishes, > Ioannis > _______________________________________________ > 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: From rogers at bic.mni.mcgill.ca Tue Sep 22 10:16:15 2020 From: rogers at bic.mni.mcgill.ca (Christine Rogers) Date: Tue, 22 Sep 2020 10:16:15 -0400 Subject: [Loris-dev] module / feature request In-Reply-To: References: Message-ID: Hi Tom, Thanks for the feature request - We discussed it in the last LORIS team meeting and added an Issue for it in the development roadmap here: https://github.com/aces/Loris/issues/7035 We'll be in touch for testing / code review - thanks for offering to collaborate on that, Christine On Thu, Sep 10, 2020 at 7:49 PM Tom Beaudry wrote: > Hi Everyone, > > I was wondering if anyone had interest in creating a module / test page > that would be used for when people create instruments with php. Currently > it's cumbersome to make them since i have to assign them to a fake project, > and then add it to the DB, and then update the table every time i add a > few lines to it to make sure i like the formatting. > > i'd be more than happy to do the testing / code review. > > Thanks, > Tom > > _______________________________________________ > Loris-dev mailing list > Loris-dev at bic.mni.mcgill.ca > https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev > -- christine.rogers at mcgill.ca McGill Centre for Integrative Neuroscience | MCIN.ca Montreal Neurological Institute McGill University | Montreal | Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolasbrossard.mni at gmail.com Tue Sep 22 14:14:55 2020 From: nicolasbrossard.mni at gmail.com (Nicolas Brossard) Date: Tue, 22 Sep 2020 14:14:55 -0400 Subject: [Loris-dev] upload_file.pl issue In-Reply-To: <34F068C0-4FD2-48F9-BFF6-E96892CDDF4D@berkeley.edu> References: <824AFC06-675B-4939-9BD0-A37523EF8618@berkeley.edu> <34F068C0-4FD2-48F9-BFF6-E96892CDDF4D@berkeley.edu> Message-ID: Hi Ioannis, Apologies for the late reply. Since you are getting a permission denied error, it means the directory exists *but* you cannot cd to it, otherwise you'd be getting a directory does not exist error. My guess is that when the archive is decompressed, the script creates directory /tmp/ImagingUpload-15-8-Z8Hax5/BR013_243782_V1 but the owner/permissions on that directory, once extracted, do not allow it to cd there afterwards. So... Are you running script imaging_upload.pl as root or as another user? Check the contents of the archive you are processing: what are the ownership/permissions on directory BR013_243782_V1? What do you get when you type the Unix command umask? Cheers, Nicolas On Thu, Sep 17, 2020 at 9:54 PM Ioannis Pappas wrote: > Hi Nicolas. > > Apologies for the late reply but I wanted to look into it more with the > kind help of Julie (our sys admin). For your information the exact error is > this: > > Can't cd to (/tmp/ImagingUpload-15-8-Z8Hax5/) BR013_243782_V1: Permission > denied > at /data/loris-mri/bin/mri/uploadNeuroDB/NeuroDB/ImagingUpload.pm line 202. > > However, I can write in /tmp no problem e.g. > > [lorisadmin at loris ~]$ mkdir /tmp/ImagingUpload-15-8-Z8Hax5/ > [lorisadmin at loris ~]$ ls -ld /tmp/ImagingUpload-15-8-Z8Hax5/ > drwxrwxr-x 2 lorisadmin lorisadmin 4096 Sep 17 15:14 > /tmp/ImagingUpload-15-8-Z8Hax5/ > > I think that the problem is that the perl script doesn?t make the > temporary directory after unzipping in /tmp and then all of sudden it wants > to cd there (that?s why I get ?permission denied? it just doesn?t exist). > My .zip (BR013_243782_V1.zip) contains one folder (BR013_243782_V1) of > .dcm files for simplicity. Should there be some internal structure there > (or something else in terms of naming)? > > Thank you very much. > > Best wishes, > Ioannis > > > > > > On Sep 15, 2020, at 1:44 PM, Nicolas Brossard < > nicolasbrossard.mni at gmail.com> wrote: > > Hi Ioannis, > > No worries, we're here to help! > > On Unix systems, all users usually have permission to create directories > in /tmp but just to be sure it'd be good idea to test that: just try > > % mkdir /tmp/hello > > and see if that works. If it does, then it means there's something more > "sneaky" going on. > > You can try specifying an alternate temporary directory in which the > upload script will write files: just type the following line in your > environment file (located in the LORIS-MRI root directory): > > export TMPDIR=/my/alternate/temporary/dir > > > Let me know if that helps. > > > Cheers, > Nicolas > > > On Tue, Sep 15, 2020 at 4:23 PM Ioannis Pappas > wrote: > >> Hi Loris support. >> >> Another quick question (hopefully I don?t occupy a lot of your time >> during this pandemic). >> >> I am running the simple imaging upload pearl script like this: >> >> *sudo -i -u lorisadmin >> /data/loris-mri/bin/mri/uploadNeuroDB/imaging_upload_file.pl >> -profile prod -upload_id 2 >> /data/loris/incoming/BR013_243782_V1.zip -verbose* >> >> I think the script involves creating some directories because it leads to >> an error. The error is this: >> >> *mkdir /tmp/ImagingUpload-13-7-7Z_JFF/BR013_243782_V1/BIAS_12ch_22: >> Permission denied at /usr/local/share/perl5/Archive/Zip/DirectoryMember.pm * >> >> Do you guys think it has to do with my permission at /tmp or there is >> something else more sneaky? The /tmp folder doesn?t seem to have anything >> related to *ImagingUpload*[..] >> >> Thank you very much. Hopefully I don?t see more errors in the script. >> >> Best wishes, >> Ioannis >> _______________________________________________ >> 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: From AMORALESPINZON at bwh.harvard.edu Fri Sep 25 16:29:54 2020 From: AMORALESPINZON at bwh.harvard.edu (Morales Pinzon, Alfredo) Date: Fri, 25 Sep 2020 20:29:54 +0000 Subject: [Loris-dev] Different StudyInstanceUIDs In-Reply-To: References:

Message-ID: Hi Nicolas, We are working on this issue but a question. Sometimes studies have dual echo and dynamic sequences (e.g., a dual-echo PD/T2 sequence produces a PD-weighted image and a T2-weighted image together) that result in in two sequences sharing the same ? SeriesInstanceUID?. This seems to be quite common, don?t you have a workaround already available in LORIS? Best, Alfredo. On May 4, 2020, at 8:50 AM, Morales Pinzon, Alfredo > wrote: Hi Nicolas, Thank you for your answer. We?ll handle these cases based on LORIS requirements. Best, Alfredo. On May 1, 2020, at 1:39 PM, Nicolas Brossard > wrote: External Email - Use Caution Hi Alfredo, You cannot insert in the database a scan archive containing two different study UIDs: all the scans inside the archive must have the same study UID, that's a LORIS requirement. I suggest you split your original archive into two archives, based on their study UIDs, and then upload/insert both. You could also "hack" you original archive so that all study UIDs are identical but I am not a big fan of this strategy since you are altering the original data you got from the scanner... Best, Nicolas p.s: if you are not comfortable splitting archives, I can help On Fri, May 1, 2020 at 11:03 AM Morales Pinzon, Alfredo > wrote: Dear LORIS-Dev Team, In the IPMSA project some scans have acquisitions with two different StudyInstanceUIDs. This leads to an error in the insertion pipeline. The reason for having two different StudyInstanceUIDs is because some acquisitions failed QC and were re-acquired and added to the same study but with a different StudyInstanceUIDs. Here are our questions: 1. Would it be possible to insert a study having acquisitions with two different StudyInstanceUIDs? 2. If we were to change the StudyInstanceUIDs to have only one in a study, would LORIS insert they study with acquisitions having different scan date? Thank you for your help. Regards, Alfredo. 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: From nicolasbrossard.mni at gmail.com Fri Sep 25 16:36:14 2020 From: nicolasbrossard.mni at gmail.com (Nicolas Brossard) Date: Fri, 25 Sep 2020 16:36:14 -0400 Subject: [Loris-dev] Different StudyInstanceUIDs In-Reply-To: References:

Message-ID: Hi Alfredo, I am afraid what I said earlier was not 100% correct: each SerieInstanceUID/echo time combo has to be unique. So yeah, you could have two DICOM files associated with different modalities that have identical SeriesInstanceUIDs (in that case though, it is expected that the echo times will be different). I am guessing the studies you are referring to in your email fit that requirement, right? Apologies for the confusion. Best, Nicolas On Fri, Sep 25, 2020 at 4:29 PM Morales Pinzon, Alfredo < AMORALESPINZON at bwh.harvard.edu> wrote: > Hi Nicolas, > > We are working on this issue but a question. Sometimes studies have dual > echo and dynamic sequences (e.g., a dual-echo PD/T2 sequence produces a > PD-weighted image and a T2-weighted image together) that result in in two > sequences sharing the same ? SeriesInstanceUID?. This seems to be quite > common, don?t you have a workaround already available in LORIS? > > Best, > Alfredo. > > On May 4, 2020, at 8:50 AM, Morales Pinzon, Alfredo < > AMORALESPINZON at BWH.HARVARD.EDU> wrote: > > Hi Nicolas, > > Thank you for your answer. We?ll handle these cases based on LORIS > requirements. > > Best, > Alfredo. > > On May 1, 2020, at 1:39 PM, Nicolas Brossard < > nicolasbrossard.mni at gmail.com> wrote: > > External Email - Use Caution > > Hi Alfredo, > > You cannot insert in the database a scan archive containing two different > study UIDs: all the scans inside the archive must have the same study UID, > that's a LORIS requirement. I suggest you split your original archive into > two archives, based on their study UIDs, and then upload/insert both. You > could also "hack" you original archive so that all study UIDs are identical > but I am not a big fan of this strategy since you are altering the original > data you got from the scanner... > > > Best, > Nicolas > > p.s: if you are not comfortable splitting archives, I can help > > On Fri, May 1, 2020 at 11:03 AM Morales Pinzon, Alfredo < > AMORALESPINZON at bwh.harvard.edu> wrote: > >> Dear LORIS-Dev Team, >> >> In the IPMSA project some scans have acquisitions with two different StudyInstanceUIDs. >> This leads to an error in the insertion pipeline. The reason for having two >> different StudyInstanceUIDs is because some acquisitions failed QC and >> were re-acquired and added to the same study but with a different StudyInstanceUIDs. Here >> are our questions: >> >> 1. Would it be possible to insert a study having acquisitions with >> two different StudyInstanceUIDs? >> >> 2. If we were to change the StudyInstanceUIDs to have only one in a >> study, would LORIS insert they study with acquisitions having different >> scan date? >> >> Thank you for your help. >> >> Regards, >> Alfredo. >> >> 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: From nicolasbrossard.mni at gmail.com Wed Sep 30 09:30:47 2020 From: nicolasbrossard.mni at gmail.com (Nicolas Brossard) Date: Wed, 30 Sep 2020 09:30:47 -0400 Subject: [Loris-dev] Different StudyInstanceUIDs In-Reply-To: References:

Message-ID: Hi Samson, This will not be sufficient as LORIS would expect in this case different SeriesInstanceUID/echo time combinations for these images...Unfortunately, I don't think there is any way around this. Best, Nicolas On Fri, Sep 25, 2020 at 4:47 PM Samson Antel wrote: > Hi Nicolas, > > The dual echo PD/T2 sequences we are dealing with will indeed have > distinct echo times. > > We also have some MT-On/MT-Off image pairs that were acquired on Philips > scanners using a dynamic sequence. In those cases, the images will share a > SeriesInstanceUID _and_ an echo time. However, they will contain distinct > InstanceNumbers and TemporalPositionIdentifiers; will that be sufficient > for LORIS? > > Thanks, > Samson > > > On Fri, Sep 25, 2020 at 4:37 PM Nicolas Brossard < > nicolasbrossard.mni at gmail.com> wrote: > >> Hi Alfredo, >> >> I am afraid what I said earlier was not 100% correct: each >> SerieInstanceUID/echo time combo has to be unique. So yeah, you could have >> two DICOM files associated with different modalities that have identical >> SeriesInstanceUIDs (in that case though, it is expected that the echo times >> will be different). I am guessing the studies you are referring to in your >> email fit that requirement, right? >> >> Apologies for the confusion. >> >> >> Best, >> Nicolas >> >> >> On Fri, Sep 25, 2020 at 4:29 PM Morales Pinzon, Alfredo < >> AMORALESPINZON at bwh.harvard.edu> wrote: >> >>> Hi Nicolas, >>> >>> We are working on this issue but a question. Sometimes studies have dual >>> echo and dynamic sequences (e.g., a dual-echo PD/T2 sequence produces a >>> PD-weighted image and a T2-weighted image together) that result in in >>> two sequences sharing the same ? SeriesInstanceUID?. This seems to be >>> quite common, don?t you have a workaround already available in LORIS? >>> >>> Best, >>> Alfredo. >>> >>> On May 4, 2020, at 8:50 AM, Morales Pinzon, Alfredo < >>> AMORALESPINZON at BWH.HARVARD.EDU> wrote: >>> >>> Hi Nicolas, >>> >>> Thank you for your answer. We?ll handle these cases based on LORIS >>> requirements. >>> >>> Best, >>> Alfredo. >>> >>> On May 1, 2020, at 1:39 PM, Nicolas Brossard < >>> nicolasbrossard.mni at gmail.com> wrote: >>> >>> External Email - Use Caution >>> >>> Hi Alfredo, >>> >>> You cannot insert in the database a scan archive containing two >>> different study UIDs: all the scans inside the archive must have the same >>> study UID, that's a LORIS requirement. I suggest you split your original >>> archive into two archives, based on their study UIDs, and then >>> upload/insert both. You could also "hack" you original archive so that all >>> study UIDs are identical but I am not a big fan of this strategy since you >>> are altering the original data you got from the scanner... >>> >>> >>> Best, >>> Nicolas >>> >>> p.s: if you are not comfortable splitting archives, I can help >>> >>> On Fri, May 1, 2020 at 11:03 AM Morales Pinzon, Alfredo < >>> AMORALESPINZON at bwh.harvard.edu> wrote: >>> >>>> Dear LORIS-Dev Team, >>>> >>>> In the IPMSA project some scans have acquisitions with two different StudyInstanceUIDs. >>>> This leads to an error in the insertion pipeline. The reason for having two >>>> different StudyInstanceUIDs is because some acquisitions failed QC and >>>> were re-acquired and added to the same study but with a different StudyInstanceUIDs. Here >>>> are our questions: >>>> >>>> 1. Would it be possible to insert a study having acquisitions with >>>> two different StudyInstanceUIDs? >>>> >>>> 2. If we were to change the StudyInstanceUIDs to have only one in a >>>> study, would LORIS insert they study with acquisitions having different >>>> scan date? >>>> >>>> Thank you for your help. >>>> >>>> Regards, >>>> Alfredo. >>>> >>>> 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: