Introduction
FME supports many raster formats as readers and writers. The full list of supported raster formats can be found in the FME Integrations Gallery in the “Raster & Aerial Imagery” category.
There are different types of rasters, and when translating between raster formats, you might see error messages in the FME translation log if the source and destination bands and palettes are not compatible. This article discusses the process of translating between different types of rasters.
Step-by-Step Instructions
Let's look at a few example workspaces that translate between raster formats. In Part 1, we’ll translate between two raster formats with compatible interpretations. In Part 2, we'll examine a scenario where we encounter an error message and need to convert the band interpretation. In Part 3, we'll examine another error message that requires resolving the palette to meet the destination format’s requirements. For further information on handling bands and palettes, refer to the FME Raster Documentation.
Part 1: Direct translations between compatible raster formats
The simplest raster translation is when the reader and writer formats are compatible. That is, the destination format supports the same or a richer interpretation than the source format.
1. Generate a Workspace
In FME Workbench, click File > Generate Workspace. Select your source format and dataset, as well as your destination format and dataset. In this example, the user reads a DEM file in the CDED format and translates it to GeoTIFF.
2. Inspect the Source Data
To find out the interpretation of the source raster, open the FME Data Inspector and open the source dataset. Click anywhere on the raster to drop a pin, then look at the band information in the Feature Information pane.
When viewing the CDED raster in the Data Inspector, we can see that the interpretation is defined in “Band 0 (INT32)”.
3. Run the Translation
When the user runs the translation in Workbench, the raster is translated from source to destination without any errors. Converting from CDED to GeoTIFF is successful because the band interpretation is compatible — GeoTIFF supports a wide variety of interpretations, and Int32 (32-bit integer values) is among them.
Part 2: Converting band interpretations
Some raster translations require the band interpretation to be coerced into the destination type. After completing the steps in Part 1 and running the translation, you might get an error message related to the band interpretation.
1. Inspect the Error Message
In this example, the user is trying to translate an Esri ASCII Grid file to MapInfo Vertical Mapper Grid (NGrid), and an error appears in the translation log.
The error says there is an unsupported band interpretation and that we need to convert it to a valid type.
ERROR |NGRID writer: Unsupported band interpretation 'REAL64'. Please convert the interpretation to one of the following valid types: REAL32Esri ASCII Grid uses Real64 for band interpretation, whereas MapInfo Vertical Mapper Grid (NGrid) uses Real32. This is a scenario where the source format has an interpretation that accepts a wider range of data than the destination format, resulting in an FME translation failure and an error message being logged.
2. Add an *InterpretationCoercer Transformer
To resolve this, add a RasterInterpretationCoercer or RasterBandInterpretationCoercer and open the parameters. In this example, the user sets the Destination Interpretation Type to Real32 to make the data compatible with the NGrid format. The following translation is successful:
Part 3: Resolving palettes
Some raster translations require the removal or resolution of the palette(s) to match the destination format. After completing the steps in Part 1 and running the translation, you might get an error message related to the palettes.
1. Inspect the Error Message
In this example, the user is trying to translate GIF to JPEG and an error appears in the translation log.
The error says that the destination type doesn’t support palettes.
ERROR |JPEG writer: This format cannot support palettes. Consider removing or resolving palettes that are attached to the rasterGIF is a palette-based format, while JPEG is pure RGB24 or Gray8 and does not support palettes.
2. Add a RasterPalette* Transformer
We have two solutions: add a RasterPaletteRemover or a RasterPaletteResolver. We could use a RasterPaletteRemover to delete the palette, but the resulting UInt8 interpretation is unsupported in JPEG. We could then add a RasterBandInterpretationCoercer to coerce UInt8 to Gray8—but that would give us a gray resulting raster.
The better solution here is to resolve the palette using a RasterPaletteResolver.
This sets the raster’s cell values to values taken from a palette. So a cell/pixel in the source data might have the RGB24 value “191, 127, 76”, and the same cell in the destination would have three bands:
- Band 0 (RED8): 191
- Band 1 (GREEN8): 127
- Band 2 (BLUE8): 76
Using the RasterPaletteResolver to convert the source RGB24 palette to the RGB bands in the destination JPEG raster is successful.
Conclusion
Often, users need to transform the bands or palettes in a raster translation in order to make the source and destination formats compatible. Sometimes, more than one transformer will need to be placed to make the source format’s bands and palettes compatible with the destination format. For example, you might place a RasterSelector and a RasterBandKeeper to select and retain only one band in the raster, along with a RasterPaletteResolver to resolve the palette. Refer to the additional resources below for more information on raster translations.