http://imagej.273.s1.nabble.com/1D-Fourier-transform-in-macro-tp5009727p5009767.html
in an ImageJ macro.
important. No "sophisticated things" are involved.
Of course you may write a dedicated IJ-plugin. If Ludovic had asked for
Java FFT code instead, I could have sent him some.
> Hi Herbie,
>
> I am sure your are right in pointing out that there is no *need* for another
> FFT algorithm, but when one's data is in the form of an array, derived e.g.
> from a z profile using code in the Z_Profiler plugin, it seems rather convoluted
> to have to copy those into an image (which you have to manage the creation
> and destruction of), use the built-in command(s), and then copy the values out
> again into another array.
>
> Is that really what people who want to derive e.g. a power spectrum from
> their 1d array data are expected to do?
>
> Francis
> ________________________________________
> From: ImageJ Interest Group [
[hidden email]] on behalf of Herbie [
[hidden email]]
> Sent: 25 September 2014 15:23
> To:
[hidden email]
> Subject: Re: 1D Fourier transform in macro
>
> Thanks Michael,
>
> I really wonder why Ludovic couldn't explain his desire in a sound way.
>
> Yes, of course, ImageJ can do a 1D FFT and in fact what you get in your
> test is what is to be expected. There is no need for another FFT-algorithm.
>
> BTW, except for the spectral value at the origin (DC-component) and for
> an amplitude scale factor, I get the same result from the FFT of the
> single line (PSF) image. Dividing the value at the origin by n should
> help with the exaggerated DC when taking the FFT of single line images.
>
> Best
>
> Herbie
>
> ::::::::::::::::::::::::::::::::::::::::
> On 25.09.14 15:03, Michael Schmid wrote:
>> Hi Herbie, Ludovic,
>>
>> to me it looks like Ludovic wants to do a prodecure as described
>> here:
>>
>>
http://www.irss.ca/documents/CODES%20&%20STANDARDS_02-28-08/ASTM%20Standards/PDF/E1695.PDF>>
>> The procedure is essentially determining the one-dimensional point
>> spread function (PSF) from the derivative of the image of an edge,
>> and then taking the Fourier transform of the PSF to find the
>> modulation transfer function (MTF).
>>
>> So it is really just the Fourier transform of the PSF that is
>> needed.
>>
>> For that purpose, I agree with Ludovic that no background should be
>> subtracted.
>>
>> So I tried creating a line with a PSF-like function, replicated it to
>> get a 32-bit square image with a size of 2^n, and ran FFT on it. The
>> raw power spectrum does not give a single pixel in the center but
>> rather a short streak. Then one can do 'Swap Quadrants', run
>> Math>Square Root, select a rectangle of only the first row and do a
>> profile. This profile should be the FFT required for converting the
>> PSF into the MTF.
>>
>> So one can do it without doing a 1D FFT.
>>
>>
>> Michael
>> ________________________________________________________________ On
>> Sep 25, 2014, at 11:14, Herbie wrote:
>>
>>> Ludovic,
>>>
>>> I must admit that I'm confused!
>>>
>>> First you wrote: "This is to perform direct _MTF_ evaluation from
>>> the profile"
>>>
>>> Now you write: "It is for _CT_ (reconstruction)"
>>>
>>> You also wrote: "What I get is a single _colored_ pixel"
>>>
>>> Now you write: "16bits unsigned _grey_ level"
>>>
>>> If you are indeed seeking to reconstruct images from CT projections
>>> (not profiles) then there exist several methods to do so. I'm quite
>>> familiar with CT but not with formal standards and norms.
>>>
>>> One way of reconstructing images from projections is by first
>>> Fourier-transforming all projections (you need at least n * PI/2
>>> projections, where n is the number of pixels of the properly
>>> sampled projections). The resulting 1D Fourier-spectra are then
>>> combined to give a 2D spectrum by properly rotated superposition of
>>> the 1D spectra. This 2D spectrum is to be corrected by the
>>> so-called rho-filter to compensate its 1/f_r amplitude
>>> characteristic. Finally the resulting 2D spectrum is
>>> Fourier-retransformed and results in the desired image.
>>>
>>> Principally you should be able to compute all steps by use of
>>> ImageJ and perhaps you will even find an appropriate
>>> ImageJ-plugin.
>>>
>>> In any case, the FFT must lead to complex-valued spectra. Power
>>> spectra make no sense in this application.
>>>
>>> Good luck
>>>
>>> Herbie
>>>
>>> :::::::::::::::::::::::::::::::::::::::: On 25.09.14 09:07, Ludovic
>>> Pinier wrote:
>>>> Herbie,
>>>>
>>>> the pictures I work with are 16bits unsigned grey level from a CT
>>>> machine (raw format). No color. And using a Fourier transform is
>>>> the method described in the standard applying to CT I use (ASTM
>>>> E-1695). This standard also prevents to remove the mean or alter
>>>> the contrast/brightness. To be standard-compliant, profile (the
>>>> "Edge Spread Function") is mandatory. You are only allowed to
>>>> frequency-filter it, and remove aberrant points. Even the Fourier
>>>> transform sampling has to be compliant with the standard
>>>> criteria. Concerning the Fourier transform, I am used to
>>>> manipulate time-frequency transforms, but not to deal with the
>>>> programming aspects. Last, my reason is that the tool built in
>>>> the machine is not accurate. And the "slanted edge method" plugin
>>>> is inappropriate for the geometry of my targets (which are also
>>>> defined according to the standard: material, shape and size). The
>>>> standard requires a line profile, and the slanted edge produces
>>>> an integration of the profile along the edge. I could use this
>>>> plugin with 1pixel-wide areas, but ,that means I need to rotate
>>>> the image; and even if is an as-accurate-as-possible
>>>> transformation, it is an interpolation that produces a calculated
>>>> image. It is not the direct capture from the sensor anymore. That
>>>> is also the reason why the slanted edge method was introduced in
>>>> the ISO12233. But unfortunately, the target definition in this
>>>> standard is inappropriate for my use.
>>>>
>>>> I know your suggestions could definitely help, but they don't
>>>> apply to my need.
>>>>
>>>> Best regards, Ludovic
>>>>
>>>> -- ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>>>>
>>>
>>> -- ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>>
>> -- ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>>
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>