Unexpected getProfile behavior

Hi All,

First time poster. Normally, I find that strange macro code outputs are entirely due to my own hackery. This time, I’m stumped though. If anyone can confirm or explain the behavior below, I’d appreciate it.

In a nutshell, I need a macro function that outputs getProfile() based arrays with arbitary segment midpoint position, segment length, angle, and averaging width as inputs. It’s convenient to do this based on a midpoint pixel rather than to use the makeLine start & endpoint arguments directly.

That didn’t seem like a big deal until I wrote and tested the function and had some unexpected behavior pop up. The function works exactly as expected as long as the averaging width is kept at 1. If the averaging width is increased to more than 1, then the output array lengths are no longer the same size as angle is changed. I’ve played a little bit with different segment lengths and averaging widths, and can’t find any obvious consistency other than that the output array lengths are not constant if averaging width is more than 1.

Has this been observed before?

Script attached. Run it with any available 8bit image. First run: leave profile width = 1. Second run: change profile width to 2. Array lengths should be constant for profile width = 1 and show angle-dependent behavior for profile width = 2. (See attached screenshots of results for examples.)

Thanks!

Angle_profile_test.ijm (2.5 KB)

1 Like

OK- second post on the topic.

I’ve added a ‘v2’ of the demo script for the issue; it uses a synthetic image of a box around a center measuring point. (As an aside- this teaches how to write a work-around for the getProfile behavior, however, having it work as expected would be a better solution.)

Running the script with prof_w = 1 shows the expected behavior:

  1. all arrays are the same length (33);
  2. The arrays behave symmetrically vs. sweep angle. (i.e., the array at 40° is symmetric to the array at 50° as the sweep passes the box corner.)

Running the script with prof_w = 3 shows unexpected behavior:

  1. arrays now vary in length from 32-34;
  2. array symmetry around 0, 45, 90 etc. is broken.

I’ve also confirmed that some sweep radii show this behavior, and others don’t. (The default value for prof_r = 16 definitely shows it.)

One consequence of this is that the profiles of the same pixels measured in two different directions (i.e., 0° vs. 180°, 5° vs 185°, etc. will have direction-dependent offsets as the output array size varies. This is a significant nuisance.

Is this the right place to file this as a ‘bug report’? If not, where should I send the info instead? This seems like an issue with a basic workhorse function in IJ that could use attention. Thx!box_img_clip Angle_profile_test_v2.ijm (3.5 KB)

1 Like