Original Message:
Sent: 4/21/2023 1:43:00 AM
From: Duri Bradshaw
Subject: RE: Raster Rendering Deep Dive – Part 1 – Default Algorithms
Hi Sam,
I know this is a very old post but I always find myself referring back to them when I'm trying to do something unusual with a GHX, so firstly thanks!!
I'm wondering if there a way to tell MapInfo which band to use for ALPHA?
I can see there is an EnableAlpha
<RenderStyle value="RGB" Underviews="1" EnableAlpha="1">
I can see that we can set the RGB bands to 1, 2, or 3 but I cant see anyway to tell MapInfo to use and 4 as my alpha band..
Normally MapInfo just reads the band called alpha and uses that but in my case I have a lot of images (ECW) that have unnamed bands and so I need to be able to specify which band to use.
Thanks
------------------------------
Duri Bradshaw
Spatial IT Consultant
Insight GIS
------------------------------
Original Message:
Sent: 06-13-2019 23:50
From: Sam Roberts
Subject: Raster Rendering Deep Dive – Part 1 – Default Algorithms
This article introduces you to the new raster rendering engine, shows you how to create a default algorithm for a raster or an algorithm that uses settings from a GHX file, and describes a method to reproject rasters on the fly to circumvent rendering performance problems in a map.
In this series of articles, I will explore the capabilities of the new raster rendering engine in MapInfo Pro. The engine has become accessible in MapInfo Pro version 17.03. You must install MapInfo Pro version 17.03 or later to use these capabilities.
In 64 bit MapInfo, most rasters are rendered by the MapInfo Pro Advanced raster handler. The handler contains embedded rendering code which uses rendering properties drawn from an associated GHX file. The GHX file is a simple XML file that contains rendering properties for the raster that it is associated with.
When you add a raster to a map, the raster handler will render the raster to a bitmap, according to the instructions in the GHX file, and then pass the bitmap back to MapInfo. To display the bitmap in a map window, MapInfo may have to apply some post-processing including re-projection (from the raster coordinate system to the map coordinate system), stretching and transparency processing.
In a future version of MapInfo, we plan to replace the current raster handler with a new raster handler that will render rasters using a new rendering engine. This engine is already available in the Raster SDK. In addition to being able to render a raster, the handler will be able to render an algorithm. A rendering algorithm is able to draw upon multiple rasters simultaneously to generate far richer raster visualisations.
In version 17.03, it is possible to acquire access to this rendering engine and to supply an algorithm to it for rendering in MapInfo. To achieve this you need to use a special raster driver called the "MapInfo Render Algorithm (.mrd)" driver. If you go to the backstage and look at the MapInfo Pro Raster preferences dialog you will see this driver listed under the native formats heading. Before proceeding, make sure the driver is enabled for display and processing.
This driver will load rendering algorithms and render them on-demand. Within MapInfo, it will look as though you have loaded a raster that is a simple "Image". When MapInfo asks for raster data (via the raster handler) the driver will call upon the rendering engine API's to render the algorithm you have supplied to it.
To display the rendering algorithm in a map requires double rendering – unfortunate, but presently unavoidable. Firstly the driver renders the algorithm, then the raster handler renders the image. To ensure that we get the image as it was generated by the driver, we need to ensure that the rendering settings in the GHX file for the rendering algorithm are benign and do not result in any color changes.
Now to cut to the chase – we need to write a rendering algorithm and save it in a file that can be loaded into MapInfo and recognised by the render algorithm driver. These files are written using XML and will have a ".mrd" file extension (you can also use a ".xml" file extension - the driver doesn't mind and I find it more convenient to edit the files when they have this recognisable extension). To proceed, you should have a basic understanding of XML syntax and you need a text editor. I use Notepad++ which is free to use and understands XML syntax. Here is an example of the simplest possible algorithm with some comments included.
<!-- This is XML boiler plate and ought to be included in each file -->
<?xml version="1.0" encoding="UTF-8"?>
<!-- This is the root element and identifies a rendering algorithm -->
<RenderAlgorithm>
<!-- I have listed a single raster specifying the full file name and path -->
<Raster File="C:\Temp\GA_SRTM_1as_25cm_DEM-H.mrr"/>
</RenderAlgorithm>
Inside the root element is a "Raster" element that specifies the file name of a single raster. You can copy this XML snippet to your own file, and then change the raster filename to point to a raster on your own system (the one arc-second resolution terrain raster of Australia I use in this example is 10 giga-cells and I am not uploading it!). This filename can use a relative path like "Data\MyRaster.mrr" which would lead the engine to a raster in the "Data" directory subordinate to the directory the algorithm file is located in.
In this example, no algorithm has been defined! Consequently, the rendering engine will fabricate a default algorithm for you based on the properties of the supplied raster. MapInfo does a similar thing for you when you display a raster for the first time. You can load this file into MapInfo and it will display your raster. MapInfo will create a TAB file and a GHX file to associate with the algorithm file. To load it into MapInfo use the normal mechanism for loading any other kind of raster file. Open the "Open Table" file-open dialog and select the "Raster Image" filter, then select your .mrd or .xml algorithm file.
Unfortunately, the default rendering properties that MapInfo applies are inappropriate and usually result in some additional color stretching. The way you should rectify this is to use a "Direct Mapping" transform for the Red, Green and Blue channels. The GHX file would look like this.
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<ghx>
<RasterHandler>
<Colour version="1">
<RenderStyle value="RGB" Underviews="4" EnableAlpha="1">
<RGB>
<Red field="0" band="1" name="CommonTransform" />
<Green field="0" band="2" name="CommonTransform" />
<Blue field="0" band="3" name="CommonTransform" />
</RGB>
</RenderStyle>
<TransformsList>
<Transform name="CommonTransform" UserDefinedMapping="false">
<Description>
<Datamapping>3</Datamapping>
</Description>
</Transform>
</TransformsList>
</Colour>
</RasterHandler>
</ghx>
Unfortunately, I have noticed that the raster handler turns black pixels into transparent pixels in this scenario. The alternative method is to change to a linear transform, applied the same to all channels, with clip limits from 0 – 255. However, I am not actually sure this works perfectly either. Unfortunately, a fix for this can't be delivered until we replace the raster handler.
Regardless, the GHX file has the same content for any algorithm you make so you can make the GHX manually by copying a template. You do need to make sure the GHX file is named appropriately – for example if your raster is called "Name.Ext" then the GHX file must be named "Name_Ext.ghx". Listed below is the GHX content using a linear transform.
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<ghx>
<RasterHandler>
<Colour version="1">
<RenderStyle value="RGB" Underviews="1" EnableAlpha="1">
<RGB>
<Red field="0" band="1" name="CommonTransform" />
<Green field="0" band="2" name="CommonTransform" />
<Blue field="0" band="3" name="CommonTransform" />
</RGB>
</RenderStyle>
<TransformsList>
<Transform name="CommonTransform" UserDefinedMapping="false">
<Description>
<Datamapping>0</Datamapping>
<Bandpass enable="true">
<BPType>0</BPType>
<BP1>0</BP1>
<BP2>255</BP2>
</Bandpass>
<ClipMinMaxColour>false</ClipMinMaxColour>
</Description>
</Transform>
</TransformsList>
</Colour>
</RasterHandler>
</ghx>
As a second example, you can generate a default algorithm that copies the rendering settings from the GHX file that is associated with the source raster. This algorithm ought to display pretty close to the way the source raster displays in Pro. Before you try this example, you need to load and display the raster in Pro so that it has a GHX file the rendering algorithm can be created from.
<?xml version="1.0" encoding="UTF-8"?>
<RenderAlgorithm>
<!-- I have listed a single raster specifying the full file name and path -->
<RasterGHX>C:\Temp\GA_SRTM_1as_25cm_DEM-H.mrr</RasterGHX>
</RenderAlgorithm>
Whilst interesting, these examples are not particularly useful. Generally, the raster will display much the same as they would in Pro. However, the new engine has a higher level of correctness and so you may see differences in unusual cases. You may also see differences in rasters that have highly irregular or skewed data distributions.
My final example gives you a useful workaround for a performance problem you may encounter in MapInfo. You may have noticed that as you zoom in on a large raster, the rendering performance gets progressively slower until, eventually, it is unusable. This happens when MapInfo has to reproject the raster and can easily be triggered by adding a Bing maps layer to a map. This changes the coordinate system of the map and forces all other data to be reprojected to match this coordinate system – including rasters. Rendering algorithms provide us with a solution – the rendering driver can reproject the raster at render time and this will prevent MapInfo from doing it. All that you need to do is to specify the new coordinate system in the algorithm as shown below. You can do this for default algorithms or for algorithms that use the GHX rendering properties, as shown in the two examples below.
<?xml version="1.0" encoding="UTF-8"?>
<RenderAlgorithm>
<Raster File="C:\Temp\GA_SRTM_1as_25cm_DEM-H.mrr"/>
<!-- Projections of the world - Popular Visualization CRS [ESPG: 3857] -->
<CoordinateSystem>CoordSys Earth Projection 10,157,"m",0</CoordinateSystem>
</RenderAlgorithm>
<?xml version="1.0" encoding="UTF-8"?>
<RenderAlgorithm>
<RasterGHX>C:\Temp\GA_SRTM_1as_25cm_DEM-H.mrr</RasterGHX>
<CoordinateSystem>CoordSys Earth Projection 10,157,"m",0</CoordinateSystem>
</RenderAlgorithm>
There are some major disadvantages to rendering rasters using algorithms rather than through the normal direct mechanism. The "Raster Info" and "Statistics" dialogs will show you the properties of the algorithm (which MapInfo thinks is a raster) but not the properties of the actual raster being rendered in the algorithm. Your actual raster will not appear in any operations as a discoverable source raster for processing, and the raster cell value tool will tell you the color of the pixels in the algorithm but not of the actual data in the raster. However, algorithms provide a host of new rendering capabilities and you may enjoy (and benefit from) exploring them. Please note, all of the algorithms demonstrated are available as an attachment.
In future articles, I will document multi-layered algorithms, Pseudocolor layers, RGB layers, Image layers, Terrain draping, Transparency modulation, Multi-raster collections and other advanced topics.
Next article - Raster Rendering Deep Dive - Part 2 - LUTColor Layers
------------------------------
Sam Roberts
Engineer, MapInfo Pro Advanced (Raster)
Australia
------------------------------