Results table contains results partially shifted (polar coordinates from FFT)

fiji
imagej
macro
results-table
fourier

#1

Dear folks,

I think I’m having a strange observation and I cannot figure it out. I use this test image to play around (strangely when I try to properly upload the image the website cannot determine the size of the image - but this should not be a problem with respect to testing what I see):
image

I perform the following operations to extract polar coordinates from the FFT power spectrum:

width=getWidth;
height=getHeight;
run("FFT");
run("Set Measurements...", "integrated display redirect=None decimal=5");
    //for each pixel extract radius and angle
    for (i=0; i<width ; i++)
    {
    	for (j=0; j<height ; j++)
    	{
    		makePoint(i,j);
    		run("Measure");
    	}
    }

The above actions results in a table with 7 columns:
Label, X, Y, IntDen, RawInDent, R, Theta
Via hovering with the mouse over the FFT image you can read the polar coordinates in the ImageJ window, and use this to check data in the table. The results in the table appear to be slightly funny:
→ the results for R and Theta in the results table are shifted 1 row up from the rest of the data:
image

The easiest locations in the image to check is near the center of the FFT power spectrum, and near the corners / edges, e.g. these coordinates:
[0, 0]
[0, 127]
[127, 0]
[127, 127]
near [64, 64].

In my macro I adjust the results so that I can work further with the data, but I am very puzzled by this.
Am I having a brain fart :no_mouth: or is something indeed going wrong?


#2

I must admit that I never understood why positions in the power-spectral domain are numerically given in polar coordinates …

I can confirm your finding and I’m asking furthermore:
Shouldn’t the center position [64,64] give R = 0 and Theta = undefined?

Regards

Herbie


#3

Hello Herbie,

It is correct that the center position results should indeed be R = 0 and Theta = undefined. When hovering the mouse over that central point the main window shows this correct result.

When l place a point on that position (using the point tool) and press Ctrl+M to measure, this is not the case → you can actually get different results around that same pixel position [64, 64]:
image

In addition to my earlier observation where results on R and Theta are shifted one row in the Results table, I also have not been able to work out either why it is the case that different results can be collected within the same pixel.
Both these things cannot be correct, right?

  • Do you know if / how / where l should report the partially shifted results in the Results table?
  • I’ve tried to understand in the FFT.java source code as far as my basic skills allow me (https://imagej.nih.gov/ij/source/ij/plugin/FFT.java). Do you think the strange measurements at the center position could originate from something in there?

#4

As I’ve written, I can confirm your finding and more oddities.

Do you know if / how / where l should report the partially shifted results in the Results table?

Maybe @Wayne can have a look at the issue.

I’ve tried to understand in the FFT.java source code as far as my basic skills allow me. Do you think the strange measurements at the center position could originate from something in there?

Where else … ?

Independent of these problems, I hope that you are aware of the fact that power-spectra produced by calling FFT show logarithmically scaled values and that the way this is done is suboptimum. With log-scaled values one must define/restrict the number of displayed decades, otherwise the scaling is useless for scientific purposes.

Regards

Herbie


#5

Just curious (as I didn’t test it myself): could this be a race condition? I.e. does the results table oddity change if you put a wait(10); statement between creating the point and measuring it? Or if you switch setBatchMode(true);?


#6

Good day Jan,

I don’t think it’s a race condition because you can measure without any macro-code and the values for R and Theta at the exactly centered position of the point-selection are simply wrong.

Interestingly, point selections can be positioned with sub-pixel resolution.

Best

Herbie


#7

Hello @imagejan,

Thanks for your response, I’d never heard of race condition, something new to me :slight_smile:
I’ve tested your suggestions, individually as well as implementing both at the same time in the macro.

wait(10); was placed between creating the point and measuring there.
setBatchMode(true); was placed at the start of the code.

There was no impact on the R and Theta results that are shifted one row up compared with the rest of the data.