Hamish wrote: > Markus wrote: > .... > > > New Revision: 34353 > .... > > backport this?
No. > also r34350 and r34351 look very bugfix-like. > > those too? Maybe and yes. r34350 adds a new color table transformation, G_abs_log_colors(), which is like G_log_colors() but works with signed data (it maps x to log(fabs(x)+1), with the +1 to prevent the range [-1,+1] from dominating the colour table). The change to the G_make_grey_scale_fp_colors() is purely cosmetic. It uses DCELL for the min/max arguments for consistency with the other G_make_*_fp_colors() functions, but DCELL is always equivalent to double. r34351 is an important bug fix. In the FFTW 3.x case, the order of the rows and cols was the wrong way around. This wasn't immediately obvious because i.fft forced the dimensions to be powers of two (the original fft() implementation required this), so a typical test case would result in either a square array or at worst a 2:1 ratio. [Think about what will happen if you read a 256x256 image as if it were 512x128: it will be wrong, but it won't look like noise in the way that a highly irregular ratio would.] When I removed the power-of-two restriction, the bug became clear. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
