Statistics output about connected-components-3d

[william-silversmith]

Okay, the latest version is released and should solve the problem.

…

On Wed, Dec 6, 2023 at 7:04 PM Chaitanya ***@***.***> wrote: Thanks for looking into this. If I change the test image to be ones only between [10:20, 10:20, 10:20] and zeros elsewhere the background centroid is still around [64, 64, 64]. That shouldn’t be the case right? — Reply to this email directly, view it on GitHub <#114 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATGQSKS67FL5DCG2JBBL3TYIEBZJAVCNFSM6AAAAABAKA5FHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBTHEYDCMRQGI> . You are receiving this because you commented.Message ID: ***@***.***>

[ckolluru]

Thanks @william-silversmith!

[william-silversmith]

Hi!

Thanks for writing in.

The first centroid is for label 0 and the second is for label 1.

I took at look at your example, and it seems the reason is a loss of precision in float32 as its summing across a large area. When I upgrade from float to double, the numbers come out right. Float32 can represent a large range, but only has full precision for integers up to 10^7.

512 * 511 / 2 * 512 * 512 = 34e9

I'll see if I can find a nice fix for this.

[william-silversmith]

It looks like this used to be float64 but there was a problem with memory consumption.

13d7c49

Hmm....

[ckolluru]

Thanks for looking into this.

If I change the test image to be ones only between [10:20, 10:20, 10:20] and zeros elsewhere the background centroid is still around [64, 64, 64]. That shouldn’t be the case right?

[william-silversmith]

That's also loss of precision and changing the foreground doesn't affect it that much since the vast majority of background pixels are black in both scenarios. When I change it to double, it gives something like the right result (256.29568989, 256.29568989, 256.29568989) which is still a bit off...

I have to figure out some way to prevent the sum from blowing up so high without sacrificing accuracy and memory efficiency.

[william-silversmith]

It was kind of tricky to figure out a method for doing this that used less memory than simply bumping to double, so I'll release a new version with that once the build completes. The precision for double is actually pretty good, I forgot to account for the large "hole" in the data before.

I'll let you know when the new version is released.