I'm doing a forward FFT using ippsFFTFwd_RToPack_64f(pSrc.data(), pDst.data(), pSpec64, pBuffer), which writes waveformLen elements to pDst (pSrc.size() == waveformLen).
Then, I'm trying to convert pDst to complex numbers, with ippsConjPack_64fc(pDst.data(), fftResIPP.data(), waveformLen). What I don't understand is why the output vector, fftResIPP, needs to be the same size as the input vector, pDst.
According to the format specification, the Pack format is the first half plus one of the FFT bins, listed as alternating the real and imaginary values, skipping the imaginary value for the first and last FFT bin. I understand that makes the Pack format the same length as the input to the FFT.
However, when converting it to complex, I would think the resulting vector would be (N-2)/2 + 2 times as long as the Pack vector, as it would be combining every two into a complex value, except the first and last, which have a 0 imaginary value.
From what I understand:
input: [x,x,x,x] (4 values)
output complex: 0.1+0i, 0.5+3i, 1+2i, 0.3+0i, -0.3-0i, -1-2i, -0.5-3i, -0.1-0i (8 values)
output pack: 0.1, 0.3, 3, 1, 2, 0.3, 0, -0.3 (8 values)
However, when I try running the sample pack to complex conversion function, but with the different length, (waveformLen - 2) / 2 + 2, as so: ippsConjPack_64fc(pDst.data(), fftResIPP.data(), (waveformLen - 2) / 2 + 2 ), the program crashes.
On the ConjPack page, a different impression of the Pack format is presented. This time it appears that the Pack format uses a type of compression which is not immediately recognizable or available (I don't see a complex to Pack function in the IPP developer reference).
