upsampling

[jtlz2]

Hi - extremely useful code - thank you. Using it to upsample a radio map. One question about http://image-registration.readthedocs.org/en/latest/_modules/image_registration/fft_tools/upsample.html#upsample_image

As written, the image, which originally contained both positive and negative values, came out with only positive values when upsampled. I think it's because of the return numpy.abs(ups) statement. Hacking this to return np.real(ups) seemed to help, but that's a bit dangerous in case there are any imaginary values (I can't think why there might be... better revise that...).

Any thoughts on this?

Also, what's the difference in practice between use_numpy_fft=True/False?

[keflavich]

use_numpy_fft is a switch to choose between different implementations of fft, e.g. fftw and fftw3. It shouldn't matter in practice, but can result in slight speed differences.

The questions about .real vs abs vs complex results are reasonable and interesting - I'll investigate further if I get a chance. Short answer, though: I think, especially for the Fourier Upsampling techniques, only the real data have meaning (as long as real data were input)

[jtlz2]

Thanks - do you know which is faster by any chance (or I shall time it). Re real data -> real data - I agree, but a second opinion would be v helpful!

[keflavich]

https://code.google.com/p/agpy/source/browse/trunk/tests/test_ffts.py has fft benchmarks

[jtlz2]

@keflavich

The questions about .real vs abs vs complex results are reasonable and interesting - I'll investigate further if I get a chance. Short answer, though: I think, especially for the Fourier Upsampling techniques, only the real data have meaning (as long as real data were input)

The way I handled this in the end for a total-intensity map (Stokes I, i.e. any real values) was indeed to change return np.abs(ups) to return np.real(ups).

BUT, for a polarization map (P=sqrt{Q^2+U^2}, i.e. any non-negative values), this fails in that upsample_image produces some negative (unphysical) artifacts. Any pointers? Can you think of the correct way to handle this?

[keflavich]

could you include an example of the artifacts? I'm not sure off the top of my head...

[jtlz2]

I think there may be an implicit assumption that the image has to be non-negative: If I input an image of purely negative numbers, the upsampling function (when using np.abs(ups)) gives back purely positive values (by eye it looks to be inverted). A workaround would be to apply an offset before upsampling.

[keflavich]

@jtlz2 sorry, I still don't fully understand the issue. If you can create an example to include as a test in the package, I can include it and try to debug. I'd welcome a pull request if you figure anything out!

[jtlz2]

@keflavich OK here is a simple case that fails:

import numpy
from image_registration.fft_tools import upsample_image
i = -1.0*numpy.ones((2,2))
print i
r = upsample_image(i,upsample_factor=1,use_numpy_fft=True)
print r
assert((r==i).all()), 'with upsample_factor=1, should give back the original array'

The output is: [[-1. -1.] [-1. -1.]] [[ 1. 1.] [ 1. 1.]] AssertionError: with upsample_factor=1, should give back the original array

i.e. the np.abs(ups) has caused an inversion.

[keflavich]

Sorry about the long delay. I think you're right that that is in error; it may be that we need to use np.real(ups) instead of np.abs(ups). I'll try to fix this as part of #8