Legacy ImageMagick Discussions Archive

fmw42 wrote:

Oh please, don't quote WP as a reference for anything. It's like watching a Hollywood film "based on a true story" and imagining you are learning history.

So are you saying that it is wrong. A lot of experts have contributed to Wikipedia. So there must be something to it. I cannot explain to you but using the real sinc or jinc to recover the image from motion blur and defocus (without an imaginary component) works.

I'm not saying any particular topic is "wrong", I'm saying it is not a reliable reference, so I do not refer to it. Aside "a lot of experts" there are also a lot of idiots who edit WP. There is no restriction who edits WP so there is no reason to believe those who contribute are "expert". I won't waste further time on that issue here.

fmw42 wrote:

I am not aware of any fast DFT that actually operates in polar co-ordinates (not to say it can't be done). My guess is that either IM converts when you use -fft or FFTW does it internally. By using +fft or -fft you are simply stating in what form you wish to have the output. That the two are consistent does prove or confirm anything is correct.

FFT or DFT etc, do not use polar coordinates and I never said so. The fact that the jinc is circular symmetric comes from the fact that the spatial transform or PSF is a circle for defocus. This has nothing to do with the workings of the FFT.

So we're agreed , the fact that to two results match does not verify anything because they come from the same source.

fmw42 wrote:

Could you post a code snip that demonstrates that?

No, my conclusions are based on getting the same kind of results from simulations and real defocus images. If I use the fftdeconvol using a circle filter or I use the cameradeblur using a jinc, they both correct the defocus. The fftdeconvol has to deal however with the fact that the digital circle is not perfect, especially for small circles. Nevertheless, the both deblur the image. Both methods use real-imaginary FFT components of the image. fftdeconvol use real/imaginary components for the fft of the circle filter. cameradeblur uses on the jinc as the real part.

So how can I access this "internal", not mucked about with, transform?

As far as I know, you cannot in mag phase, only from real/imaginary in HDRI mode. You could use those to regenerate mag phase without any scaling if you want.

OH What?! More undocumented "features" . No wonder I can't follow what IM is doing. Whenever I try to pull out an intermediary step to see what is going on it gets "converted" so I can see it.

I have edited the docs to bring them up to speed with the current IM FFT. If you find any other issues or have questions, then please notify us and we will try to fix them as quickly as possible.

Well if the actual result of the transform is not available that probably should be made very clear. If IM retains some internal copy this probably needs explaining because I saw no mention of this is the doc. Thanks for updating the other issue.

fmw42 wrote:
If you are unhappy with IM's approach to FFT, you are free to use other software. I have already suggested two -- ImageJ and FFTJ. I am sure there are lots of other tools out there.

Well each new bit of software is another set of instructions and syntax to learn and they will have their short-comings too. At some point it is necessary to understand the restrictions and work around them. That is what I'm trying to do, though the process is somewhat impeded by unexpected behaviour that is not documented.

Hopefully raising these issues will allow them to be corrected.

But I really don't know how to interpret the phase profile. It seems to have very high frequency oscillations within slower osciallations, the later of which seem to match the cycles in the mag profile.

I suspect the hf is spurious, I think the correct phase is a linear ramp.

I know that FFTW is a widely used and respected library but as its name suggests the design criteria are speed more than accuracy. It is widely used in video and audio applications where scientific rigour is not essential but speed is.

This may be a result of design choices.

[EDIT]
Their site does not seem to indicate this kind of issue. Not sure what to make of this.

I'm not saying any particular topic is "wrong", I'm saying it is not a reliable reference, so I do not refer to it. Aside "a lot of experts" there are also a lot of idiots who edit WP. There is no restriction who edits WP so there is no reason to believe those who contribute are "expert". I won't waste further time on that issue here.

There are reference to those tables to very respectable books. I think we are just missing something in the interpretation. I don't agree that it is not reliable at least not in this case. If there were idiots putting up a lot of garbage, then either the experts would replace it with correct stuff or WP would be totally useless and go away. I think you are too hard on them. People put up a lot of stuff that comes from very particular points of view that may not be very informative or helpful, but I doubt it is really wrong.

So we're agreed , the fact that to two results match does not verify anything because they come from the same source.

I absolutely do not agree. All I am saying is that FFT does not do anything in the polar coordinate system, unless you are considering mag/phase as polar. But even then, the FFT only produces real/imaginary and other processing converts it to mag/phase.

I still believe the fact that I can reproduce the mag/phase images that other tools generate by using the real/imaginary components indicates that IM is doing things correctly whether by mag/phase or real/imaginary. The point is they both agree with what is generated by several other FFT tools.

Well if the actual result of the transform is not available that probably should be made very clear.

The real/imaginary components are what all FFT tools including IM produces as raw data. It is then up to the software tool whether to convert to mag/phase. Furthermore, it is stated clearly now that the HDRI and non-HDRI forms of phase are scaled from 0,2pi to 0,quantumrange. All other components are unscaled. It would be very easy to process the phase to multiply by 2pi/quantumrange to get back to unscaled values.

As I said, I have corrected the documents to the best of my ability to make your points clear. If I have missed something, please let me know. If you have any questions about it then please ask.

I suspect the hf is spurious, I think the correct phase is a linear ramp.

Well, I thought you said that the phase should be a cosine from Wolfram? So it cannot be both? I for one do not know what to expect from the phase.

I know that FFTW is a widely used and respected library but as its name suggests the design criteria are speed more than accuracy. It is widely used in video and audio applications where scientific rigour is not essential but speed is.

I do not agree. It is as accurate as any FFT software (and has as much or more accuracy than needed to do a proper job on image processing applications) and has plenty of flexibility. However, you should note that it is a combination of DFT and HFT (Hartley Transforms). FFTs generally only work on power of two size images. At least that was the way it was originally and when I used it 30 years ago (from the Cooley-Tukey approach).

Their site does not seem to indicate this kind of issue. Not sure what to make of this.

I don't know what issue you are referring to? If the scaling of phase, that is outside the bounds of the FFTW software, which only generates the real/imaginary (complex) data. All further processing must be done by the subsequent application.

Yes magnitude and phase is a polar co-ord system, the complex plane in a cartesian representation. The two are equivalent expressions of the same thing, so a result in one frame cannot confirm a result in the other , it's the same thing.
Yes that provides a degree of corroboration. Does it still work if you roll back to the origin?

Does it still work if you roll back to the origin?

It depends upon what you mean by "it". If you are talking about computing mag/phase from real/imaginary, then I would not expect otherwise. I have not tried it. I don't see why that would matter. Rolling the image, just shifts the fft whether it is real/imaginary or mag/phase. One should still be able to generate the mag/phase from the real/imaginary, but the resulting origin will be rolled in either case.

If you do not roll the filter PSF image (when using my fftconvol fftdeconvol), so that the line or circle is centered at the top/left, then you will get a recovery image that is rolled and hard to view. But my fftconvol and fftdeconvol assume the line or circle is centered in the image and rolls the filter image before processing, so that you don't have to roll the filter -- it is taken care of for you.

If you are doing your own script, then you would need to leave the image alone and roll the PSF line or circle filter so that its center is at the upper left corner. That would result in the resulting restoration in the centered same as the input. If you don't roll the filter, then your restoration will be split into quadrants centered at the top left corner and need to rolled to put the center back at the center of the image. But the restoration should be no different.