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.
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"