Review bin2tif extractor and output

[craig-willis]

Review issue for the bin2tif extractor and rgb_geotiff output.

Completion criteria:

• [ ] Code review complete (includes extractor, any functions in terrautils, etc)
• [x] Sample data output verified
• [x] Sample metadata verified
• [x] Changes for 2017 release implemented
• [ ] Issue(s) for changes postponed until 2018 created
• [x] Extractor tagged/versioned
• [x] Extractor deployed
• [ ] Final output verified/reviewed

[max-zilla]

LINKS

bin2tif output dataset example https://terraref.ncsa.illinois.edu/clowder/datasets/59afda604f0ca12ea0b4fd79 raw dataset that was used to generate this output https://terraref.ncsa.illinois.edu/clowder/datasets/59afda604f0ca12ea0b4fd4b collection with 7,926 other output datasets https://terraref.ncsa.illinois.edu/clowder/collection/59af02944f0ca12ea0a387ac

an output dataset includes left/right JPG and GeoTIFF.

outputs on ROGER are in /ua-mac/Level_1/rgb_geotiff

[max-zilla]

@ZongyangLi @craig-willis can confirm that the extractor ran without dark pixel correction yesterday - I added an if statement to allow the same extractor to work on both flir and rgb by ignoring the DARKER flag if sensor!='rgb_geotiff' but the way the code is written I had to adjust that if statement because the RGB also got routed into normal code.

I renamed the existing TIFs in the fullfield directory with a _nodark prefix so they aren't overwritten, and just started a run to generate pixel-corrected images.

[max-zilla]

@pless @ZongyangLi something is definitely off with georeferencing, @craig-willis and I looked at 2 bin2tif outputs using latest code and they are vertically adjacent instead of horizontally:

Gonna take a quick look to see if there's an obvious explanation e.g. axes swapped.

[ZongyangLi]

@max-zilla That's not an error of our extractor, the scan is in vertical direction. I reported yesterday here: https://github.com/terraref/reference-data/issues/183#issuecomment-328640626 in point 1

Things also happened in flir scan, please see https://github.com/terraref/reference-data/issues/182#issuecomment-328883698

Besides, if you ignore the sun impact, leaves on the edge are almost connected correctly.

[max-zilla]

@ZongyangLi I don't think scans are supposed to be in vertical direction (even east/west are offset n/s and not e/w) so I am looking at bin2tif georeferencing first.

[ZongyangLi]

@max-zilla I did check the metadata in raw_data yesterday, in the most closest directories, y position is unchanged, in the same time x position is moving a little bit from one directory to another. @smarshall-bmr Could you please confirm the scan direction in recent days?

[max-zilla]

@ZongyangLi you are correct. I looked at a test image from 05/20 and corrected our stereo offset (was setting left/right to wrong side so right was offset left and vice versa).

now looks correctly aligned (these are the same area with east on top then west on top):

this would explain some of the weirdness in our full field stitching, but not all. we can run another full day of bin2tif + full field on this.

[ZongyangLi]

@max-zilla Could you please tell me more about the 'setting left/right to wrong side', I didn't realize this issue before.

[max-zilla]

@ZongyangLi as discussed, we are regenerating a few days of bin2tif with offset correction fix. We will just need to document that we are looking into sunlight correction but there are concerns with potential issues that could introduce.

[smarshall-bmr]

I'm just confirming that yes, I have been running scans on the north-south axis for the past few months. The stereo pair still fires simultaneously so issues in stitching probably have to do with different distances from the camera. Plants in the field vary between 70cm and 4m tall so I have to aim for some sort of consensus distance that can capture everything. Has anyone tried generating an orthomosaic?

[ZongyangLi]

This extractor processes binary files into JPG and TIFF files. To obtain a well stitched map, a HEIGHT_MAGIC_NUMBER and PREDICT_MAGIC_SLOPE were applied when we estimate the field of view, this is a testing based number. The geo-reference bounding box base on an assumption of image axis is in a same direction of lat-lon axis.

The current stitched image is suitable for most data quality and coverage assessments and some data analysis. We are not sure that any simple stitching process (or any more complicated process that would be called stitching) is good enough to be used for more complicated analysis.

One of the artifacts is duplication of area, this is unavoidable without a much more complex stitching algorithm that implicitly infers the 3D structure of the ground. The justification for not going for such a rich representation is that:

• for the plants, since they move, it would be impossible not to have artifacts at the edges of the image, and
• for the ground, I judged that small stitching errors were not worth the (substantial) additional effort to build the more complete model.

[craig-willis]

Stale issue, closing. Will revisit 2018 QC in new issue