Pixel shift when going from FLT to TIF (multiple tools)

[jfbourdon]

Several tools shift by half-pixel the output raster:

• fill_single_cell_pits => half-pixel shift (down-left)
• breach_single_cell_pits => half-pixel shift (down-left)
• breach_depressions => half-pixel shift (down-left)
• convert_raster_format => no shift from FLT or TIFF, but half-pixel shift (down-left) if going from DEP to FLT or TIFF

The problem occurs when going from FLT to FLT or TIFF. If the input raster is TIFF, the output raster (TIFF or FLT) has the correct extent.

[jfbourdon]

After doing a bit of digging, I found that it may be a feature and not a bug (partialy at least)... In the file related to reading and writing ArcBinary files (FLT), there is a part looking if the cellCornerMode is true (coordinates of a pixel at the top left) or false (coordinates of a pixel at the center):

whitebox-tools/src/raster/arcbinary_raster.rs

Lines 88 to 103 in 65a0794

	// set the North, East, South, and West coodinates
	if xllcorner != f64::NEG_INFINITY {
	//h.cellCornerMode = true
	configs.east = xllcorner + (configs.columns as f64) * configs.resolution_x;
	configs.west = xllcorner;
	configs.south = yllcorner;
	configs.north = yllcorner + (configs.rows as f64) * configs.resolution_y;
	} else {
	//h.cellCornerMode = false
	configs.east = xllcenter - (0.5 * configs.resolution_x)
	+ (configs.columns as f64) * configs.resolution_x;
	configs.west = xllcenter - (0.5 * configs.resolution_x);
	configs.south = yllcenter - (0.5 * configs.resolution_y);
	configs.north =
	yllcenter - (0.5 * configs.resolution_y) + (configs.rows as f64) * configs.resolution_y;
	}

For a reason that elude me, it seems it's always assumed that the coordinates of pixels are at their center (xllcorner != f64::NEG_INFINITY is always FALSE).

[jfbourdon]

I confirm that the bug is still present in v1.1.0.

[jfbourdon]

This bug has been corrected in release 1.2.0 by 1357e7a but is still present with ASCII files (was not in original issue but I just found out).

[jfbourdon]

Issue corrected with ASCII files by 616b3b8.