NITRC mri_reface Forum: open-discussion

RE: matlab version

Christopher Schwarz — Fri, 29 May 2026 13:56:09 GMT

No, the matlab runtime needs to match the one it was compiled with, but please remember this is the free Matlab runtime, not actual Matlab that you would have to pay for. If you have a system install of a different version, you can still install the needed runtime for this in a separate location.
Chris Schwarz

matlab version

evaneldridge — Fri, 29 May 2026 13:50:35 GMT

Hi 
 
I am trying to use the mri_reface executable and just wanted to ask whether the matlab version can be higher than the one specified?

RE: Changing location for working files

Paul Wright — Tue, 19 May 2026 9:24:40 GMT

Originally posted by Christopher Schwarz:
<blockquote>
If your $MCR_CACHE_ROOT on $scratch_dir is shared across multiple jobs, you may run into difficulties where two jobs start at roughly the same time, causing one to delete the cache that the other just unpacked. Ideally you would seed time or jobID into the scratch_dir name to avoid collisions, but 350MB x n jobs may be more scratch than your node has available. It's an unfortunately tricky balance inherent to deployed matlab applications.
</blockquote>
Yes, I currently have:
<div>
<div>scratch_dir=/scratch0/${USER}/mri_reface_${JOB_ID}.${SGE_TASK_ID}</div>
<div> </div>
<div>As you say, that means I have multiple copies of the MCR cache, even if they are short-lived. I agree it's a balancing act!</div>
</div>

RE: Changing location for working files

Christopher Schwarz — Fri, 15 May 2026 13:28:49 GMT

If your $MCR_CACHE_ROOT on $scratch_dir is shared across multiple jobs, you may run into difficulties where two jobs start at roughly the same time, causing one to delete the cache that the other just unpacked. Ideally you would seed time or jobID into the scratch_dir name to avoid collisions, but 350MB x n jobs may be more scratch than your node has available. It's an unfortunately tricky balance inherent to deployed matlab applications.

Our nodes don't have enough scratch to avoid overlaps, so we have this in a wrapper script:

while ! stat "$MCR_CACHE_ROOT" > /dev/null 2>&1; do
echo "Waiting for $MCR_CACHE_ROOT to be accessible..."
sleep 1 # Wait 1 second before checking again
done

Changing location for working files

Paul Wright — Wed, 13 May 2026 13:27:20 GMT

I'm running mri_reface on a cluster via Sun Grid Engine. I want to use scratch space for working files instead of the /tmp/$tempdir and ~/.mcrCache9.12 cache directories mri_reface uses by default.
You can achieve this by setting environment variables to something like:
TMPDIR="${scratch_dir}/tmp"
MCR_CACHE_ROOT="${scratch_dir}/mcr_cache"
I am running using singularity, so I set these using the `--env` argument in the `singularity run` command.
It's probably not a big deal, since mri_reface does not write much to /tmp, and I think it deletes it afterwards, and the MCR cache is about 350 MB, not enough to threaten even the small quota my home directory gets on our server. I have done any rigorous testing to see if it improves speed on my cluster. I thought I'd share in case it saves anyone else a little time.

RE: Trying Docker version

Christopher Schwarz — Mon, 09 Dec 2024 19:04:16 GMT

We ask that people do not redistribute the program on Dockerhub. Any versions on Dockerhub are not official. Please use the official Docker images hosted here.

RE: Trying Docker version

Sun Sar — Mon, 09 Dec 2024 19:00:13 GMT

Hello,
Just wondering if there is still no Docker image on DockerHub

RE: Trying Docker version

Christopher Schwarz — Fri, 17 Nov 2023 22:45:51 GMT

Originally posted by Adam Raikes:
<blockquote>
I haven't seen any resolution to this issue, but wanted to give my experience.
I created a Singularity container from the current Docker image for use with the system I have access to. Binding the updated ADIR_nii2dicom.py as /usr/bin/mlrtapp/image_handling/ADIR_nii2dicom.py solved this problem for us.
</blockquote>
Adam,
I'm sorry you had to do that. I was waiting for confirmation from Dianne and largely forgot about this.
Today I released a new version 0.3.3 that includes this fix (and some other unrelated ones).
Thanks,
Chris

RE: Trying Docker version

Adam Raikes — Thu, 02 Nov 2023 18:44:24 GMT

I haven't seen any resolution to this issue, but wanted to give my experience.
I created a Singularity container from the current Docker image for use with the system I have access to. Binding the updated ADIR_nii2dicom.py as /usr/bin/mlrtapp/image_handling/ADIR_nii2dicom.py solved this problem for us.

RE: Trying Docker version

Christopher Schwarz — Tue, 13 Jun 2023 0:30:34 GMT

Dianne,
Thanks for posting the steps you followed. I followed your steps to create the updated image and I called it mri_reface2, as you did. I then exited and went into mri_reface2 in a new terminal and verified that the updated copy of ADIR_nii2dicom.py was still there.
$ docker run -ti mri_reface2 root@55793afdac4c:/usr/bin/mlrtapp/image_handling# grep xml ADIR_nii2dicom.py              dcmfiles_temp = [i for i in dcmfiles_temp if not re.search(r'\.xml$', i) ]
The above grep result matches the code I added newly in the revision I attached previously. 
I created a new run_mri_reface_docker.sh  $ cp run_mri_reface_docker.sh run_mri_reface2_docker.sh
Which I then edited to replace mri_reface with mri_reface2 in BOTH docker lines: 96 docker run -ti --mount type=bind,src\=$tmpdir,target=$tmpdir mri_reface2 run_mri_reface.sh $input $output_tmp ${input_array[@]:2 } 97  98 docker run -ti --mount type=bind,src=$tmpdir,target=$tmpdir mri_reface2 chmod =777 -R $tmpdi
From there I ran it two ways. One was using run_mri_reface2_docker.sh:
$ ./run_mri_reface2_docker.sh dcm_t1 outExternal -imType T1
[...] ADIR_ReFace finished in: 17.9749 minutes Finished writing 176 dcm files to outDir: /tmp/tmp.A1n3Oz3nih/outputs/dcm Including custom code sequence: code: "replace_recognizable" meaning: "Replace face, ears, and artifacts in air" designator: "mri_reface" version: "0.3.2" Finished. De-faced DICOM was written to /tmp/tmp.A1n3Oz3nih/outputs/dcm. This DICOM metadata is NOT otherwise de-identified. Only de-facing was performed. If you need the meta-data de-identified also, you should run it through your preferred DICOM de-identification software.
When it completed, I opened outExternal/dcm and the files are present and successful.
I also tried running the whole thing inside docker, rather than using run_mri_reface2_docker.sh
$ chmod a+wrX . $ docker run -ti --mount type=bind,src=${PWD},target=/host mri_reface2 root@23aadd07062d:/usr/bin/mlrtapp/image_handling# cd /host root@23aadd07062d:/host# run_mri_reface.sh dcm_t1 out2 -imType T1
[...] ADIR_ReFace finished in: 17.8532 minutes Finished writing 176 dcm files to outDir: out2/dcm Including custom code sequence: code: "replace_recognizable" meaning: "Replace face, ears, and artifacts in air" designator: "mri_reface" version: "0.3.2" Finished. De-faced DICOM was written to out2/dcm. This DICOM metadata is NOT otherwise de-identified. Only de-facing was performed. If you need the meta-data de-identified also, you should run it through your preferred DICOM de-identification software. root@23aadd07062d:/host# exit
Then I checked out2/dcm. The dcm files are present and valid.
I tried again using your dicom directory name, just in case that had something to do with it:
$ ./run_mri_reface2_docker.sh T1_mprage_1mm_13/ out -imType T1
And that was also successful. 
From here, I was at a bit of a loss. My best guess was that there's a mistake in one of the steps you didn't show me. Maybe you could verify that your mri_reface2 image has the updated code (via the above grep example), and you could verify that your run_mri_reface2_docker.sh replaced 'mri_reface' in BOTH 'docker' commands with 'mri_reface2'? 
Toward that hypothesis, I looked back at the start of your pdf and I think you may not have replaced the correct file/path.  /usr/bin/mlrtapp has ADIR_nii2dicom, a program. It also has a subdirectory called image_handling. Inside image_handling is ADIR_nii2dicom.py. I intended for you to replace /usr/bin/mlrtapp/image_handling/ADIR_nii2dicom.py, NOT /usr/bin/mlrtapp/ADIR_nii2dicom, but it looks like you replaced ADIR_nii2dicom. I surprised that didn't up with a new error message when you tried to run it that way, but otherwise I think this explains why it's now working for me, but not you. 
Can you please try starting again from the original mri_reface image and copy the new ADIR_nii2dicom.py into image_handling, this time? From there, I hope it will work for you. Please let me know. Sorry my original instructions weren't clear enough about which file to replace. 
Thanks, Chris