You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A quick summary: Seems like some non-obvious input data problem causes insert coordinates for the surfaces 2p to be negative, in which case surfaces are to be inserted outside of the fullfield image. From operation standpoint this should not be the case unless ScanImage's internal coordinate system is reset between surface and fullfield steps of the experiment. When this happens, we should skip inserting surface to the fullfield image, only output the stitched fullfield image and output error message that says that insert coordinates were erroneous.
The text was updated successfully, but these errors were encountered:
nataliaorlova
changed the title
negative insert coordinates for mapping surafces to fullfield
negative insert coordinates for mapping surfaces to fullfield
Apr 3, 2023
This is with regards to the following failed job: http://lims2/job_logs?id=1258717334
A quick summary: Seems like some non-obvious input data problem causes insert coordinates for the surfaces 2p to be negative, in which case surfaces are to be inserted outside of the fullfield image. From operation standpoint this should not be the case unless ScanImage's internal coordinate system is reset between surface and fullfield steps of the experiment. When this happens, we should skip inserting surface to the fullfield image, only output the stitched fullfield image and output error message that says that insert coordinates were erroneous.
More detailed comments form ScottD on this:
"I’m going to guess that the problem arises in the conversion from physical coordinates to pixel coordinates here
https://github.com/AllenInstitute/ophys_etl_pipelines/blob/main/src/ophys_etl/modules/mesoscope_splitting/full_field_utils.py#L155-L164
probably this calculation ends up trying to map the ROI image to a location that isn’t inside the pixel bounds of the full field image. I don’t know if that means the metadata in the average image is wonky or if there’s an edge case the calculation cannot handle.
If that is the problem, a quick fix would be to add an if statement here
https://github.com/AllenInstitute/ophys_etl_pipelines/blob/main/src/ophys_etl/modules/mesoscope_splitting/full_field_utils.py#L166
that just skips stitching in the ROI if it is outside of the full field image bounds
Indeed, these lines
https://github.com/AllenInstitute/ophys_etl_pipelines/blob/main/src/ophys_etl/modules/mesoscope_splitting/full_field_utils.py#L156
https://github.com/AllenInstitute/ophys_etl_pipelines/blob/main/src/ophys_etl/modules/mesoscope_splitting/full_field_utils.py#L160
could result in negative values for row0 or col0.
In that case, you would get an error like this. Probably the physical-to-pixel coordinates code should clip at zero (provided that the origin for the ROI isn’t many pixels below 0"
The text was updated successfully, but these errors were encountered: