Bogus measurement appears in results file in Fiji

Tags: #<Tag:0x00007fd698ba0470>


I am using Fiji (ImageJ) to measure annual growth rings of a tree using the same simple macro I have used for years. When trying to measure one ring (which happens to be #96), a bogus measurement appears in the results file. I have set measurement to “perimeter”, and right-hand column is the ring measurement in hundreths of a mm. Here is the culprit below (#96)—You can see it if you scroll down. Note that the bogus measurement is an entirely new field that offsets the actual measurement to the right. This is the kind of glitch that I would randomly encounter in the old NIH Image 20 years ago occasionally. I can at least see the problem, but thought I’d bring it to the attention of the forum in case someone had insights about what was going on.

95 0 -67.203 39.461
96 42427.513 110.556 94.452
97 0 -66.631 88.501


Could you post the macro?


And the image you get the alleged error from, please. Otherwise it will be difficult to know what is going on.


I second the request of others to please include your macro, and ideally your data, so that we can attempt to reproduce.

That said, I do not see any extra measurements shown in your snippet above. The “offset to the right” is a trick of the eye: the pasted text uses tabs, and the 42427.513 measurement is long enough that the subsequent tab shunts the remaining numbers one column to the right. But if you plot this in a table, it looks like:

95 0 -67.203 39.461
96 42427.513 110.556 94.452
97 0 -66.631 88.501


I am assuming 42427.513 is known to supposed to be 0; just like the other values in the example.


OK, Here is the macro:

macro "measring2 [z]" {

I use it for measuring the length (perimeter) of an annual growth ring in scanned images of polished wood. Sorry, I cannot include the image. It is 59 megabytes in size. We scan at 2540 dpi in order to measure at 0.01mm resolution. Here is the dropbox link to the file in question:

At this point, I’m able to see that the file is fine except for the odd large value that appears in the 96th measurement row instead of zero. Note that correct measurement does indeed appear in the results file produced by the measurements. I appreciate your efforts at trying to figure this out. At this point, it’s minor annoyance. if it happens again, then I’ll bring this to your attention.


What are the values being recorded?