wcslib triggers an error when the pixels are out of the image

[ayllon]

I do not know if this is generalized, but I get an exception coming from an error within wcslib, complaining about invalid world coordinates.

one or more of the world coordinates were invalid.

I have managed to catch the error, and the coordinates look ok to me.

231.42560781394292, 30.238717631401094

They are projected outside of the frame

-0.37306747266120238, -5.5780510021143312

But that's ok. We will clip and that's it. Not sure why that's an issue now, or only with the dataset of #380.

P.S It was the 4th corner. The others were translated fine.

[ayllon]

The image that triggers this is SEF/EUC_MER_SCI-SWIN-NIR-J_41_20210512T213931.933876Z_00.00.fits Other images are just fine if the coordinates are out of bounds, but that particular one triggers the error.

[marcschefer]

Isn't that the same problems that we had before? (issue #254) I don't think we ever fully understood what was going on.

[ayllon]

Yup, good memory. I have dug the error to be

2021-09-01T12:06:39CEST WCS ERROR : wcs.c:3368 wcss2p
2021-09-01T12:06:39CEST WCS ERROR : One or more of the world coordinates were invalid
2021-09-01T12:06:39CEST WCS ERROR : lin.c:921 linx2p
2021-09-01T12:06:39CEST WCS ERROR : De-distort error
2021-09-01T12:06:39CEST WCS ERROR : dis.c:1298 disx2p
2021-09-01T12:06:39CEST WCS ERROR : Convergence not achieved after 30 iterations, residual 7.4e-12

But in this case, we are out of bounds. I guess we can not always expect the projection to be well-behaved there. Should we just keep going in these cases? We can identify this error with the constant LINERR_DEDISTORT.

@mkuemmel ?

[ayllon]

On a second thought, it may be better to flag and not do anything with a source like that. Anything we do is pretty much undefined at this point, isn't it?

[mkuemmel]

wcss2p transforms from sky to pixel coordinates. with non-linear distortions present this is not always possible. This should be limited to sky coordinates that outside of that image anyway. When establishing the non-linear distortions objects all over the image are used which results in a solution across the image (but not beyound).

The best solution would be to drop that particular image (EUC_MER_SCI-SWIN-NIR-J_41_20210512T213931.933876Z_00.00.fits) for this objects and do the fitting using the other images where a solution does exist.

[ayllon]

The best solution would be to drop that particular image (EUC_MER_SCI-SWIN-NIR-J_41_20210512T213931.933876Z_00.00.fits) for this objects and do the fitting using the other images where a solution does exist.

Agree. I will add a flag so this can be identified on the output catalog.

[mkuemmel]

I had a look at the coordinates that produce the error in WCS. The error is reproducible. I took that particular image and projected 10 million objects in the area of the detection image into that particular image. Out of those 10 million positions there is no error, interestingly. Here the overview:

The green point is the position giving the error. Blue are VIS detections which mark the detection FOV, and dark red is the carpet of random positions. The green point is in the FOV, the area that crashes must be rather small around the green point, since no random point is close enough to crash as well. Kind of strange.

But the solution with the warning is okay, of course.

[mkuemmel]

While I know that this is kind of an overkill, I tried to map out the dangerous area around RA=231.42560781394292, Dec=30.238717631401094 that raises an error. Turns out that this is on the order of a few 1.0e-08 around those coordinates and hence really small. No surprise that we had not hit such a spot as of now.