Disable seam leveling for multispectral data, and add backstops to flag and fix any negative reflectances that slip by

[ckwood256]

Closes #43

For multispectral data, disable both local and global seam leveling because it leads to artifacts that can cause negative reflectance values in the spectral orthophoto bands.

Disabling seam leveling, in addition to #39 and #41, should fix all known causes of negative reflectance values in the orthophotos, at least that I'm aware of. However, in case negative reflectances somehow slip by, these changes also add backstops to the texturing and orthophoto stages to detect, warn of, and fix any negative reflectances.

I wrote some of the code in these changes, but Claude also wrote some of the code (which I carefully reviewed and sometimes modified). I also used Claude Code to help understand the structure of the ODX stages, understand some of the details of MVS Texturing, propose fixes, and to review my code. These changes took me about 2 days to implement and validate on real-world datasets using my M3M. I'm a geophysicist doing scientific programming for more than 30 years.

[pierotofy]

Local seam leveling is kind of important. I don't think the solution is to skip it.

Also: a separate compiled extension that can be ABI-incompatible with the installed numpy in some environments.. What? Please do not use Claude code to implement this stuff.

[ckwood256]

Seam-leveling is the final issue I found which could cause negative reflectance values in multispectral orthos. The symptom is negative values in the texture atlases, which the PR checks for.

Turning off both local and global seam leveling completely fixed the issue in the data sets I tested, while neither alone did.

The 2014 conference article Let There Be Color! Large-Scale Texturing of 3D Reconstructions which describes the methods used by MVS Texturing is a bit short on details, so it would be useful if there were comments in the code describing how important each leveling type is for image sets representing physical quantities like reflectance, and how to avoid artifacts. In practice, both types caused problems for the data sets I tested.

Finally, the comment you mentioned is 1 line out of a 4-line comment, and is more awkward taken out of context than it really is. The basic issue is that ODX appears to have packages in the distribution ODX/venv that rely on numpy 1.2 and some that rely on 2.x, such as gdal vs. rasterio. These are ABI-incompatable and can cause ODX to fail in weird ways. I asked Claude to suggest the cause of the initial gdal implementation crashing and it came up with one that used rasterio instead, including the verbose (but correct) comment. I believe I mentioned using Claude to propose fixes in this PR, consistent with the requirements that existed at the time (looks like the goalposts may have shifted a bit as those requirements were changed after my PR was submitted).