RasterMosaicker Fails using Alpha Band

Can you inspect the feature/record going into the RasterMosaicker and take a screen snapshot of the FeatureInformation showing the raster and its Alpha band

You need to ensure all features/records have this alpha band

FME2024.1 might be stricker about mixed bands being tagged or not tagged with Alpha

Use RasterSelect to ensure band count is the same… forcing all RGB to RGBA

or RasterBandNodataSetter (for nodata → alpha effect)

Here are the screenshots of the details of the two input rasters, each with an Alpha8 and RED8, GREEN8, BLUE8 band. 
I’ve also tried the RasterBandNodataSetter as well as the RasterBandNodataRemover, but the Mosaicker fails regardless. None of the bands have a palette.

Well, they both have the same coordinate system, extents, cell size and origin.

FME must be misinterpreting the alpha band

Prior to the RasterMocaiker, can you inspect both have the same numbers

• fme_raster_numbands
• fme_raster_band_interpretation

Both rasters seem to have the same values.

Only thing that seems to be different is the attribute band_num_tile_rows / band_num_tile_columns which is 1024 for the alpha band and 8192 for the RGB bands. But in the listed resolution of the whole raster it is 8192. And when extending the info about the raster, all four bands are listed with 8192 so idk if this is actually an issue.

Hello ​@mifranz, good catch! There indeed was a behaviour change in FME Form 2022.1 that tightened up validation in the RasterMosaicker so that mismatched interpretations will cause a failure or be rejected, whereas older versions were more lenient. I will consider filing an issue to have the documentation updated. The RasterBandOrderer is likely the best bet before sending the rasters to the mosaicker. Happy to help, Kailin.