[Git][debian-gis-team/pyspectral][master] 4 commits: New upstream version 0.9.5+ds
Antonio Valentino
gitlab at salsa.debian.org
Wed Feb 5 07:18:53 GMT 2020
Antonio Valentino pushed to branch master at Debian GIS Project / pyspectral
Commits:
9b83ff7f by Antonio Valentino at 2020-02-05T07:13:14+00:00
New upstream version 0.9.5+ds
- - - - -
0e714a42 by Antonio Valentino at 2020-02-05T07:13:15+00:00
Update upstream source from tag 'upstream/0.9.5+ds'
Update to upstream version '0.9.5+ds'
with Debian dir 61a663b0f8ba67d6b67af4151989f8a5268032b2
- - - - -
7c3c5c7a by Antonio Valentino at 2020-02-05T07:14:07+00:00
New upstream release
- - - - -
c30c34eb by Antonio Valentino at 2020-02-05T07:16:12+00:00
Set distribution to unstable
- - - - -
4 changed files:
- CHANGELOG.md
- debian/changelog
- doc/rad_definitions.rst
- pyspectral/solar.py
Changes:
=====================================
CHANGELOG.md
=====================================
@@ -1,3 +1,26 @@
+## Version v0.9.5 (2020/02/04)
+
+### Issues Closed
+
+* [Issue 101](https://github.com/pytroll/pyspectral/issues/101) - Getting the near infrared reflectance of a viirs scene crashes. ([PR 102](https://github.com/pytroll/pyspectral/pull/102))
+
+In this release 1 issue was closed.
+
+### Pull Requests Merged
+
+#### Bugs fixed
+
+* [PR 103](https://github.com/pytroll/pyspectral/pull/103) - Fix '-' (minus) sign in math string
+* [PR 102](https://github.com/pytroll/pyspectral/pull/102) - Fix round returning a float ([101](https://github.com/pytroll/pyspectral/issues/101), [101](https://github.com/pytroll/pyspectral/issues/101))
+
+#### Documentation changes
+
+* [PR 103](https://github.com/pytroll/pyspectral/pull/103) - Fix '-' (minus) sign in math string
+* [PR 100](https://github.com/pytroll/pyspectral/pull/100) - Updated the documentation of inverse Planck function for broad channels
+
+In this release 4 pull requests were closed.
+
+
## Version v0.9.4 (2019/12/30)
=====================================
debian/changelog
=====================================
@@ -1,8 +1,9 @@
-pyspectral (0.9.4+ds-2) UNRELEASED; urgency=medium
+pyspectral (0.9.5+ds-1) unstable; urgency=medium
+ * New upstream release.
* Bump Standards-Version to 4.5.0, no changes.
- -- Antonio Valentino <antonio.valentino at tiscali.it> Sat, 25 Jan 2020 11:04:45 +0100
+ -- Antonio Valentino <antonio.valentino at tiscali.it> Wed, 05 Feb 2020 07:15:56 +0000
pyspectral (0.9.4+ds-1) unstable; urgency=medium
=====================================
doc/rad_definitions.rst
=====================================
@@ -42,7 +42,7 @@ Constants
^^^^^^^^^
+---------------------------------+----------------------------------------------------------------------------------------+
- | :math:`k_B` | Boltzmann constant (:math:`1.3806488 1e−23`) |
+ | :math:`k_B` | Boltzmann constant (:math:`1.3806488 1e-23`) |
+---------------------------------+----------------------------------------------------------------------------------------+
| :math:`h` | Planck constant (:math:`6.62606957 1e-34`) |
+---------------------------------+----------------------------------------------------------------------------------------+
@@ -263,23 +263,84 @@ In python it may look like this:
>>> print([round(t, 8) for t in temp])
[299.99998562, 301.00000518]
+This approach only works for monochromatic or very narrow bands for which the
+spectral response function is assumed to be constant. In reality, typical imager
+channels are not that narrow and the spectral response function is not constant over the band. Here it
+is not possible to de-convolve the planck function and the spectral response function
+without knowing both, the spectral radiance and spectral response function in
+high spectral resolution. While this information is usually available for
+the spectral response function, there is only one integrated radiance per channel.
+That makes the derivation of brightness temperature from radiance more complicated
+and more time consuming - in preparation or in execution.
+Depending on individual requirements, there is a bunch of feasible solutions:
+
+
+
+Iterative Method
+++++++++++++++++
+
+A stepwise approach, which starts with a guess (most common temperature), calculate
+the radiance that would correspond to that temperature and compare it with the measured
+radiance. If the difference lies above a certain threshold, adjust the temperature
+accordingly and start over again:
+
+
+ (i) set uncertainty parameter :math:`\Delta L`
+ (ii) set :math:`T_j = T_{first guess}`
+ (iii) calculate :math:`B(T_j)`
+ (iv) if :math:`(B(T_j) - L_{measure}) > \Delta L` then adjust :math:`T_j` and go back to :math:`iii`
+ (v) :math:`T_j` matches the measurement within the defined uncertainty
+
+Advantages
+ * no pre-computations
+ * accuracy easily adaptable to purpose
+ * memory friendly
+ * independent of band
+ * independent of spectral response function
+
+Disadvantages
+ * slow, especially when applying to wide bands and high accuracy requirements
+ * redundant calculations when applying to images with many pixels
+
+
+Function Fit
+++++++++++++
+
+Another feasible approach is to fit a function :math:`\Phi` in a way that
+:math:`|T - \Phi(L_{measure})|` minimizes. This requires pre-calculations
+of data pairs :math:`T` and :math:`L(T)`. Finally an adequate function :math:`\Phi`
+(dependent on the shape of :math:`T(L(T))`) is assigned and used to calculate the
+brightnesss temperature for one channel.
+
+Advantages
+ * fast approach (especially in execution)
+ * minor memory request (one function per channel)
+
+Disadvantages
+ * accuracy determined in the beginning of the process
+ * complexity of :math:`\Phi` depends on :math:`T(L(T))`
+
+
+Look-Up Table
++++++++++++++
+
+If the number of possible pairs :math:`T` and :math:`L(T)` is limited (e.g. due to
+limited bit size) or if the setting for a function fit is too complex or does not
+fit into a processing environment, it is possible to just expand the number of
+pre-calculated pairs to a look-up table. In an optimal case, the table cover every
+possible value or is dense enough to allow for linear interpolation.
+
+Advantages
+ * fast approach (but depends on table size)
+ * (almost) independent of function
+
+Disadvantages
+ * accuracy dependent on value density (size of look-up table)
+ * can become a memory issue
+
-Provided the input is a central wavenumber or wavelength as defined above, this
-gives the brightness temperature calculation under the assumption of a linear
-planck function as a function of wavelength or wavenumber over the spectral
-band width and provided a constant relative spectral response. To get a more
-precise derivation of the brightness temperature given a measured radiance one
-needs to convolve the inverse Planck function with the relative spectral
-response function for the band in question:
-.. math::
- T_B = \frac{\int_0^\infty \Phi_{i}(\lambda) T(B_{\lambda}) \mathrm{d}\lambda}
- {\int_0^\infty \Phi_{i}(\lambda) \mathrm{d}\lambda}
-or
-.. math::
- T_B = T(B_{\nu}) = \frac{\int_0^\infty \Phi_{i}(\nu) T(B_{\nu}) \mathrm{d}\nu}
- {\int_0^\infty \Phi_{i}(\nu) \mathrm{d}\nu}
=====================================
pyspectral/solar.py
=====================================
@@ -179,7 +179,7 @@ class SolarIrradianceSpectrum(object):
# print "Start and end: ", start, end
LOG.debug("Begin and end wavelength/wavenumber: %f %f ", start, end)
dlambda = self._dlambda
- xspl = np.linspace(start, end, round((end - start) / self._dlambda) + 1)
+ xspl = np.linspace(start, end, int(round((end - start) / self._dlambda)) + 1)
ius = InterpolatedUnivariateSpline(wvl, resp)
resp_ipol = ius(xspl)
@@ -239,7 +239,7 @@ class SolarIrradianceSpectrum(object):
else:
start, end = ival_wavelength
- xspl = np.linspace(start, end, round((end - start) / self._dlambda) + 1)
+ xspl = np.linspace(start, end, int(round((end - start) / self._dlambda)) + 1)
if self.wavespace == 'wavelength':
ius = InterpolatedUnivariateSpline(
self.wavelength, self.irradiance)
View it on GitLab: https://salsa.debian.org/debian-gis-team/pyspectral/compare/4f3140183337f0869e9ffcc6fadbfab472d1bd35...c30c34eb610e2ad29f53617a4f17eeb6ec14de14
--
View it on GitLab: https://salsa.debian.org/debian-gis-team/pyspectral/compare/4f3140183337f0869e9ffcc6fadbfab472d1bd35...c30c34eb610e2ad29f53617a4f17eeb6ec14de14
You're receiving this email because of your account on salsa.debian.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-grass-devel/attachments/20200205/c4f54e4f/attachment-0001.html>
More information about the Pkg-grass-devel
mailing list