Mesoscope surface image misassignment

[wbwakeman]

Surface images are being assigned to the incorrect planes for mesoscope experiments.

The issue appears to be two specific things:

1. The first 3 planes are assigned one surface image, and the other 5 are assigned the other. This does not make sense because there are 4 planes per ROI, so there should be 4 and 4.
2. The surface images are associated with the opposite ROI. Because of the 3/5 split, this means that only the 4th plane in ROI 1 is correct.

Example: http://lims2/ophys_sessions?search[id][opt]=%3D&search[id][from]=914224851

Tasks:

• [ ] Investigate why this image misassignment might be happening
• [ ] Implement a fix
• [ ] Provide a suggestion on how to backfill incorrect experiments

Acceptance criteria:

• [ ] Can demonstrate that a mesoscope experiment that was incorrect previously is now split with all the correct images assigned to the correct experiments

[wbwakeman]

Natalia also gave this ophys_session as an example of mis-assignment issues in LIMS: 882756028

[djkapner]

Some additional context:

This file appears to be an example of what was run to split a mesoscope file into individual experiments: /allen/programs/braintv/production/visualbehavior/prod0/specimen_840542948/ophys_session_914224851/MESOSCOPE_FILE_SPLITTING_QUEUE_914224851.pbs

which refers to a particular branch of this repo: https://github.com/AllenInstitute/brain_observatory_utils/blob/mesoscope_splitting/brain_observatory_utils/scripts/run_mesoscope_splitting.py

[djkapner]

Related to this issue

[wbwakeman]

A recent example:

[kschelonka]

I think this is blocking #1462, not the other way around? It seems like this is the actual module/algorithm that does the splitting, and the other story is to incorporate that into the prod ETL pipeline. Please let me know if my understanding is incorrect.

[wbwakeman]

Both #1206 and #1462 need to be completed. When #1206 was being examined some months ago, the consensus was that we should start by getting the splitting code into a better place. If you think it makes more sense to start with this issue, that is okay too.

[kschelonka]

@waynewakeman

I took a look at the experiment you linked in LIMS.

I used the platform.json and MESOSCOPE_SPLITTING..._input.json to manually extract the experiment_id and targeted_structure_id for each plane in the plane groups. I confirmed using the "z" and "roi_index" values that the ordering was maintained between the platform plane groups and the mesoscope input plane groups. I then plotted the surface images by experiment_id and added the structure from the metadata. Below are the results. Note that the second row (VISl) looks similar to the last row (VISam), but I confirmed that it is not actually the same image.

Naively this looks correct to me. I confirmed that each pair has the same surface image, and all the images are different across rows. Of course, it doesn't line up with the "ground truth" that was posted. I'm not sure how that ground truth was created -- maybe I'm missing something in the way I'm associating surface images to areas? Would be helpful for more info about the ground truth.

[nataliaorlova]

@kschelonka I'm going to answer your question here, and use the session Wayne used above to showcase that the code that generates fullfield_2p image manifests the same errors when using mesoscope_2p on the rig to split and map surfaces to full FOV file. On the image below, green indicates correct location and visual area name (middle image), while red is what mapping code on the rig outputs(left), and blue (right) is if I were to use LIMS's surface assignment to map the surface image files to higher visual areas. Please let me know if you decide to migrate the code before looking at the bug - I'd want the fix the bug also on the rig where fullfield_2p_image is generated.

[nataliaorlova]

@kschelonka to get the ground truth every Nth frame of the the surface file should be extracted and then the 16 of them averaged to obtain the "split" surface images. N is the number of visual areas in the data set. N can be extracted form the tiff header (which is what the bug might be in in mesoscope_2p), or read from LIMS. We have only two possible values for N so far : 2 for 2areasx4depth, 4 for 4 areasx2depth.

16 is the number controlled during acquisition, can be read from the tiff header, but not from LIMS. Experimental protocol for now calls out for 16, so all datasets should have 16 copies of the same frame to average for averaged_surface.tiff and averaged_depth.tiff

Split surface images (I just did this using FIji) this session (which has 4 vis. areas) :

[kschelonka]

Thanks @nataliaorlova , I have a much better understanding of what's going on now.

[kschelonka]

@wbwakeman, @nataliaorlova has been helping me document some of the fields. She's also going to open a dialogue with Vidrio (the company that produces these images) to help us out more. There is no detailed API documentation available online for older versions (which we are using). Instead you have to install ScanImage and use MATLAB to look at their documentation.

http://scanimage.vidriotechnologies.com/display/SI2017/ScanImage+API

[kschelonka]

Started documenting what we can here: http://confluence.corp.alleninstitute.org/x/yyxNBQ

[kschelonka]

From yesterday's meeting with Natalia, she is going to provide us with more documentation about the data outputs and how they should be processed. I'm moving this in the blocked section since she's going on vacation, and we can pick it up again after.

[wbwakeman]

Complete input files for one mesoscope session are available at /allen/aibs/technology/waynew/allen/programs/braintv/production/incoming/neuralcoding/ Please copy them elsewhere to use them.

Refer to the production file logs and input/output json files at /allen/programs/braintv/production/neuralcoding/prod64/specimen_1029485863/ophys_session_1053297451 for example of successful and complete processing

Ping me with any questions or if anything is still missing

[nataliaorlova]

Here is a doc file where I'll be documenting file structure for all two-photon data streams, and describe how each of them should be split.

[wbwakeman]

This is interesting. Some (not all) recent experiments look okay. For this one: http://lims2/ophys_sessions?search%5Bid%5D=1061417028 Sam writes: "that session has all the surface images associated with the correct experiments"

[djkapner]

This PR from Jed: https://github.com/AllenInstitute/ophys_etl_pipelines/pull/119 would(might) fix this issue (Natalia)

[wbwakeman]

This is fixed going forward by the work in https://github.com/AllenInstitute/ophys_etl_pipelines/issues/135 and https://github.com/AllenInstitute/ophys_etl_pipelines/issues/171