While experimenting with real_domain_fft I noticed that this has different input shape requirements compared to complex_domain_fft. As a result, pad_modes in ['none', '2357'] will throw an error for some input shapes.
if real_domain_fft: check if shape after padding is odd in any dimension and increase shape by one.
It is not obvious whether handling pad_mode == None like this is desirable behaviour. If users don't want padding maybe a warning should be issued that padding happens anyway.
Edit:
While
https://www.tensorflow.org/api_docs/python/tf/signal/rfft3d
doesn't explicitly mention the permitted shape, the fact that fft_length / 2 positive-frequency terms are returned seems to confirm that even dimensions are rquired.
While experimenting with
real_domain_fftI noticed that this has different input shape requirements compared tocomplex_domain_fft. As a result,pad_modesin['none', '2357']will throw an error for some input shapes.A notebook to reproduce this is here: https://github.com/VolkerH/flowdec/blob/realdomainexperiments/python/examples/notebooks/experimenting%20with%20real_domain%20option.ipynb
I first noticed this here: https://github.com/VolkerH/Lattice_Lightsheet_Deskew_Deconv/issues/37
Suggested fix:
real_domain_fft: check if shape after padding is odd in any dimension and increase shape by one.It is not obvious whether handling
pad_mode == Nonelike this is desirable behaviour. If users don't want padding maybe a warning should be issued that padding happens anyway.Edit: While https://www.tensorflow.org/api_docs/python/tf/signal/rfft3d doesn't explicitly mention the permitted shape, the fact that
fft_length / 2 positive-frequency termsare returned seems to confirm that even dimensions are rquired.