Non-volumetric mesoscope data processing

[CBroz1]

I'm working with a team that has mesoscope data with 4 ROIs across 2 planes, recorded over time, and fixed z-depths. So far, images have been processed by splitting tifs into their respective ROIs before running Suite2p. I'd like to be able to run Suite2p as described here, but I'm running into issues.

1. Can Suite2p handle my case?
2. I tried using mesoscope_json_from_scanimage.m to generate input parameters
   1. This line relies on a function and file I don't have. Maybe this portion should be parameterized under a boolean 'perform motion correction' flag? Would you be interested in a PR to this effect?
   2. With only 1 z-depth, my headers don't have SI.hFastZ.userZs. In other code, we use unique values of the json metadata "zs" to number of depths. I can hardcode nplanes, but I think I need to make adjustments to cXY, cXY, mu and imin to get the proper calculations for lines parameter. Any suggestions for making revisions there? Any suggestions for documentation on these parameters?

Thanks for your help!!

[carsen-stringer]

consolidating issues: #802

[CBroz1]

Thanks for linking! This notebook has been helpful today. One difficulty in my case is that I have 3 ROIs at one z-depth, and 1 ROI at a second z-depth. I'm thinking this is an edge-case, as it doesn't align with the some baked in assumptions of nplanes * nrois => ops['nplanes'].

I'll dive into the weeds on mesoscan_to_binary - maybe I could adjust it to accommodate my case.

[carsen-stringer]

thanks @CBroz1 ! yeah I've never actually dealt with that case myself

[samupicard]

Hi suite2p team, at cortex lab we are dealing with a similar case: in scanimage we define a certain number of planes over which individual ROIs have been defined at discrete depths: hence, some ROIs may have one plane, others more. We therefore cannot assume that nplanes * nrois => ops['nplanes']. Instead we represent these data as N fields-of-view (what suite2p would write out as plane0, plane1, ... planeN), where each FOV(k) is a unique combination of plane(i) with ROI(j).

We have written code to parse the tiff headers and figure out the individual lines and frames on which each FOV's data can be found, but we cannot use the mesoscan_to_binary function for further suite2p processing because of the baked-in assumption described above. Would you consider re-writing to accommodate this case, as it seems to be a common choice for other labs as well?

I would be happy to try to re-write mesoscan_to_binary to generalize across cases, would you consider reviewing this and merging it with the master branch?