Working with odd sizes images

[cyriltasse]

Is any good reason why pymoresane raises an exception while working with odd size images? As to the use of FFTs, odd sizes make more sense to me...

[JulienNGirard]

I stumbled upon the same thing during my previous attempts to use it. It happens that it only support even sized images, and I had either to crop it or recenter it when I wanted to use pymoresane.
I do not see a good reason either but that is indeed implemented as is (it is either due to the IUWT implementation or GPU related?)

[JSKenyon]

It has been quite a while since I looked at this. If I recall correctly, it was mainly a matter of convenience from an implementation perspective - at the time, I had never encountered a .fits image that had an odd size.

[cyriltasse]

So the reason why I'm asking is that I'm incorporating Moresane into SSD. It could be very great. The problem is that islands can have any sizes, and the fact that Moresane only accepts even sizes rises other problems... I can do fixes to this on the DDFacet side, but if there a possibility of having it to work with any sizes, it would be great...

[JSKenyon]

Hmm, I cannot really promise development from my side at the moment - CubiCal and my PhD have to take precedence. You are also free to do a PR on the PyMORESANE repository if you want to. I will take a brief look and see if I can recall what needs to be changed. I suspect that much of it has to do with slicing out central regions etc.

[cyriltasse]

ok - no worries, I'll take a look if I feel that's absolutly needed.

[landmanbester]

It would be great if DDFacet supported even sized grids since the current version of Nifty that I need for resolve only supports even grids. I did incorporate a hack which allows me to work with even sized grids for regular facets in the branch adding_resolve_dev but I wouldn't know where to begin for the general tessellation class. @cyriltasse if you get this working I'll owe you a beer and I will try to implement an image space version of resolve in SSD

[cyriltasse]

@landmanbester on the imager side, the difficultly is that the gridder and associated convolution functions needs to properly handle odd and even sizes... That's really tuff. Was easier to for me choose odd at the time. And also, I never got to understand what the fftshift is doing for even sizes and even what the fft itself is doing since there are missing terms. So I guess it has to zero the last row/column. I didn't like all this, and went to even, which is more natural. The main reason I guess is that the FFT in lapack is better at 2**n sizes (not that strongly so in FFTW).

So I'll need more than only one beer to motivate these changes on the DDFacet side of things. I prefer to spend a little time modifying pymoresane - which don't have such a good reason (at first glence) it seems to support only even sizes. :)

[cyriltasse]

... and it doesn't change the problem that for SSD, islands can be of any sizes....

[landmanbester]

Hmmm I suspected that this even/odd issue was causing the sensitivity to the initial guess I give resolve. It is the main reason why I haven't merged the adding_resolve branch into master. Here's to hoping the new version of Nifty supports odd sized grids...