# [Scilab-users] fftshift and ifftshift are way too different

9 messages
Open this post in threaded view
|

## [Scilab-users] fftshift and ifftshift are way too different

 Hello all,  From what I understand of fast Fourier transforms, fftshift and ifftshift should be almost identical. The only difference is when there are an odd number of elements in the dimension along which the shift is performed (ie fftshift([1:4])==ifftshift([1:4]) but fftshift([1:5])!=ifftshift([1:5])). However, it seems that in scilab6.x fftshift and ifftshift are based on completely different codes and do not accept the same arguments. In particular, with fftshift, one can specify the dimension along which to perform the shift, while it is not the case for ifftshift. I think some update of ifftshift would be welcome. I propose to use the code below (myifftshift), where I just changed "ceil" by "floor" in the definition if fftshift. What do you think, does it look right to you? Cheers, Antoine function x = myifftshift(x,job)      if argn(2)<2 then job="all",end      deff("sel=fun(sk)","c=floor(sk/2);sel=[c+1:sk,1:c]")      if job=="r" then job=1,elseif job=="c" then job=2,end      ind=list()      if job=="all" then          for sk=size(x),ind(\$+1)=fun(sk),end      else          for sk=size(x),ind(\$+1)=:,end;          ind(job)=fun(size(x,job))      end      x=x(ind(:)) endfunction _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users
Open this post in threaded view
|

## [Scilab-users] Re : fftshift and ifftshift are way too different

 Hello Antoine, fttshift() switches all halves along all dimensions. This is mandatory. So for instance in 2D, opposite quadrants (wrt the center) are switched. In 3D, opposite cubes are switched. etc. To me, the current implementation is right: --> m=grand(3,5,"uin",0,9)  m  =    2.   5.   9.   3.   0.    2.   4.   5.   5.   6.    4.   1.   8.   5.   9. --> fftshift(m)  ans  =    5.   9.   4.   1.   8.    3.   0.   2.   5.   9.    5.   6.   2.   4.   5. --> ifftshift(fftshift(m))  ans  =    2.   5.   9.   3.   0.    2.   4.   5.   5.   6.    4.   1.   8.   5.   9. --> and(ifftshift(fftshift(m))==m)  ans  =   T BR Samuel ----- Mail d'origine ----- De: antoine monmayrant+scilab <[hidden email]> À: International users mailing list for Scilab. <[hidden email]>, List dedicated to development questions <[hidden email]> Envoyé: Tue, 09 Oct 2018 11:02:20 +0200 (CEST) Objet: [Scilab-users] fftshift and ifftshift are way too different Hello all,  From what I understand of fast Fourier transforms, fftshift and ifftshift should be almost identical. The only difference is when there are an odd number of elements in the dimension along which the shift is performed (ie fftshift([1:4])==ifftshift([1:4]) but fftshift([1:5])!=ifftshift([1:5])). However, it seems that in scilab6.x fftshift and ifftshift are based on completely different codes and do not accept the same arguments. In particular, with fftshift, one can specify the dimension along which to perform the shift, while it is not the case for ifftshift. I think some update of ifftshift would be welcome. I propose to use the code below (myifftshift), where I just changed "ceil" by "floor" in the definition if fftshift. What do you think, does it look right to you? Cheers, Antoine function x = myifftshift(x,job)      if argn(2)<2 then job="all",end      deff("sel=fun(sk)","c=floor(sk/2);sel=[c+1:sk,1:c]")      if job=="r" then job=1,elseif job=="c" then job=2,end      ind=list()      if job=="all" then          for sk=size(x),ind(\$+1)=fun(sk),end      else          for sk=size(x),ind(\$+1)=:,end;          ind(job)=fun(size(x,job))      end      x=x(ind(:)) endfunction _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users
Open this post in threaded view
|

## Re: Re : fftshift and ifftshift are way too different

 Hello Samuel, Sorry I might not have made myself clear: fft and fftshift provide the ability to perform transform along only one of the dimensions of a multidimensional array. Something like S(x,y,z) --[FFT along 3rd dim]--> ffthift(ffft(S(x,y,z), -1,3),3)=Ŝ(x,y,kz). In that case, you need to perform fft and eventually fftshift along only the dimension of the transform. ifftshift should also provide the same possibility to perform the inverse transform: Ŝ(x,y,kz) --[IFFT along 3rd dim]--> iffthift(ffft(Ŝ(x,y,kz), +1,3),3)=S(x,y,z). This is a basic signal processing requirement in my field. Cheers, Antoine Le 09/10/2018 à 16:05, [hidden email] a écrit : > Hello Antoine, > > fttshift() switches all halves along all dimensions. This is mandatory. > So for instance in 2D, opposite quadrants (wrt the center) are switched. > In 3D, opposite cubes are switched. etc. > > To me, the current implementation is right: > > --> m=grand(3,5,"uin",0,9) >   m  = >     2.   5.   9.   3.   0. >     2.   4.   5.   5.   6. >     4.   1.   8.   5.   9. > > --> fftshift(m) >   ans  = >     5.   9.   4.   1.   8. >     3.   0.   2.   5.   9. >     5.   6.   2.   4.   5. > > --> ifftshift(fftshift(m)) >   ans  = >     2.   5.   9.   3.   0. >     2.   4.   5.   5.   6. >     4.   1.   8.   5.   9. > > --> and(ifftshift(fftshift(m))==m) >   ans  = >    T > > BR > Samuel > > ----- Mail d'origine ----- > De: antoine monmayrant+scilab <[hidden email]> > À: International users mailing list for Scilab. <[hidden email]>, List dedicated to development questions <[hidden email]> > Envoyé: Tue, 09 Oct 2018 11:02:20 +0200 (CEST) > Objet: [Scilab-users] fftshift and ifftshift are way too different > > Hello all, > >   From what I understand of fast Fourier transforms, fftshift and > ifftshift should be almost identical. > The only difference is when there are an odd number of elements in the > dimension along which the shift is performed (ie > fftshift([1:4])==ifftshift([1:4]) but fftshift([1:5])!=ifftshift([1:5])). > However, it seems that in scilab6.x fftshift and ifftshift are based on > completely different codes and do not accept the same arguments. > In particular, with fftshift, one can specify the dimension along which > to perform the shift, while it is not the case for ifftshift. > I think some update of ifftshift would be welcome. > I propose to use the code below (myifftshift), where I just changed > "ceil" by "floor" in the definition if fftshift. > What do you think, does it look right to you? > > Cheers, > > Antoine > > function x = myifftshift(x,job) >       if argn(2)<2 then job="all",end >       deff("sel=fun(sk)","c=floor(sk/2);sel=[c+1:sk,1:c]") >       if job=="r" then job=1,elseif job=="c" then job=2,end >       ind=list() >       if job=="all" then >           for sk=size(x),ind(\$+1)=fun(sk),end >       else >           for sk=size(x),ind(\$+1)=:,end; >           ind(job)=fun(size(x,job)) >       end >       x=x(ind(:)) > endfunction > _______________________________________________ > users mailing list > [hidden email] > http://lists.scilab.org/mailman/listinfo/users> _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users
Open this post in threaded view
|

## Re: Re : fftshift and ifftshift are way too different

 Le 09/10/2018 à 21:52, antoine monmayrant a écrit : > Hello Samuel, > > Sorry I might not have made myself clear: fft and fftshift provide the > ability to perform transform along only one of the dimensions of a > multidimensional array. > Something like S(x,y,z) --[FFT along 3rd dim]--> > ffthift(ffft(S(x,y,z), -1,3),3)=Ŝ(x,y,kz). > In that case, you need to perform fft and eventually fftshift along > only the dimension of the transform. > ifftshift should also provide the same possibility to perform the > inverse transform: Ŝ(x,y,kz) --[IFFT along 3rd dim]--> > iffthift(ffft(Ŝ(x,y,kz), +1,3),3)=S(x,y,z). > > This is a basic signal processing requirement in my field. Hello Antoine, Yes, you are right: in case of directional FFT and odd number of elements along the chosen direction, ifftshift can't presently be used. Could you please post the same remark on bugzilla? This bug/wish is not yet reported. IMO we may propose and include it in Scilab as soon as for Scilab 6.0.2. BTW, still IMO, fftshift and ifftshift should rather be merged in a single function. It's the same code, except a floor<=>ceil. This should deserve just an option, not a separate dedicated function. I guess that this separation likely comes from a kind of abusive Matlab-like mimicry. Best regards Samuel _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users
Open this post in threaded view
|

## Re: Re : fftshift and ifftshift are way too different

 Le 10/10/2018 à 08:47, Samuel Gougeon a écrit : Le 09/10/2018 à 21:52, antoine monmayrant a écrit : Hello Samuel, Sorry I might not have made myself clear: fft and fftshift provide the ability to perform transform along only one of the dimensions of a multidimensional array. Something like S(x,y,z) --[FFT along 3rd dim]--> ffthift(ffft(S(x,y,z), -1,3),3)=Ŝ(x,y,kz). In that case, you need to perform fft and eventually fftshift along only the dimension of the transform. ifftshift should also provide the same possibility to perform the inverse transform: Ŝ(x,y,kz) --[IFFT along 3rd dim]--> iffthift(ffft(Ŝ(x,y,kz), +1,3),3)=S(x,y,z). This is a basic signal processing requirement in my field. Hello Antoine, Yes, you are right: in case of directional FFT and odd number of elements along the chosen direction, ifftshift can't presently be used. Could you please post the same remark on bugzilla? This bug/wish is not yet reported. OK, I'll put it in my TODO-list. IMO we may propose and include it in Scilab as soon as for Scilab 6.0.2. BTW, still IMO, fftshift and ifftshift should rather be merged in a single function. It's the same code, except a floor<=>ceil. This should deserve just an option, not a separate dedicated function. I guess that this separation likely comes from a kind of abusive Matlab-like mimicry. Yes, I agree. But I don't see how we can merge the two without increasing the huge halo of confusion that blurs the help pages and use of fft-related functions¹ ². The first idea that came to my mind was to make one single fftshift function where:  - if dim>0, you do direct shift (ie for a direct Fourier transform) along dimension dim;  - if dim<0, you do inverse shift (ie for an inverse Fourier transform) along dimension |dim|. But as "-1" means direct fft and "+1" inverse fft, mixing fft and fftshift would be a real mess. Antoine ¹ One I just discovered yesterday: the help page for fft is not listed in "Scilab Help >> Signal Processing > Transforms " ! Only ifft is listed, cool, he? Of course, ifft points to "Scilab Help >> Signal Processing > Transforms > fft". Idem  for dst, ... ² Oh, and this one cool too: in the fft help page: "incr a vector of positive numbers with integer values, or a vector of positive integers. See the Description part for details." but the Description never says what the heck "incr" is, does and means.... Arghhh. It only appears once in an example of a "previous syntax". Best regards Samuel _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users ```-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ Antoine Monmayrant LAAS - CNRS 7 avenue du Colonel Roche BP 54200 31031 TOULOUSE Cedex 4 FRANCE Tel:+33 5 61 33 64 59 email : [hidden email] permanent email : [hidden email] +++++++++++++++++++++++++++++++++++++++++++++++++++++++ ``` _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users
Open this post in threaded view
|

## Re: Re : fftshift and ifftshift are way too different

 Le 10/10/2018 à 09:21, [hidden email] a écrit : Le 10/10/2018 à 08:47, Samuel Gougeon a écrit : Le 09/10/2018 à 21:52, antoine monmayrant a écrit : Hello Samuel, Sorry I might not have made myself clear: fft and fftshift provide the ability to perform transform along only one of the dimensions of a multidimensional array. Something like S(x,y,z) --[FFT along 3rd dim]--> ffthift(ffft(S(x,y,z), -1,3),3)=Ŝ(x,y,kz). In that case, you need to perform fft and eventually fftshift along only the dimension of the transform. ifftshift should also provide the same possibility to perform the inverse transform: Ŝ(x,y,kz) --[IFFT along 3rd dim]--> iffthift(ffft(Ŝ(x,y,kz), +1,3),3)=S(x,y,z). This is a basic signal processing requirement in my field. Hello Antoine, Yes, you are right: in case of directional FFT and odd number of elements along the chosen direction, ifftshift can't presently be used. Could you please post the same remark on bugzilla? This bug/wish is not yet reported. OK, I'll put it in my TODO-list. IMO we may propose and include it in Scilab as soon as for Scilab 6.0.2. BTW, still IMO, fftshift and ifftshift should rather be merged in a single function. It's the same code, except a floor<=>ceil. This should deserve just an option, not a separate dedicated function. I guess that this separation likely comes from a kind of abusive Matlab-like mimicry. Yes, I agree. But I don't see how we can merge the two without increasing the huge halo of confusion that blurs the help pages and use of fft-related functions¹ ². You know, the most numerous pages we have about basically the same feature, the more inconsistencies between them we can get. The first idea that came to my mind was to make one single fftshift function where:  - if dim>0, you do direct shift (ie for a direct Fourier transform) along dimension dim;  - if dim<0, you do inverse shift (ie for an inverse Fourier transform) along dimension |dim|. I am not too convinced using the sign of dim to set the direction of the shift, because the dim sign could be used to something else more useful (and general) when dealing with an hypermatrix (to be discussed elsewhere). But as "-1" means direct fft and "+1" inverse fft, mixing fft and fftshift would be a real mess. Yes, having chosen the sign of the exponent as a flag to set the direction is not very handy/clear. But we must do with it now... Basically, flipdim() could do the same, by implementing  new "fft"|"ifft" values for its blockSize option. Antoine ¹ One I just discovered yesterday: the help page for fft is not listed in "Scilab Help >> Signal Processing > Transforms " ! Only ifft is listed, cool, he? Of course, ifft points to "Scilab Help >> Signal Processing > Transforms > fft". Idem  for dst, ... It is listed, but it depends on the way you get the list: Go to the Scilab help browser, and watch the list in the left margin : fft is listed, but not ifft Now, click on the fft help directory, still on the leftside list : in the page pannel, you get the list of contents of the help directory: here, ifft is listed, but not fft This is due to the bug 11633. It occurs when a page has multiple (titles) About ifft() and fft2(): to me, these both functions are completely useless. They do nothing more than what fft() can do. I presume they have been introduced again to mimic Matlab. What brings confusion. Formerly, there was also a mfft() in Scilab. We have removed it, since fft() does its job whatever is the number of dimensions of the input! To me, we must go on and remove fft2() and ifft(), or at least undocument them. This does not prevent to keep "fft2" and "ifft" tags in the fft() page, in order to get the fft() page when we type "help ifft" ; or even to keep also their code (but maintaining the Matlab-to-Scilab converter should be a priority instead!). But not to keep their pages. Or otherwise, to move them in the "Compatibility functions" module. To me, it's their only relevant place. ² Oh, and this one cool too: in the fft help page: "incr a vector of positive numbers with integer values, or a vector of positive integers. See the Description part for details." but the Description never says what the heck "incr" is, does and means.... Arghhh. It only appears once in an example of a "previous syntax". It is written: ```X=fft(A,sign,dims,incr [,option])``` is a previous syntax that also allows to perform all direct or inverse fft of the slices of `A` along selected dimensions. For example, if `A` is an array with `n1*n2*n3` elements `X=fft(A,-1,n1,1)` is equivalent to `X=fft(matrix(A,[n1,n2,n3]),-1,1)`. and ```X=fft(A,-1,[n1 n3],[1 n1*n2])``` is equivalent to `X=fft(matrix(A,[n1,n2,n3]),-1,[1,3])`. So, it is described ;) But it is rather unclear, indeed. You are welcome to reformulate it :) When 3 pages have to be written and maintained (in ideally 5 different languages en fr ja pt ru) instead of one, then the time and care than can be invested to write excellent pages is expectedly 3 times shorter for each one of them... _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users
Open this post in threaded view
|

## Re: Re : fftshift and ifftshift are way too different

 In reply to this post by Samuel GOUGEON Le 10/10/2018 à 08:47, Samuel Gougeon a écrit : > Le 09/10/2018 à 21:52, antoine monmayrant a écrit : >> Hello Samuel, >> >> Sorry I might not have made myself clear: fft and fftshift provide >> the ability to perform transform along only one of the dimensions of >> a multidimensional array. >> Something like S(x,y,z) --[FFT along 3rd dim]--> >> ffthift(ffft(S(x,y,z), -1,3),3)=Ŝ(x,y,kz). >> In that case, you need to perform fft and eventually fftshift along >> only the dimension of the transform. >> ifftshift should also provide the same possibility to perform the >> inverse transform: Ŝ(x,y,kz) --[IFFT along 3rd dim]--> >> iffthift(ffft(Ŝ(x,y,kz), +1,3),3)=S(x,y,z). >> >> This is a basic signal processing requirement in my field. > > Hello Antoine, > > Yes, you are right: in case of directional FFT and odd number of > elements along the chosen direction, ifftshift can't presently be used. > Could you please post the same remark on bugzilla? This bug/wish is > not yet reported. Done: http://bugzilla.scilab.org/show_bug.cgi?id=15799> > IMO we may propose and include it in Scilab as soon as for Scilab 6.0.2. > > BTW, still IMO, fftshift and ifftshift should rather be merged in a > single function. > It's the same code, except a floor<=>ceil. This should deserve just an > option, not a separate dedicated function. > I guess that this separation likely comes from a kind of abusive > Matlab-like mimicry. > > Best regards > Samuel > > _______________________________________________ > users mailing list > [hidden email] > http://lists.scilab.org/mailman/listinfo/users> -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++   Antoine Monmayrant LAAS - CNRS   7 avenue du Colonel Roche   BP 54200   31031 TOULOUSE Cedex 4   FRANCE   Tel:+33 5 61 33 64 59     email : [hidden email]   permanent email : [hidden email] +++++++++++++++++++++++++++++++++++++++++++++++++++++++ _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users
 Le 06/11/2018 à 10:52, Samuel Gougeon a écrit : Le 10/10/2018 à 12:39, [hidden email] a écrit : Le 10/10/2018 à 08:47, Samuel Gougeon a écrit : Le 09/10/2018 à 21:52, antoine monmayrant a écrit : Hello Samuel, Sorry I might not have made myself clear: fft and fftshift provide the ability to perform transform along only one of the dimensions of a multidimensional array. Something like S(x,y,z) --[FFT along 3rd dim]--> ffthift(ffft(S(x,y,z), -1,3),3)=Ŝ(x,y,kz). In that case, you need to perform fft and eventually fftshift along only the dimension of the transform. ifftshift should also provide the same possibility to perform the inverse transform: Ŝ(x,y,kz) --[IFFT along 3rd dim]--> iffthift(ffft(Ŝ(x,y,kz), +1,3),3)=S(x,y,z). This is a basic signal processing requirement in my field. Hello Antoine, Yes, you are right: in case of directional FFT and odd number of elements along the chosen direction, ifftshift can't presently be used. Could you please post the same remark on bugzilla? This bug/wish is not yet reported. Done: http://bugzilla.scilab.org/show_bug.cgi?id=15799 This complementary feature is now implemented and proposed for Scilab 6.0.2 there. Nice! BR Samuel ```_______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users ``` ```-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ Antoine Monmayrant LAAS - CNRS 7 avenue du Colonel Roche BP 54200 31031 TOULOUSE Cedex 4 FRANCE Tel:+33 5 61 33 64 59 email : [hidden email] permanent email : [hidden email] +++++++++++++++++++++++++++++++++++++++++++++++++++++++ ``` _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users