Following the instructions, I was able to run the real-time demo using programs under AFNI_data6/realtime_demos, but there are still a few things not clear to me.
My settings: - The three components (1) image monitor (using Dimon), (2) afni+ RT plugin, (3) real-time receiver are run on the same system (a Mac).
- I use Matlab installed on a separate PC to display feedback.
- Data from the scanner are deposited in real-time to a folder in the Mac.
Question 1. Do I have to always open three different Terminals to run the three afni components above? Will this work for real scanning as well or just for offline testing (given the following: AFNI_TRUSTHOST = localhost / AFNI_REALTIME_MP_HOST_PORT = localhost:53214 / Data from the scanner are deposited in real-time to a folder in the Mac)?
Question 2. Is there any concern about processing speed if the three components are run on the same computer?
Question 3. I see no options in the ‘realtime_receiver’ where I can set a path and a prefix for the text files that store ROI data (average or all voxels) that this program will output at each time point. By “path”, I mean I want to write data to a local folder that my Matlab program from the other PC can access instead of outputting data to the serial port. I tried setting AFNI_REALTIME_WRITEMODE=1 and AFNI_REALTIME_Root = /, but could not find text files anywhere. Did I do something not right?
Question 4. Also in terms of timing, what is the typical delay between the time an EPI.dcm is received and the time the corresponding text file for ROI data is generated?
Thank you for your helps.
- It is not necessary to open multiple terminal windows for
this, but it is a good idea, given that each program has its
own output streams, and that the programs do such different
things. At the scanners (that use them) here at the NIH,
these programs are started and stopped by scripts invoked
via the scanner automatically. There are no terminals.
Dimon and afni have been used for real-time scanning here at
NIH for well over a decade, it is not just for testing. In
fact, scanner usage was the main reason for writing Dimon.
And ‘afni’ has been doing real-time work at scanners since
realtime_receiver.py was written mostly as a template for
researchers to alter as they see fit. Are you actually
using this program for feedback? It is not a necessary
component of the real-time system.
- It is hard to say since you have to said exactly what
you will use it for. But again, this has been used for
many years, on slower computers than yours.
One concern might be network latency. You presumably have
something like an NFS mount to make data visible on your
mac. But that might not always keep up.
Writing from realtime_receiver.py to a text file should
be trivial, but I never added such an option. Just trace
where it is printed to the screen. We can discuss this if
it is not clear.
There is not a big delay, except that Dimon waits for
an entire volume to be acquired before passing it on.
Consider use of -sleep_init and -sleep_vol. Those would
define the likely delay in Dimon (it does NOT constantly
hit the directory to find any new files). Processing
takes little time, unless you start doing regression.
Thank you Rick for your explanations.
There was no doubt that the real-time system will work. I simply asked my questions to understand better how it works and see if I can simply start from those demo programs (I think this is easiest because I have the data sent directly in real time from the scanner to the Mac already, which is similar to running the demo).
I understand from your answer that using realtime_receiver.py is optional. So I think my first question is in case I am not using it, what should I do to interact with AFNI and the RT-plugin to extract the data at each time point? I guess this will require anyway a piece of afni scripts to change some variables in the RT-Options so the RT-plugin knows what to compute and write out, e.g. a text file that contains the ROI mean.
However, If using realtime_receiver is easier, I would rather go from there (But wait! there must be a reason you said it is not necessary for the real-time system).
With the goal to have a txt file generated after each TR, I am wading thru the realtime_receiver Python code now …
In ‘realtime_receiver.py’ and ‘compute_TR_data()’, it looks like ‘rti.extras[[i]][j]’ stores the mean of ROI [[i]] at time point [j]. And then this data at the said time point is appended to ‘self.TR_data’ under ‘process_one_TR()’.
I think what I should do next is add a few lines under ‘def process_demo_data(self):’ to allow for the last value in ‘self.TR_data’ written out to a txt file.
I am planning to add the following but not sure if it will work since I am not familiar with Python:
file_name = “timepoint”+str(length)+“.txt”
txt_file = open(file_name, “w”)
txt_file.write(“%s” % self.TR_data[length-1])
Maybe you can give me a better way to do.
Again, thank you very much for your helps.
With Matlab, I would expect that you could directly
set up a TCP connection to the realtime plugin (then
realtime_receiver.py would not be used). But if that
seems difficult, then having realtime_receiver.py
write to a text file that is read from Matlab should
Note that there is also a serial_helper program, if
you prefer coding in C to python. That is an older
program, but it does similar work.
When writing to a file, do not write to a different
text file per time point, just keep appending to the
same one (and flush the buffer so there is no delay).
For example, using:
fname = ‘realtime_output.txt’
txt_file = open(fname, ‘a’)
txt_file.write(‘%s’ % self.TR_data[length-1])
Note that the open() and close() do not need to be in
any loop. You could just write() and flush() each
Thanks a lot.
I managed to run the demo again with your suggestion for outputting the txt file but it didn’t seem to work. The txt file was generated but I didn’t see any data recorded and so the file remains at Zero bytes.
Another thing I don’t understand is when running realtime_receiver.py with -verb 2, I don’t see things that are supposed to be printed out when ‘self.verb>1’.
So could you pls take a look at the modified codes and tell me what the problem is.
I am sending them to you via email because they are not allowed as attachments here.
In case any are interested, there is now a -write_text_data
option available in realtime_receiver.py. That file stream is
flushed after every write, to keep it current.
One can write to stdout or stderr that way too, but it might
be important to be careful in doing so, as that could add
another layer of buffering on the output (so it might then
come out slowly, in larger blocks).