Here we will try color balancing and pan-sharpening, i.e. applying the higher resolution panchromatic channel to the color channels, using i.colors.enhance (former i.landsat.rgb).
Landsat 8 – RGB color balancing: natural color composites
After import, the RGB (bands 4,3,2 for Landsat 8) may look initially less exciting than expected.This is easy to fix by a histogram based auto-balancing of the RGB color tables.
To brighten up the RGB composite, we can use the color balancing tool of GRASS GIS 7:
As input, we specify the bands 4, 3, and 2:
Using a “Cropping intensity (upper brightness level)” of 99 (percent), the result look as follows:
For special purposes or under certain atmospheric/ground conditions it may be useful to make use of the functions “Preserve relative colors, adjust brightness only” or “Extend colors to full range of data on each channel” in the “Optional” tab of i.colors.enhance (former i.landsat.rgb).
You will need to experiment since the results depend directly on the image data.
Landsat 8 pansharpening
Pansharpening is a technique to merge the higher geometrical pixel resolution of the panchromatic band (Band 8) with the lower resolution color bands (Bands 4, 3, 2).
This module runs in multi-core mode parallelized. The management of the resolution (i.e., apply the higher resolution of the panchromatic band) is performed automatically.
2. IHS transform
Here we select as above the bands in the i.pansharpen interface but use the “ihs” method.
HINT: If the colors should look odd, then apply i.colors.enhance (former i.landsat.rgb) to the pan-sharpened bands (see above).
https://neteler.org/wp-content/uploads/2024/01/wg_neteler_logo.png00Markushttps://neteler.org/wp-content/uploads/2024/01/wg_neteler_logo.pngMarkus2013-10-05 00:32:002023-11-20 16:46:20Processing Landsat 8 data in GRASS GIS 7: RGB composites and pan sharpening
The Landsat 8 mission is a collaboration between the U.S. Geological Survey (USGS) and National Aeronautics and Space Administration (NASA) which continues the acquisition of high-quality data for observing land use and land cover change.
The Landsat 8 spacecraft which was launched in 2013 carries they following key instruments:
OLI: the Operational Land Imager which collects data in the visible, near infrared, and shortwave infrared wavelength regions as well as a panchromatic band. With respect to Landsat 7 two new spectral bands have been added: a deep-blue band for coastal water and aerosol studies (band 1), and a band for cirrus cloud detection (band 9). Furthermore, a Quality Assurance band (BQA) is also included to indicate the presence of terrain shadowing, data artifacts, and clouds.
TIRS: The Thermal Infrared Sensor continues thermal imaging and is also intended to support emerging applications such as modeling evapotranspiration for monitoring water use consumption over irrigated lands.
The data from Landsat 8 are available for download at no charge and with no user restrictions.
Using the “Download options”, you can download the data set (requires login). Select the choice:
[x] Level 1 GeoTIFF Data Product (842.4 MB)
You will receive the file “LC80160352013134LGN03.tar.gz”.
Unpacking the downloaded Landsat 8 dataset
To unpack the data, run (or use a graphical tool at your choice):
tar xvfz LC80160352013134LGN03.tar.gz
A series of GeoTIFF files will be extracted: LC80160352013134LGN03_B1.TIF, LC80160352013134LGN03_B2.TIF, LC80160352013134LGN03_B3.TIF, LC80160352013134LGN03_B4.TIF, LC80160352013134LGN03_B5.TIF, LC80160352013134LGN03_B6.TIF, LC80160352013134LGN03_B7.TIF, LC80160352013134LGN03_B8.TIF, LC80160352013134LGN03_B9.TIF, LC80160352013134LGN03_B10.TIF, LC80160352013134LGN03_B11.TIF, LC80160352013134LGN03_BQA.TIF
Note: While this Landsat 8 scene covers the area of the North Carolina (NC) sample dataset, it is delivered in UTM rather than the NC’s state plane metric projection. Hence we preprocess the data first in its original UTM projection prior to the reprojection to NC SPM.
Using the Location Wizard, we can import the dataset easily into a new location (in case you don’t have UTM17N not already created earlier):
grass70 -gui
Now start GRASS GIS 7 and you will find the first band already imported (the others will follow shortly!).
For the lazy folks among us, we can also create a new GRASS GIS Location right away from the dataset on command line:
Landsat 8 Operational Land Imager (OLI) and Thermal Infrared Sensor (TIRS) images consist of nine spectral bands with a spatial resolution of 30 meters for Bands 1 to 7 and 9. New band 1 (ultra-blue) is useful for coastal and aerosol studies. New band 9 is useful for cirrus cloud detection. The resolution for Band 8 (panchromatic) is 15 meters. Thermal bands 10 and 11 are useful in providing more accurate surface temperatures and are collected at 100 meters. Approximate scene size is 170 km north-south by 183 km east-west (106 mi by 114 mi).
Landsat 7
Wavelength (micrometers)
Resolution (meters)
Landsat 8
Wavelength (micrometers)
Resolution (meters)
Band 1 – Coastal aerosol
0.43 – 0.45
30
Band 1 – Blue
0.45 – 0.52
30
Band 2 – Blue
0.45 – 0.51
30
Band 2 – Green
0.52 – 0.60
30
Band 3 – Green
0.53 – 0.59
30
Band 3 – Red
0.63 – 0.69
30
Band 4 – Red
0.64 – 0.67
30
Band 4 (NIR)
0.77 – 0.90
30
Band 5 – Near Infrared (NIR)
0.85 – 0.88
30
Band 5 (SWIR 1)
1.55 – 1.75
30
Band 6 – SWIR 1
1.57 – 1.65
30
Band 7 (SWIR 2)
2.09 – 2.35
30
Band 7 – SWIR 2
2.11 – 2.29
30
Band 8 – Panchromatic
0.52 – 0.90
15
Band 8 – Panchromatic
0.50 – 0.68
15
Band 9 – Cirrus
1.36- 1.38
30
Band 6 – Thermal Infrared (TIR)
10.40 -12.50
60* (30)
Band 10 – Thermal Infrared (TIRS) 1
10.60 – 11.19
100* (30)
Band 11 – Thermal Infrared (TIRS) 2
11.50- 12.51
100* (30)
* ETM+ Band 6 is acquired at 60-meter resolution. Products processed after February 25, 2010 are resampled to 30-meter pixels.
* TIRS bands are acquired at 100 meter resolution, but are resampled to 30 meter in delivered data product.
Natural color view (RGB composite)
Due to the introduction of a new “Cirrus” band (#1), the BGR bands are now 2, 3, and 4, respectively. See also “Common band combinations in RGB” for Landsat 7 or Landsat 5, and Landsat 8.
From Digital Numer (DN) to reflectance:
Before creating an RGB composite, it is important to convert the digital number data (DN) to reflectance (or optionally radiance). Otherwise the colors of a “natural” RGB composite do not look convincing but rather hazy (see background in the next screenshot). This conversion is easily done using the metadata file which is included in the data set with i.landsat.toar:
Now we are ready to create a nice RGB composite (hint 2015: i.landsat.rgb has been renamed to i.colors.enhance):
Select the bands to be visually combined:
… and voilà !
Applying the Landsat 8 Quality Assessment (QA) Band
One of the bands of a Landsat 8 scene is named “BQA” which contains for each pixel a decimal value representing a bit-packed combination of surface, atmosphere, and sensor conditions found during the overpass. It can be used to judge the overall usefulness of a given pixel.
We can use this information to easily eliminate e.g. cloud contaminated pixels. In short, the QA concept is (cited here from the USGS page):
For the single bits (0, 1, 2, and 3):
0 = No, this condition does not exist
1 = Yes, this condition exists.
The double bits (4-5, 6-7, 8-9, 10-11, 12-13, and 14-15) represent levels of confidence that a condition exists:
00 = Algorithm did not determine the status of this condition
01 = Algorithm has low confidence that this condition exists (0-33 percent confidence)
10 = Algorithm has medium confidence that this condition exists (34-66 percent confidence)
11 = Algorithm has high confidence that this condition exists (67-100 percent confidence).
Detailed bit patterns (d: double bits; s: single bits):
d – Bit 15 = 0 = cloudy
d – Bit 14 = 0 = cloudy
d – Bit 13 = 0 = not a cirrus cloud
d – Bit 12 = 0 = not a cirrus cloud
d – Bit 11 = 0 = not snow/ice
d – Bit 10 = 0 = not snow/ice
d – Bit 9 = 0 = not populated
d – Bit 8 = 0 = not populated
d – Bit 7 = 0 = not populated
d – Bit 6 = 0 = not populated
d – Bit 5 = 0 = not water
d – Bit 4 = 0 = not water
s – Bit 3 = 0 = not populated
s – Bit 2 = 0 = not terrain occluded
s – Bit 1 = 0 = not a dropped frame
s – Bit 0 = 0 = not fill
Usage example 1: Creating a mask from a bitpattern
We can create a cloud mask (bit 15+14 are set) from this pattern:
cloud: 1100000000000000
Using the Python shell tab, we can easily convert this into the corresponding decimal number for r.mapcalc:
Welcome to wxGUI Interactive Python Shell 0.9.8
Type "help(grass)" for more GRASS scripting related information.
Type "AddLayer()" to add raster or vector to the layer tree.
Python 2.7.5 (default, Aug 22 2013, 09:31:58)
[GCC 4.8.1 20130603 (Red Hat 4.8.1-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> int(0b1100000000000000)
49152
Using this decimal value of 49152, we can create a cloud mask:
# set NULL for cloudy pixels, 1 elsewhere:
r.mapcalc "cloudmask = if(LC80160352013134LGN03_BQA == 49152, null(), 1 )"
# apply this mask
r.mask cloudmask
In our sample scene, there are only tiny clouds in the north-east, so no much to be seen. Some spurious cloud pixels are scattered over the scene, too, which could be eliminated (in case of false positives) or kept.
Usage example 2: Querying the Landsat 8 BQA map and retrieve the bitpattern
Perhaps you prefer to query the BQA map itself (overlay the previously created RGB composite and query the BSA map by selecting it in the Layer Manager). In our example, we query the BQA value of the cloud:
Using again the Python shell tab, we can easily convert the decimal number (used for r.mapcalc) into the corresponding binary representation to verify with the table values above.
Hence, bits 15,14,13, and 12 are set: cloudy and not a cirrus cloud. Looking at the RGB composite we tend to agree :-) Time to mask out the cloud!
wxGUI menu >> Raster >> Mask [r.mask]
Or use the command line, as shown already above:
# remove existing mask (if active)
r.mask -r
# set NULL for cloudy pixels, 1 elsewhere:
r.mapcalc "cloudmask = if(LC80160352013134LGN03_BQA == 61440, null(), 1 )" --o
# apply the new mask
r.mask cloudmask
The visual effect in the RGB composite is minimal since the cloud is white anyway (as NULL cells, too). However, it is relevant for real calculations such as NDVI (vegetation index) or thermal maps.
We observe dark pixels around the cloud originating from thin clouds. In a subsequent identification/mask step we may eliminate also those pixels with a subsequent filter.
https://neteler.org/wp-content/uploads/2024/01/wg_neteler_logo.png00Markushttps://neteler.org/wp-content/uploads/2024/01/wg_neteler_logo.pngMarkus2013-09-29 23:35:012023-11-20 16:46:07Processing Landsat 8 data in GRASS GIS 7: Import and visualization
The GRASS GIS community is delighted to present the outcome of the 4th Community Sprint that took place in a warm and sunny Prague, Czech Republic, from July 12 to July 18, 2013. The event happened after the Geoinformatics conference at the Czech Technical University in Prague. The Community Sprint was once more a creative gathering of both long-term and new developers, as well as users.
This meeting was held in the light of 30 YEARS OF GRASS GIS!
We wish to cordially thank the Department of Mapping and Cartography, Faculty of Civil Engineering, Czech Technical University in Prague for hosting and technical support. In particular, we gratefully acknowledge our association sponsors OSGeo and FOSSGIS e.V., and many individual donors: Peter Löwe, Andrea Borruso, Massimo Di Stefano, Alessandro Sarretta, Joshua Campbell, Andreas Neumann, Jon Eiriksson, Luca Casagrande, Karyn O Newcomb, Holger Naumann, Anne Ghisla, Helena Mitasova and Lubos Mitas, Dimitris Tamp, Mark Seibel, Markus Metz, and Tawny Gapinski. These financial contributions were used to cover costs such as meals and to help reducing travelling and accommodation expenses for participants with far arrival who came on own expenses.
Developers and users who joined the event came from various countries like Italy, Czech Republic, Slovak Republic, Poland, Sri Lanka/France, USA and Germany.
The Community Sprint focused on:
About GRASS GIS
The Geographic Resources Analysis Support System, commonly referred to as GRASS GIS, is an Open Source Geographic Information System providing powerful raster, vector and geospatial processing capabilities in a single integrated software suite. GRASS GIS includes tools for spatial modeling, visualization of raster and vector data, management and analysis of geospatial data, and the processing of satellite and aerial imagery. It also provides the capability to produce sophisticated presentation graphics and hardcopy maps. GRASS GIS has been translated into about twenty languages and supports a huge array of data formats. It is distributed freely under the terms of the GNU General Public License (GPL). GRASS GIS is an official project of the Open Source Geospatial Foundation (OSGeo).
GRASS GIS 6.4.3 released – Birthday release for 30 years of GRASS GIS https://grass.osgeo.org
We are pleased to announce the release of a new stable version of GRASS GIS. This release fixes bugs discovered in 6.4.2 version of the program and adds a number of new features. This release includes over
830 updates to the source code since 6.4.2. As a stable release series, the 6.4 line will enjoy long-term support and incremental enhancements while preserving backwards-compatibility with the entire GRASS 6 line.
Key improvements of this release include some new functionality (assistance for topologically unclean vector data), major speedup for some vector modules, fixes in the vector network modules, fixes for the wxPython based portable graphical interface (attribute table management, wxNVIZ, and Cartographic Composer). A number of new modules have been added for processing LANDSAT and MODIS satellite data, and a new vector statistics module is also introduced. Many new symbols and north arrows are available, and the user will find an improved and easier to use wizard for creating custom project locations with precise map projection and datum support. Community-contributed add-on modules are now more easily and robustly installed from an online archive. Other major developments include enhancements to the Python scripting library and numerous software-compatibility fixes and translation updates. Important is the enhanced portability for MS-Windows (native support, fixes in case of missing system DLLs). And we welcome Romanian as our twenty-fourth language!
Video of GRASS GIS 6.4 development visualization from 1999 to 2013 (with soundtrack)
About GRASS GIS
GRASS (Geographic Resources Analysis Support System) is a free and open source Geographic Information System (GIS) software suite used for geospatial data management and analysis, image processing, graphics and map production, spatial modeling, and 3D visualization. GRASS GIS is currently used in academic and commercial settings around the world, as well as by many governmental agencies and environmental consulting companies. GRASS GIS can be used either as a stand-alone application or as backend for other software packages such as QGIS and R geostatistics. It is a founding member of the Open Source Geospatial Foundation (OSGeo).
Fourth (and last) release candidate of GRASS GIS 6.4.3 with improvements and stability fixes A fourth release candidate of GRASS GIS 6.4.3 is now available.
To get the GRASS GIS 6.4.3RC4 source code directly from SVN: Â svn checkout https://svn.osgeo.org/grass/grass/tags/release_20130710_grass_6_4_3RC4/
Key improvements of this release include some new functionality (assistance for topologically unclean vector data), fixes in the vector network modules, fixes for the wxPython based portable graphical interface (attribute table management, wxNVIZ, and Cartographic Composer), fixes in the location wizard for Datum transform selection and support for PROJ.4 version 4.8.0, improvements for selecting the Python version to be used, enhanced portability for MS-Windows (native support, fixes in case of missing system DLLs), and more translations (esp. Romanian).
https://neteler.org/wp-content/uploads/2024/01/wg_neteler_logo.png00Markushttps://neteler.org/wp-content/uploads/2024/01/wg_neteler_logo.pngMarkus2013-06-17 17:12:552024-01-22 22:30:21Scaling up globally: 30 years of FOSS4G development
Key improvements of the GRASS 6.4.3 release include some new functionality (image processing tools), major speedup for some vector modules, fixes for the wxPython based portable graphical interface, improvements for the Python API, enhanced portability for MS-Windows (native support), and more translations.
The GRASS GIS team will organize a GRASS GIS Community Sprint from 2-7 Feb, 2013 in Genova, Italy. The sprint is at the same time of the “XIV Meeting degli Utenti Italiani GRASS e Gfoss” at the University of Genova.
We would like to invite you to financially support this upcoming Community Sprint! The past sprints have been very successful as we expect for the upcoming one.
Background info The GRASS GIS Community Sprint is a great occasion for folks to support the development by actively contributing to the source code, manuals or likewise. The community sprint is a get-together for GRASS project members and supporters and related OSGeo projects to take decisions and tackle larger problems. For this meeting, we welcome people committed to improving the GRASS GIS project and the interfaces to QGIS, GDAL, PostGIS, R-stats. Sextante. gvSIG, OGC Services and more. This includes developers, documenters, bug reporters, translators and other OSGeo supporters. Not only the “C Tribe” will be addressed but also Python or whatever the participants prefer.
Earlier this Last year, in June, Don Meltz wrote an interesting blog “ArcGIS vs QGIS Clipping Contest Rematch” where he let compete ArcGIS and Quantum GIS in a clipping contest. The benchmark contest data set in question is a 878MB ZIP file (ContourClipTest.zip with the (guessed) EPSG Code 2260 – NAD83 / New York East (ftUS)). The blog page gained a lot of comments, even from ESRI since some ArcGIS versions crashed on this test data set.
Find below the various timings compiled from the blog and the comments:
Proprietary software
Software
Processing time
Hardware/Software
ArcGIS 9.3
crash after 1h 9min: ERROR 999999: Error executing function. Invalid Topology [4gb file limit.] Failed to execute (Clip)
unknown
ArcGIS 10.0
crash likewise
unknown
ArcGIS 10.1
ESRI promise to calculate it in 34 seconds in this updated version (did anyone test?)
unknown
GlobalMapper (version?)
30 mins
unknown
GlobalMapper v11.02
49 sec
Windows XP w/ 3.5GB RAM
Manifold 8 (64bit)
31 min
Windows XP64 16 gb. RAM and 2.33 GHz
Note: The two GlobalMapper results are a bit funny, perhaps always minutes?