<div dir="ltr"><div><br><br>On Tue, Jan 16, 2018 at 8:32 AM, Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>> wrote:<br>><br>> On Fri, Jan 12, 2018 at 10:42 AM, Markus Metz<br>> <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> wrote:<br>> > On Fri, Jan 12, 2018 at 8:58 AM, Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>> wrote:<br>> ...<br>> > The spectral filter functions for RapidEye in i.atcorr are strange. E.g.<br>> > band 2 (green) is supposed to cover the range 520 - 590 nm, but in iwave.cpp<br>> > this band covers the range 424 - 876 nm. Further on, the file rapideye.csv<br>> > and the values in IWave::rapideye() do not match, a lot of 0.001 values have<br>> > been inserted where there should be zero. In rapideye.csv, there are gaps in<br>> > filter functions, e.g. for green from 598 to 763 nm, then again from 773 to<br>> > 876 nm. In the range 424 - 508 nm, there are also a few small blocks with<br>> > values > 0 separated by large blocks of missing values.<br>><br>> This is the source which was used:<br>> <a href="https://resa.planet.com/files/2014-06/Spectral_Response_Curves.pdf">https://resa.planet.com/files/2014-06/Spectral_Response_Curves.pdf</a><br>><br>> Maybe something went wrong?<br><br></div>I don't think so, there are just a lot of small values that can be ignored.<br><div><br>><br>> markusN<br>><br>> > In short, there are too many too small values in the rapideye filter<br>> > functions, causing numerical instability. This could be fixed upon<br>> > initialization.<br></div><div><br></div><div>This is fixed upon initialization in trunk r72072.</div><div><br></div><div>The results are still slightly different on different OS's (Debian, Fedora), but fairly similar and now there are non-NULL results.<br></div><div><br></div><div>Markus M <br></div></div>