<div dir="ltr">in old times, 8-bit was the best for storage/resolution (still there somehow...) but also for processing. rescaling IMHO is a legacy mostly of that time. Someone should look into i.atcorr with a specific target at modernizing this bit. <br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 19, 2015 at 3:20 PM Tomáš Brunclík <<a href="mailto:brunclik@atlas.cz">brunclik@atlas.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
just a note to this discussion. I never understood the input/output<br>
stretching parameters of i.atcor, so I have no advice here, just couple<br>
of thoughts.<br>
I especially don't see why these scale parameters seem to be always used<br>
in any tutorial, either always set to 0,1 both, or worse, to actual<br>
range of input for the input scaling parameter. I would understand their<br>
use, if the input TOA reflectance was in percent or in reflectance<br>
multiplied by 10000, or quantized as DN values are - then such input<br>
stretching min,max could be used to correct for this (not based on<br>
actual values in the image, but on its metadata, though). Similarly, if<br>
we needed output in percent reflectance or reflectance muptiplied by<br>
10000, then the output streching could be used.<br>
But if the input is in values of TOA reflectance already and we need<br>
output in values of ground reflectance, there should be no stretching<br>
involved at all, not even stretching to 0,1. And not even if there are<br>
pixels in the scene having TOA reflectace over 1, and not again if there<br>
are no pixels having reflectance over 0.5. Because both is possible -<br>
although reflectance over 1 is of course not possible by definition, it<br>
can be measured for surfaces not meeting measurement assumptions.<br>
A scene band can contain pixels with TOA reflectance seemingly over 1<br>
very easily, nothing fishy about that. Because keep in mind, we are<br>
speaking about *spectral directional reflectance* and it is measured<br>
with assumption of lambertian surfaces. Reflectance value of 1 should be<br>
value of pixel of absolutely white object with *lambertian surface*. But<br>
there can be an object with a mirror-like surface, like water or metal<br>
roof and if such object is reflecting light toward the sensor (glint),<br>
it can easily reach radiance values equivalent to lambertian surface<br>
reflectance well above 1. And of course there can be invalid pixels,<br>
like dead pixels in CCD cameras. So the algorithm (or the user) should<br>
not try to scale the whole input or output reflectance, regardless of if<br>
these pixels were removed from the scene or not. If unscaled TOA<br>
reflectance, even containing reflectances over 1 at places should be fed<br>
to the ATCOR algorithm unscaled, the result should be ground reflectance<br>
unscaled.<br>
And of course, it is normal, that the result may again contain<br>
reflectances above 1 - it could be the pixels mentioned before, but also<br>
for example clouds - because the reflectance is true only for surfaces<br>
on the ground. Highly reflective surfaces high above ground can again<br>
reach radiance values higher than what absolutely white object on ground<br>
could have, because to the cloud in 10 km altitude there comes much more<br>
light than to the surface below filtered by the thick atmosphere down<br>
there, and we are not correcting for this, as we do for high mountains<br>
with DMT, do we?<br>
<br>
Regards,<br>
Tomas Brunclik<br>
<br>
<br>
<br>
Yann Chemin napsal(a):<br>
> Something is fishy here, reflectance values should always be within<br>
> 0-1 range.<br>
><br>
> Please manually remove all values outside of that range (use<br>
> r.mapcalc) and make a histogram of your TOAR band. if the histogram is<br>
> of expected shape, and is not truncated at 1.0 threshold then you are<br>
> OK. if there is a problem here, that means the TOAR processing had an<br>
> issue. Stretching output from an unknown histogram skewness could be<br>
> giving you funny results.<br>
><br>
><br>
> On Mon, Jun 15, 2015 at 6:47 PM Micha Silver <<a href="mailto:micha@arava.co.il" target="_blank">micha@arava.co.il</a><br>
> <mailto:<a href="mailto:micha@arava.co.il" target="_blank">micha@arava.co.il</a>>> wrote:<br>
><br>
>     On 6/15/2015 3:25 PM, John, Lisa wrote:<br>
>>     Hi Micha,<br>
>><br>
>>     did you refer to the input range?<br>
>     Yes, the input range.<br>
><br>
>>     I did so and checked bands 1-9 with <a href="http://r.info" rel="noreferrer" target="_blank">r.info</a> <<a href="http://r.info" rel="noreferrer" target="_blank">http://r.info</a>> -r.<br>
>>     Top of atmosphere reflectance values are all in the range of<br>
>>     -0.01 - 2.12. The negative value seems to be a outlier and I<br>
>>     check in addition with the range 0-2.12.<br>
>>     I used these values for the input range in i.atcorr -r and used<br>
>>     0,1 as output range.<br>
>     I meant in the first i.landsat.toar step. The input (DN) values<br>
>     should be up to 700 or so. Landsat 8, with its 12 bit data can<br>
>     have max DN values of 4096. But I didn't use that full range,<br>
>     rather the actual DN range of the original images.<br>
><br>
>>     However I get even smaller reflectance values (0.15 respectively<br>
>>     0.29 for vegetation in band5)<br>
>><br>
>>     Regards, Lisa.<br>
>><br>
>><br>
>>     This mail was received via Mail-SeCure System.<br>
>><br>
>><br>
>>     _______________________________________________<br>
>>     grass-user mailing list<br>
>>     <a href="mailto:grass-user@lists.osgeo.org" target="_blank">grass-user@lists.osgeo.org</a>  <mailto:<a href="mailto:grass-user@lists.osgeo.org" target="_blank">grass-user@lists.osgeo.org</a>><br>
>>     <a href="http://lists.osgeo.org/mailman/listinfo/grass-user" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
>>     This mail was received via Mail-SeCure System.<br>
>><br>
>><br>
><br>
>     _______________________________________________<br>
>     grass-user mailing list<br>
>     <a href="mailto:grass-user@lists.osgeo.org" target="_blank">grass-user@lists.osgeo.org</a> <mailto:<a href="mailto:grass-user@lists.osgeo.org" target="_blank">grass-user@lists.osgeo.org</a>><br>
>     <a href="http://lists.osgeo.org/mailman/listinfo/grass-user" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> grass-user mailing list<br>
> <a href="mailto:grass-user@lists.osgeo.org" target="_blank">grass-user@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/grass-user" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
<br>
_______________________________________________<br>
grass-user mailing list<br>
<a href="mailto:grass-user@lists.osgeo.org" target="_blank">grass-user@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-user" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
</blockquote></div>