Bad GOES image detection

[astrobokonon]

Should put in an automatic way of detecting and dealing with images that are downloaded just fine, and processed, but contain obviously bogus image values. Possible ways:

1) File size check - if it's tiny, it's probably not right.

2) Actual image value checks - could be hard to catch the images where only a portion is invalid for whatever reason, but would catch the obviously all-bad ones

Once a bad image is caught, what should one do with it?

1) Skip it entirely - but then I have to figure out a way to keep skipping it since it'll just get redownloaded/reprocessed the next time around.

2) Write an obviously bad frame notification of some sort - blank frame, some text, etc.

3) Copy over the previous PNG. Would have to think more about the edge cases.

[astrobokonon]

Example bad image:

For this one, a simple file size check would have flagged it at the get-go.
20190981436216_C13.nc | 2019-04-08 14:43 | 658K

This next one is not so clear: 20190980459007_C13.nc | 2019-04-08 05:01 | 1.6M

[astrobokonon]

Perhaps the way to do it right is to just adjust the colorbar to be black at whatever bunk values are showing up in these examples. Then that would still give the overlays, and I wouldn't have to screw around too much!!

[astrobokonon]

Actual "bad" files for future reference:

20190981436216_C13.zip 20190980459007_C13.zip

[astrobokonon]

Even though pyresample's kd_tree.get_sample_from_neighbour_info has a fill_value parameter I was still getting back a masked array; I suspect because I was starting with a masked array as an input? Rather than muck around any more I just used a numpy routine to switch over to a regular ndarray with a fixed fill value after the reprojection but before it's returned for use.

Closed by 41cc6e9af407897dd4c1505fc18146cb8c4751d8; if there are ever any colormap changes, the hard-coded fill value might have to be updated as well. But good enough for government work as-is.

https://github.com/LowellObservatory/Camelot/blob/41cc6e9af407897dd4c1505fc18146cb8c4751d8/GOESMcGOESface/plotGOES.py#L164

[astrobokonon]

(this is much better in my opinion)

[astrobokonon]

Reopening this because my hack/magic value could be confused with a real value if we ever start doing statistics on these images. Making it an obvious bad value and adjusting the colorbar is what I should do before I forget all of these details.

[astrobokonon]

Closed by 139ac7ccc9cea78e7456a6f8dca8bf65c434bbf0, specifically

https://github.com/LowellObservatory/Camelot/blob/139ac7ccc9cea78e7456a6f8dca8bf65c434bbf0/GOESMcGOESface/plotGOES.py#L467-L469

[astrobokonon]