![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F10704200%2F958e1f592da9e12b52487d337303748e%2FUncorrected.png?generation=1734991531448658&alt=media\")
Pretty minor point, but you can see this if you add all of the images together for a given particle. If you do, you will see the images are slightly off center by about 1/2 a pixel. What this means is the correct transformation to get from the x,y,z coordinate grid to the i,j,k pixel grid is actually:
\ni = int(x/10.012 + 0.5)
\nand not
\ni = int(x/10.012)
\nThe latter works when the origin is the corner of the first pixel instead of the center. (Obviously replace i and x for the other dimensions.)
\nHere is Apo-Ferritin without the correction:
\n
And here is the corrected version:
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F10704200%2Fe2bcd60a8a5b33af5e9d8639089b776a%2FCorrected.png?generation=1734991554870650&alt=media\")
Note that the outer circle is there to prove that the issue isn't with the circle graphic.
", "messages": [ { "id": "3079596", "postDate": "12/23/2024 21:54:08", "content": "Pretty minor point, but you can see this if you add all of the images together for a given particle. If you do, you will see the images are slightly off center by about 1/2 a pixel. What this means is the correct transformation to get from the x,y,z coordinate grid to the i,j,k pixel grid is actually:
\ni = int(x/10.012 + 0.5)
\nand not
\ni = int(x/10.012)
\nThe latter works when the origin is the corner of the first pixel instead of the center. (Obviously replace i and x for the other dimensions.)
\nHere is Apo-Ferritin without the correction:
\n
And here is the corrected version:
\n
Note that the outer circle is there to prove that the issue isn't with the circle graphic.
", "rawMarkdown": "Pretty minor point, but you can see this if you add all of the images together for a given particle. If you do, you will see the images are slightly off center by about 1/2 a pixel. What this means is the correct transformation to get from the x,y,z coordinate grid to the i,j,k pixel grid is actually:\n\ni = int(x/10.012 + 0.5)\n\nand not\n\ni = int(x/10.012)\n\nThe latter works when the origin is the corner of the first pixel instead of the center. (Obviously replace i and x for the other dimensions.)\n\nHere is Apo-Ferritin without the correction:\n\n\n\nAnd here is the corrected version:\n\n\n\nNote that the outer circle is there to prove that the issue isn't with the circle graphic.", "votes": null }, { "id": "3079618", "postDate": "12/23/2024 22:56:47", "content": "Hi. What about i = np.rint(x/10.012)?
Yeah, that should work. Adding 0.5 and then truncating is essentially the same as rounding. np.rint() has some weird rounding rules, but those almost certainly would have no meaningful effect.
", "rawMarkdown": "Yeah, that should work. Adding 0.5 and then truncating is essentially the same as rounding. np.rint() has some weird rounding rules, but those almost certainly would have no meaningful effect.", "votes": null }, { "id": "3079854", "postDate": "12/24/2024 08:25:49", "content": "Good catch, but it shouldn't matter if you are consistent in your training/inference approaches. The model learns such systematic errors without problems.
", "rawMarkdown": "Good catch, but it shouldn't matter if you are consistent in your training/inference approaches. The model learns such systematic errors without problems.", "votes": null }, { "id": "3079867", "postDate": "12/24/2024 08:49:25", "content": "It may matter for labels…well, probably not by much…but it certainly shouldn't hurt. Honestly, it may only answer the question, why are things a little off when you add all the particles together. 😀
", "rawMarkdown": "It may matter for labels...well, probably not by much...but it certainly shouldn't hurt. Honestly, it may only answer the question, why are things a little off when you add all the particles together. 😀", "votes": null }, { "id": "3081940", "postDate": "12/27/2024 12:44:28", "content": "Such errors will no longer be systematic in case of rotation or flip augmentations. So IMO such details may matter especially considering the variability of labeling and that the maximal distance to GT for prediction to be correct is 3-7 pixels depending on particle type.
\nIn my case, this is also supported by empirical results in 4 out of 4 comparisons.
@bohdanmahometa
\nDo you see a difference between masks generated with voxel size 10 and 10.012? I don't see any difference as masks are generated in fp64 and then thresholded to 0-1. This allows for subpixel mask accuracy. I checked for masks created both ways and couldn't find any difference between them. But I didn't dig too deply into it.
Hi. What about i = np.rint(x/10.012)?
Yeah, that should work. Adding 0.5 and then truncating is essentially the same as rounding. np.rint() has some weird rounding rules, but those almost certainly would have no meaningful effect.
", "votes": null, "replies": [] } ] }, { "id": 3079854, "author_name": "sakvaua", "author_url": "", "post_date": "12/24/2024 08:25:49", "content": "Good catch, but it shouldn't matter if you are consistent in your training/inference approaches. The model learns such systematic errors without problems.
", "votes": null, "replies": [ { "id": 3079867, "author_name": "davidlist", "author_url": "", "post_date": "12/24/2024 08:49:25", "content": "It may matter for labels…well, probably not by much…but it certainly shouldn't hurt. Honestly, it may only answer the question, why are things a little off when you add all the particles together. 😀
", "votes": null, "replies": [] }, { "id": 3081940, "author_name": "bohdanmahometa", "author_url": "", "post_date": "12/27/2024 12:44:28", "content": "Such errors will no longer be systematic in case of rotation or flip augmentations. So IMO such details may matter especially considering the variability of labeling and that the maximal distance to GT for prediction to be correct is 3-7 pixels depending on particle type.
\nIn my case, this is also supported by empirical results in 4 out of 4 comparisons.
@bohdanmahometa
\nDo you see a difference between masks generated with voxel size 10 and 10.012? I don't see any difference as masks are generated in fp64 and then thresholded to 0-1. This allows for subpixel mask accuracy. I checked for masks created both ways and couldn't find any difference between them. But I didn't dig too deply into it.