Field of View Matching: New Controlled Language Tag

[samiamseid]

Metric / Plot Impacted

• Field f View Matching

Update Motivation New fail reason. "Surface does not match in Z" If a session is set up such that the surface image is collected too deep or too shallow, it will impact what the "target depth" value is, even if the depth cell matching is correct.

Example: Target should be 275um Surface is collected too deep (50um below actual surface) Depth is properly cell matched LIMS see's depth as 225um instead of 275um (which is incorrect)

Unfortunately, we have no real way of knowing how far off a surface image is in Z, but we can visually tell when it is very far off. In these cases, the experiment should be failed.

Requested Feature/Solution New controlled language tag for Field of View Matching. "Surface does not match in Z". Should raise experiment to "failed" status

Screenshots or example plots

Scope All projects

[samiamseid]

Flag name: "Surface does not match in Z" Severity: Fails experiment physio metadata Description: "Surface Image significantly mismatches in Z axis. Calculated anatomical depth not valid"

[DowntonCrabby]

Hey Sam, quick follow-up question. What happens if the surface images do not match but the depth images/cells targeted DO match?

I could see that being the case fairly often- just wondering if the metadata failing should cause the failure or if it's the inability to match cells or both?

@matchings @jkim0731 @mattjdavis, can you all weigh in?

[samiamseid]

Thats actually exactly the issue. If surface AND cells dont match, we can simply call it a mistarget. However if cells match but surface doesnt, then the depth information is no longer accurate (since depth information is calculated as the distance between surface and depth).

The key issue here would be failing the metadata. We have sufficient metrics to QC matching cells.

Also, this hasnt happened frequently. A small amount of deviation from surface is not going to be noticeable (the difference between a plane that says 250um vs 260um). The issue arises in cases like the one used as an example above, where the depth can differ >50 and no longer even be grouped in the same container anymore.

[DowntonCrabby]

okay great- thanks Sam, that helps give context to this issue and informs what the follow up actions should be for this.

It sounds like the follow up action should be that we would have to manually edit the metadata

[DowntonCrabby]

This has been added to the dev database so it should be showing up in the dev reports. @samiamseid can you confirm it looks as you'd expect/like?

[samiamseid]

tag appears as expected. Ready for deploy