On Tue, Nov 18, 2008 at 2:41 AM, <svn_grass@osgeo.org> wrote:
Author: glynn
Date: 2008-11-17 20:41:17 -0500 (Mon, 17 Nov 2008)
New Revision: 34353
Removed:
grass/trunk/imagery/i.fft/fft_colors.c
grass/trunk/imagery/i.fft/globals.h
grass/trunk/imagery/i.fft/local_proto.h
grass/trunk/imagery/i.fft/orig_wind.c
grass/trunk/imagery/i.fft/save_fft.c
grass/trunk/imagery/i.ifft/globals.h
grass/trunk/imagery/i.ifft/local_proto.h
grass/trunk/imagery/i.ifft/orig_wind.c
Modified:
grass/trunk/imagery/i.fft/Makefile
grass/trunk/imagery/i.fft/i.fft.html
grass/trunk/imagery/i.fft/main.c
grass/trunk/imagery/i.ifft/Makefile
grass/trunk/imagery/i.ifft/i.ifft.html
grass/trunk/imagery/i.ifft/main.c
Log:
Rewrite i.fft, i.ifft
Output maps are FP
Don't use cell_misc/<map>/fft{real,imag} files, use the output maps
Don't rescale to powers of two (not needed with FFTW)
Use fft2() with FFTW-style interleaved array, not fft() with separate real/imaginary arrays
Miscellaneous clean-up
On Tue, Nov 18, 2008 at 2:41 AM, <svn_grass@osgeo.org> wrote:
Author: glynn
Date: 2008-11-17 20:41:17 -0500 (Mon, 17 Nov 2008)
New Revision: 34353
Removed:
grass/trunk/imagery/i.fft/fft_colors.c
grass/trunk/imagery/i.fft/globals.h
grass/trunk/imagery/i.fft/local_proto.h
grass/trunk/imagery/i.fft/orig_wind.c
grass/trunk/imagery/i.fft/save_fft.c
grass/trunk/imagery/i.ifft/globals.h
grass/trunk/imagery/i.ifft/local_proto.h
grass/trunk/imagery/i.ifft/orig_wind.c
Modified:
grass/trunk/imagery/i.fft/Makefile
grass/trunk/imagery/i.fft/i.fft.html
grass/trunk/imagery/i.fft/main.c
grass/trunk/imagery/i.ifft/Makefile
grass/trunk/imagery/i.ifft/i.ifft.html
grass/trunk/imagery/i.ifft/main.c
Log:
Rewrite i.fft, i.ifft
Output maps are FP
Don't use cell_misc/<map>/fft{real,imag} files, use the output maps
Don't rescale to powers of two (not needed with FFTW)
Use fft2() with FFTW-style interleaved array, not fft() with separate real/imaginary arrays
Miscellaneous clean-up
backport this?
No specific ideas on this change, but if we're working towards a stable settled down 6.x then I don't think the type of miscellaneous cleanups that Glynn is doing in 7.x are candidates for backporting.
2008/11/18 Paul Kelly <paul-grass@stjohnspoint.co.uk>:
backport this?
No specific ideas on this change, but if we're working towards a stable
settled down 6.x then I don't think the type of miscellaneous cleanups that
Glynn is doing in 7.x are candidates for backporting.
it would help to have releasebranch_6_4 in this case. Then these
changes would make sense to backport to develbranch_6. I am not sure
how close we are to *finally* [1] release 6.4.0 (I hope I will have
more time to fix bugs and to help with release issues).
2008/11/18 Paul Kelly <paul-grass@stjohnspoint.co.uk>:
backport this?
No specific ideas on this change, but if we're working towards a stable
settled down 6.x then I don't think the type of miscellaneous cleanups that
Glynn is doing in 7.x are candidates for backporting.
it would help to have releasebranch_6_4 in this case. Then these
changes would make sense to backport to develbranch_6.
Yes, makes sense.
I am not sure
how close we are to *finally* [1] release 6.4.0 (I hope I will have
more time to fix bugs and to help with release issues).
Well I think there'll be time for bugfixes after the release branch is created. But creating the branch means no new features so I guess that needs to be finalised. I'm very busy though so won't be much help myself for a while, sorry.
> Author: glynn
> Date: 2008-11-17 20:41:17 -0500 (Mon, 17 Nov 2008)
> New Revision: 34353
>
> Removed:
> grass/trunk/imagery/i.fft/fft_colors.c
> grass/trunk/imagery/i.fft/globals.h
> grass/trunk/imagery/i.fft/local_proto.h
> grass/trunk/imagery/i.fft/orig_wind.c
> grass/trunk/imagery/i.fft/save_fft.c
> grass/trunk/imagery/i.ifft/globals.h
> grass/trunk/imagery/i.ifft/local_proto.h
> grass/trunk/imagery/i.ifft/orig_wind.c
> Modified:
> grass/trunk/imagery/i.fft/Makefile
> grass/trunk/imagery/i.fft/i.fft.html
> grass/trunk/imagery/i.fft/main.c
> grass/trunk/imagery/i.ifft/Makefile
> grass/trunk/imagery/i.ifft/i.ifft.html
> grass/trunk/imagery/i.ifft/main.c
> Log:
> Rewrite i.fft, i.ifft
> Output maps are FP
> Don't use cell_misc/<map>/fft{real,imag} files, use the output maps
> Don't rescale to powers of two (not needed with FFTW)
> Use fft2() with FFTW-style interleaved array, not fft() with separate real/imaginary arrays
> Miscellaneous clean-up
backport this?
No. It's an incompatible change. The output of the old i.fft won't
work with the new i.ifft and vice versa.
The old i.fft stored the actual FFT coefficients in the files
cell_misc/<map>/fft{real,imag}; the actual maps were just visual
representations which could be viewed with d.rast. The old i.ifft used
the data in the fft{real,imag} files, ignoring the maps' contents (it
would explicitly read the mask file, allowing you to perform filtering
by setting a mask before running i.ifft).
The new i.fft stores the data in the maps, and the new i.ifft reads
the maps. So you can perform filtering by using e.g. r.mapcalc on the
FFT maps.
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.
On Tue, Nov 18, 2008 at 2:21 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Markus wrote:
> backport this?
...
r34351 is an important bug fix. In the FFTW 3.x case, the order of the
rows and cols was the wrong way around.
I appreciate very much your efforts.
But I/we really need indications when to backport - to ask explicitely
with every change happening is too much randomized for me.
Suggestion: add a micro note into the commit that backport is desired?
Then we can pick it up easily.