New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rescaling TOA #10
Comments
Yes, But there are also cases where we'll need 8bit for pragmatic reasons. Both of these are limitations of GDAL's implementation but limitations nonetheless.
In auto-landsat we have some intermediate steps that might be affected by the alpha band interpretation issue. So uint8 might be necessary. I think we should have a related note: when we implement this, make sure to expose the data rescaling function in the python API as well as in the worker/cli. |
Completed rescaling: 3679f5d dtype option that defaults to
|
@celoyd and I voiced on the rescaling factor and output dtype. We think that the default should be keeping post-TOA tifs as float (currently float32). This allows faster reading and minimum information lost when we work on post-TOA processes like atmospheric correction in the future. We can add a new cli option to output rescaled 16-bit.
Why are we rescaling?
TOA is the ratio of reflected radiation from the surface to incident radiation upon it. Its dimensionless nature lets it be expressed as a percentage and is measured on a scale from zero for no reflection of a perfectly black surface to 1 for perfect reflection of a white surface. We need to rescale TOA from this ratio back to 16-bit(or 8-bit). Note that we need to rescale post-TOA tifs to 55,000 instead of 216 because USGS Landsat 8 products are delivered as 16-bit images but are actually scaled to 55,000 grey levels:
Here are the steps:
@perrygeo How about letting
rio-color
handle the 16 to 8-bit conversion?cc @dnomadb @celoyd @perrygeo
The text was updated successfully, but these errors were encountered: