Forum

Notifications
Clear all

second run replaced by first run in procStream.output

6 Posts
2 Users
1 Likes
544 Views
Dimitris Askitis
Posts: 5
Topic starter
(@dim-ask)
Active Member
Joined: 11 months ago

I am not sure if this has come up before, but searching the forum a bit I could not find anything.

 

We have 2 runs per subject. I try to get the post-processed hb data through the output .mat files with a code like this:

 

load([homerDataFolder '/groupResults.mat']);
thisSubj = group.subjs(1);
thisSubj.Load;
for r = 1:2
   thisSubj.runs(r).Load;
   thisdc = thisSubj.runs(r).procStream.output.dc.GetDataTimeSeries('reshape')*10^6;
   % more code and stuff
end

However, in both iterations I get only the data for the first run, i.e. `thisdc` is exactly the same in both iterations of the loop (for r=2 I should get the dc for the second run). Basically, the `.run(1).procStream.output` and the `.run(2).procStream.output`are the same (both corresponding to the first run). The `.run(r).acquired` objects correspond to the correct runs for r = 1,2. This happens for all our subjects.

Am I missing something or this is a bug? Or is there a better way to export data than this?

Topic Tags
5 Replies
Meryem Yücel
Posts: 133
Admin
(@mayucel)
Estimable Member
Joined: 2 years ago

@dim-ask, if your code is precisely as above, you are overwriting the variable "thisdc", as it has no index.

Reply
Dimitris Askitis
Posts: 5
Topic starter
(@dim-ask)
Active Member
Joined: 11 months ago

Ok I figured out what is wrong, it is due to the original filenames. I am sorry for being unclear, in each loop I do some stuff and save the results at each iteration (% more code and stuff). My point was that the objects `.run(1).procStream.output` and `.run(2).procStream.output` are identical.

Now I see that the processed first run is actually missing completely from the output folder (see attached image; original snirf files above, output files below; there is only one "run-specific" output mat file instead of two). Because the original snirf files use filenames of the form "subjNo time date blockX etc.snirf" where X is 1 or 2, the output mat filenames corresponding to each run truncate at the "time"; thus the second run overwrites the first when exported by homer3, which in retrospect explains what happens when I try to read the data (both runs point to the same mat file).

It took time to realise because I was not aware of how the proper output file structure should be. So now I only have the averaged HRFs for each run and not the full processed timeseries. I guess all I can do is change the .snirf filenames and re-preprocess everything (it takes ages :/)

Reply
Meryem Yücel
Posts: 133
Admin
(@mayucel)
Estimable Member
Joined: 2 years ago

@dim-ask, what version of homer3 are you using? I have never had an instance where homer truncates the filename, the output file names are always exactly the same as the snirf file names. 

Reply
Dimitris Askitis
Posts: 5
Topic starter
(@dim-ask)
Active Member
Joined: 11 months ago

@mayucel I was using the latest version in the master branch, tried also the development branch.

I actually figured what happened. In line 178 of `ProcResultClass.m`, in the function `

SetFilename` it reads:
[pname, fname] = fileparts(filename);
 
 
but when run, the filename string is provided without a file extension (there is no .snirf extension in that part). Hence if the filename itself contains dots (as in my case containing dots part of the time of the experiment) matlab considers the last dot as the beginning of the file extension (as fname is the file name without the extension; fileparts accepts a third output argument for the extension). I guess it is not best practice in general to contain dots in a filename, but this was the filename our nirs system gave originally and never changed it. I guess a fix (other than changing filenames) would be
[pname, fname, ext] = fileparts(filename);
fname = [fname ext];
 
 though I am unsure if that breaks anything else, like if there could be a case where the actual extension part is non-empty. Or to provide the .snirf extension when the function there is called in the first place, but also unsure if that would break anything else. The issue was that it took very long to notice as there was no indicated error in the process and I did not know the whole data/file structure well.
 
 
 
Reply
Page 1 / 2
Share:
en_USEnglish