using "look_one_level_down" doesn't use "bad_frames.npy"

[hwpdalgleish]

Hey both,

I'm loving Python Suite2P - especially the bad_frames functionality for removing photostim artifacts! However, it appears it doesn't work when using the look_one_level_down flag. For the below setup, with look_one_level_down = 1: -> data_path ---> bad_frames.npy ---> directory 1: multi-page tif ---> directory 2: multi-page tif

I want the multi-page tiffs in directory 1 & 2 to be registered and processed together, with bad_frames excluded. The result is this:

However, if I then use this setup with look_one_level_down = 0: -> data_path ---> bad_frames.npy ---> multi-page tif ---> multi-page tif

Then the result is this:

You can see in the first images (look_one_level_down = 1) there are some ROIs (particularly in the bottom left corner of the neuropil on the right) that have this vertical banding structure that is characteristic of our 2P photostimulation artefact. No such ROIs exist in the second image (look_one_level_down = 0).

Am I misunderstanding how to use bad_frames in this condition? If so could you let me know how to use it?

Cheers, Henry

[carsen-stringer]

Glad you like it :) It seems like you're using this option correctly so not sure what the bug is. I've added a print statement for the bad frames file name so you can see if it finds it correctly, and if it loads correctly then it will print the number of badframes.

If this works fine then the bug might be that suite2p reads in the directories in a different order than you have your badframes in? Are the directories "1" and "2"?

Also I'd try out the "sparse_mode"=1 option with your data if you're not using it already - we find it works better in many cases.

[hwpdalgleish]

Hey Carsen,

Thanks for the reply. My directories are arranged in a logical order: 1: tiff 1 2: tiff 2 3: tiff 3 etc. and bad_frames.npy tracks this same sequence.

I still seem to be having issues. Just to clarify, bad_frames.npy frame numbers should be "plane-wise", i.e. if I have 4 planes and a photostim happens at "absolute frame no." 4001 then bad_frames.npy should flag frame 1000 to be removed (round(4001/4)) from each plane? I'm assuming this to be the case because if I include absolute frame times in bad_frames.npy then I get an "index exceeds dimensions"-type error.

For now I think I can avoid this with a workaround where I don't use look_one_level_down, so I read in just tiff files in a single directory, and I've added a field to ops that tracks the number of frames in each tiff file (this was the reason for me wanting to use one_level_down - to use the frames_per_folder field).

I will keep trying to troubleshoot and if you have any further input that would be welcome!

Thanks, Henry

[carsen-stringer]

were you able to sort this out?

do you think it has to do with different planes having different number of frames per block?

[hwpdalgleish]

I used the workaround I mentioned in my previous post to successfully analyse my data/remove the photostim artifact (my eLife paper has a lot to thank Suite2P for!) but unfortunately I didn't go any deeper into it - sorry not to be more help!