To clarify: doing the gdalwarp resample without OpenCL is producing a
realistic Float32 value range. Doing it WITH OpenCL is producing far
higher values.
This is on a Tesla M2090. No other experiments/benchmarks have produced
this kind of result, and as I wrote below, gdalwarp itself works when
on
Hello,
I've run into an odd problem that I suspect is the result of some
incorrect variable type casting, but I'm not sure where to look or how
to fix it.
Inputting a raster in Float32 format (or Float64, with -ot Float32
and/or -wt Float32 enabled on the command line) and attempting to do a
resam