{ "id": 608742, "title": "Physical scale in the dataset", "url": "/competitions/MABe-mouse-behavior-detection/discussion/608742", "author_name": "", "post_date": "2025-09-22T00:33:01.967105900Z", "votes": 26, "comment_count": 2, "views": 0, "content": "

πŸ“ The competition dataset provides us with two references to physical scale in the scene of each video – arena_(width|height)_cm and pix_per_cm_approx; while video_(width|height)_pix gives us an additional form of boundary to the scene that can be combined with pix_per_cm_approx to express in physical length units.

\n

πŸ“Ή The logical interpretation of these multiple measurements seems straightforward to me: the arena describes the physical space the mice are restricted to, and the video dimensions refer to the frame captured by the camera's field of view and therefore the absolute limit on coordinates that can be tracked.

\n

It stands to reason (borne out in examples of raw video captured in the fully public datasets) that experiment designers want the frame to cover slightly more centimeters than the size of the arena so mice are cleanly tracked at all times, and furthermore a disparity in aspect ratio between the arena and camera may require larger margins in one axis to make this fit.

\n

Exploring the distribution of this margin, though, I was surprised how much variation there is in the relationship between arena and frame sizes, expressed here as a fraction:
\n\"Approx.
\nMost surprising of all was all of CautiousGiraffe's videos, which claim to show a 50cm square arena at 21pix per cm, which would require a 1050pix square frame to capture, but only a 600pix square frame provided. Did the mice really have more space to hang out off-camera than they did on-camera?! Well, no, it doesn't look like it.
\n\"Comparison
\n🧍 Tracking points from one of their videos show all parts of the mice remaining markedly well confined inside a square region comfortably within the frame, never heading off to visit other parts of the red square, that if we are to believe this interpretation of train.csv they were free to roam.

\n

Contrasting claims of very wide frames capturing a relatively small arena don't hold up in the tracking either:
\n\"Comparison
\nπŸ˜Άβ€πŸŒ«οΈ SparklingTapir/1127527475 claims to capture a 46Γ—12cm arena with its 836Γ—228pix frame but only get 8pix per cm. Yet this frame at that resolution would cover a rectangle more than double its linear size, but the mouse tracks in the data again suggest a sensibly framed arena with a little margin, allowing most of the frame to capture mouse movements at some point during the recording.

\n

In other cases, the dimensions provided are pretty believable under this interpretation:
\n\"Comparison
\nπŸ“Š But the extremes seem to affect hundreds of videos, aggregated here by area ratio:
\n\"Histogram
\nπŸ”Ž Oddly, the most abundant format of the dataset, MABe22, seems to have the opposite problem:
\n\"Comparison
\nThese videos all report metadata that sound like an arena filling most of the frame with a comfortable margin, but then at least some like this one show tracks clearly confined to a much smaller frame, though the full 800pix frame used throughout the dataset is covered at points within that dataset.

\n

πŸ€” So what gives? Is there a more coherent interpretation of the data that I haven't landed on? Is the quality control of entry on these metadata quantities so erratic that we should simply ensure that models learn strong scale-invariance from the outset? Has there been some corruption of these values at time of collation?

\n

All suggestions welcome!

\n

πŸ“œ All analysis discussed here is reproduced in this notebook.

", "messages": [ { "id": "3292496", "postDate": "09/22/2025 00:33:01", "content": "

πŸ“ The competition dataset provides us with two references to physical scale in the scene of each video – arena_(width|height)_cm and pix_per_cm_approx; while video_(width|height)_pix gives us an additional form of boundary to the scene that can be combined with pix_per_cm_approx to express in physical length units.

\n

πŸ“Ή The logical interpretation of these multiple measurements seems straightforward to me: the arena describes the physical space the mice are restricted to, and the video dimensions refer to the frame captured by the camera's field of view and therefore the absolute limit on coordinates that can be tracked.

\n

It stands to reason (borne out in examples of raw video captured in the fully public datasets) that experiment designers want the frame to cover slightly more centimeters than the size of the arena so mice are cleanly tracked at all times, and furthermore a disparity in aspect ratio between the arena and camera may require larger margins in one axis to make this fit.

\n

Exploring the distribution of this margin, though, I was surprised how much variation there is in the relationship between arena and frame sizes, expressed here as a fraction:
\n\"Approx.
\nMost surprising of all was all of CautiousGiraffe's videos, which claim to show a 50cm square arena at 21pix per cm, which would require a 1050pix square frame to capture, but only a 600pix square frame provided. Did the mice really have more space to hang out off-camera than they did on-camera?! Well, no, it doesn't look like it.
\n\"Comparison
\n🧍 Tracking points from one of their videos show all parts of the mice remaining markedly well confined inside a square region comfortably within the frame, never heading off to visit other parts of the red square, that if we are to believe this interpretation of train.csv they were free to roam.

\n

Contrasting claims of very wide frames capturing a relatively small arena don't hold up in the tracking either:
\n\"Comparison
\nπŸ˜Άβ€πŸŒ«οΈ SparklingTapir/1127527475 claims to capture a 46Γ—12cm arena with its 836Γ—228pix frame but only get 8pix per cm. Yet this frame at that resolution would cover a rectangle more than double its linear size, but the mouse tracks in the data again suggest a sensibly framed arena with a little margin, allowing most of the frame to capture mouse movements at some point during the recording.

\n

In other cases, the dimensions provided are pretty believable under this interpretation:
\n\"Comparison
\nπŸ“Š But the extremes seem to affect hundreds of videos, aggregated here by area ratio:
\n\"Histogram
\nπŸ”Ž Oddly, the most abundant format of the dataset, MABe22, seems to have the opposite problem:
\n\"Comparison
\nThese videos all report metadata that sound like an arena filling most of the frame with a comfortable margin, but then at least some like this one show tracks clearly confined to a much smaller frame, though the full 800pix frame used throughout the dataset is covered at points within that dataset.

\n

πŸ€” So what gives? Is there a more coherent interpretation of the data that I haven't landed on? Is the quality control of entry on these metadata quantities so erratic that we should simply ensure that models learn strong scale-invariance from the outset? Has there been some corruption of these values at time of collation?

\n

All suggestions welcome!

\n

πŸ“œ All analysis discussed here is reproduced in this notebook.

", "rawMarkdown": "πŸ“ The competition dataset provides us with two references to physical scale in the scene of each video – `arena_(width|height)_cm` and `pix_per_cm_approx`; while `video_(width|height)_pix` gives us an additional form of boundary to the scene that can be combined with `pix_per_cm_approx` to express in physical length units.\n\nπŸ“Ή The logical interpretation of these multiple measurements seems straightforward to me: the *arena* describes the physical space the mice are restricted to, and the *video* dimensions refer to the frame captured by the camera's field of view and therefore the absolute limit on coordinates that can be tracked.\n\nIt stands to reason (borne out in examples of raw video captured in the fully public datasets) that experiment designers want the frame to cover slightly more centimeters than the size of the arena so mice are cleanly tracked at all times, and furthermore a disparity in aspect ratio between the arena and camera may require larger margins in one axis to make this fit.\n\nExploring the distribution of this margin, though, I was surprised how much variation there is in the relationship between arena and frame sizes, expressed here as a fraction:\n![Approx. arena pixel dimensions as fraction of frame](https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F24737244%2F781443ba15be19ff36cee8c7af06153f%2Farena_2d_fractions.png?generation=1758502588253723&alt=media)\nMost surprising of all was all of `CautiousGiraffe`'s videos, which claim to show a `50`cm square arena at `21`pix per cm, which would require a `1050`pix square frame to capture, but only a `600`pix square frame provided. Did the mice really have more space to hang out off-camera than they did on-camera?! Well, no, it doesn't look like it.\n![Comparison of CautiousGiraffe/21954203 tracked coordinates, frame and arena](https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F24737244%2F29b8cf750cc05087566c0339625bf103%2FCautiousGiraffe_21954203.png?generation=1758496431555107&alt=media)\n🧍 Tracking points from one of their videos show all parts of the mice remaining markedly well confined inside a square region comfortably within the frame, never heading off to visit other parts of the red square, that if we are to believe this interpretation of `train.csv` they were free to roam.\n\nContrasting claims of very wide frames capturing a relatively small arena don't hold up in the tracking either:\n![Comparison of SparklingTapir/1127527475 tracked coordinates, frame and arena](https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F24737244%2F9e59995998976ff1914a4e28b55ba740%2FSparklingTapir_1127527475.png?generation=1758496958987824&alt=media)\nπŸ˜Άβ€πŸŒ«οΈ `SparklingTapir/1127527475` claims to capture a `46`Γ—`12`cm arena with its `836`Γ—`228`pix frame but only get `8`pix per cm. Yet this frame at that resolution would cover a rectangle more than double its linear size, but the mouse tracks in the data again suggest a sensibly framed arena with a little margin, allowing most of the frame to capture mouse movements at some point during the recording.\n\nIn other cases, the dimensions provided are pretty believable under this interpretation:\n![Comparison of SparklingTapir/2030735934 tracked coordinates, frame and arena](https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F24737244%2F1447ac1047fbe334dfbe80543cd837e2%2FSparklingTapir_2030735934.png?generation=1758497795344237&alt=media)\nπŸ“Š But the extremes seem to affect hundreds of videos, aggregated here by area ratio:\n![Histogram of arena-to-frame area ratios](https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F24737244%2Fb02c534f08d96a65405e629c20e93360%2Farena_area_fractions.png?generation=1758497905896068&alt=media)\nπŸ”Ž Oddly, the most abundant format of the dataset, `MABe22`, seems to have the opposite problem:\n![Comparison of MABe22_movies/9603 tracked coordinates, frame and arena](https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F24737244%2Fb4c4a6c2c752780d7b135bd394fde70e%2FMABe22_movies_9603.png?generation=1758498048140009&alt=media)\nThese videos all report metadata that sound like an arena filling most of the frame with a comfortable margin, but then at least some like this one show tracks clearly confined to a much smaller frame, though the full `800`pix frame used throughout the dataset is covered at points within that dataset.\n\nπŸ€” So what gives? Is there a more coherent interpretation of the data that I haven't landed on? Is the quality control of entry on these metadata quantities so erratic that we should simply ensure that models learn strong scale-invariance from the outset? Has there been some corruption of these values at time of collation?\n\nAll suggestions welcome!\n\nπŸ“œ All analysis discussed here is [reproduced in this notebook](https://www.kaggle.com/code/willhirsch/arena-size-in-mabe-sarm).", "votes": null }, { "id": "3292510", "postDate": "09/22/2025 02:09:16", "content": "

Thank you for raising this important point! I'm reviewing some of the source data now, but have a strong suspicion I know what happened.

\n

When we asked labs for metadata, we requested the resolution and pix/cm of the raw videos they collected. However, sometimes groups downsize their videos before running pose estimation, to speed up processing time- I suspect this is what happened in Giraffe and Tapir. On the other hand, MABe22_movies pose estimates were rescaled after tracking so they could be released alongside videos that had been downsized for space concerns- we missed this rescaling in the metadata and will correct it.

\n

In practice, some scale-invariance in your models is probably a good idea as arena size doesn't always get reported accurately. But egregious differences like you report here should be corrected in the metadata- we'll get right on it!

", "rawMarkdown": "Thank you for raising this important point! I'm reviewing some of the source data now, but have a strong suspicion I know what happened.\n\nWhen we asked labs for metadata, we requested the resolution and pix/cm of the raw videos they collected. However, sometimes groups downsize their videos before running pose estimation, to speed up processing time- I suspect this is what happened in Giraffe and Tapir. On the other hand, MABe22_movies pose estimates were rescaled after tracking so they could be released alongside videos that had been downsized for space concerns- we missed this rescaling in the metadata and will correct it.\n\nIn practice, some scale-invariance in your models is probably a good idea as arena size doesn't always get reported accurately. But egregious differences like you report here should be corrected in the metadata- we'll get right on it!", "votes": null }, { "id": "3294374", "postDate": "09/26/2025 02:55:01", "content": "

on a side note: i suggest you also color the blue (x,y) dots in the diagrams with behaviour class. i think you are going to see something.
\n i think there are mice marked territory by scent etc

", "rawMarkdown": "on a side note: i suggest you also color the blue (x,y) dots in the diagrams with behaviour class. i think you are going to see something.\n i think there are mice marked territory by scent etc", "votes": null } ], "comments": [ { "id": 3292510, "author_name": "annkennedy05", "author_url": "", "post_date": "09/22/2025 02:09:16", "content": "

Thank you for raising this important point! I'm reviewing some of the source data now, but have a strong suspicion I know what happened.

\n

When we asked labs for metadata, we requested the resolution and pix/cm of the raw videos they collected. However, sometimes groups downsize their videos before running pose estimation, to speed up processing time- I suspect this is what happened in Giraffe and Tapir. On the other hand, MABe22_movies pose estimates were rescaled after tracking so they could be released alongside videos that had been downsized for space concerns- we missed this rescaling in the metadata and will correct it.

\n

In practice, some scale-invariance in your models is probably a good idea as arena size doesn't always get reported accurately. But egregious differences like you report here should be corrected in the metadata- we'll get right on it!

", "votes": null, "replies": [] }, { "id": 3294374, "author_name": "hengck23", "author_url": "", "post_date": "09/26/2025 02:55:01", "content": "

on a side note: i suggest you also color the blue (x,y) dots in the diagrams with behaviour class. i think you are going to see something.
\n i think there are mice marked territory by scent etc

", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "3292496": "πŸ“ The competition dataset provides us with two references to physical scale in the scene of each video – `arena_(width|height)_cm` and `pix_per_cm_approx`; while `video_(width|height)_pix` gives us an additional form of boundary to the scene that can be combined with `pix_per_cm_approx` to express in physical length units.\n\nπŸ“Ή The logical interpretation of these multiple measurements seems straightforward to me: the *arena* describes the physical space the mice are restricted to, and the *video* dimensions refer to the frame captured by the camera's field of view and therefore the absolute limit on coordinates that can be tracked.\n\nIt stands to reason (borne out in examples of raw video captured in the fully public datasets) that experiment designers want the frame to cover slightly more centimeters than the size of the arena so mice are cleanly tracked at all times, and furthermore a disparity in aspect ratio between the arena and camera may require larger margins in one axis to make this fit.\n\nExploring the distribution of this margin, though, I was surprised how much variation there is in the relationship between arena and frame sizes, expressed here as a fraction:\n![Approx. arena pixel dimensions as fraction of frame](https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F24737244%2F781443ba15be19ff36cee8c7af06153f%2Farena_2d_fractions.png?generation=1758502588253723&alt=media)\nMost surprising of all was all of `CautiousGiraffe`'s videos, which claim to show a `50`cm square arena at `21`pix per cm, which would require a `1050`pix square frame to capture, but only a `600`pix square frame provided. Did the mice really have more space to hang out off-camera than they did on-camera?! Well, no, it doesn't look like it.\n![Comparison of CautiousGiraffe/21954203 tracked coordinates, frame and arena](https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F24737244%2F29b8cf750cc05087566c0339625bf103%2FCautiousGiraffe_21954203.png?generation=1758496431555107&alt=media)\n🧍 Tracking points from one of their videos show all parts of the mice remaining markedly well confined inside a square region comfortably within the frame, never heading off to visit other parts of the red square, that if we are to believe this interpretation of `train.csv` they were free to roam.\n\nContrasting claims of very wide frames capturing a relatively small arena don't hold up in the tracking either:\n![Comparison of SparklingTapir/1127527475 tracked coordinates, frame and arena](https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F24737244%2F9e59995998976ff1914a4e28b55ba740%2FSparklingTapir_1127527475.png?generation=1758496958987824&alt=media)\nπŸ˜Άβ€πŸŒ«οΈ `SparklingTapir/1127527475` claims to capture a `46`Γ—`12`cm arena with its `836`Γ—`228`pix frame but only get `8`pix per cm. Yet this frame at that resolution would cover a rectangle more than double its linear size, but the mouse tracks in the data again suggest a sensibly framed arena with a little margin, allowing most of the frame to capture mouse movements at some point during the recording.\n\nIn other cases, the dimensions provided are pretty believable under this interpretation:\n![Comparison of SparklingTapir/2030735934 tracked coordinates, frame and arena](https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F24737244%2F1447ac1047fbe334dfbe80543cd837e2%2FSparklingTapir_2030735934.png?generation=1758497795344237&alt=media)\nπŸ“Š But the extremes seem to affect hundreds of videos, aggregated here by area ratio:\n![Histogram of arena-to-frame area ratios](https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F24737244%2Fb02c534f08d96a65405e629c20e93360%2Farena_area_fractions.png?generation=1758497905896068&alt=media)\nπŸ”Ž Oddly, the most abundant format of the dataset, `MABe22`, seems to have the opposite problem:\n![Comparison of MABe22_movies/9603 tracked coordinates, frame and arena](https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F24737244%2Fb4c4a6c2c752780d7b135bd394fde70e%2FMABe22_movies_9603.png?generation=1758498048140009&alt=media)\nThese videos all report metadata that sound like an arena filling most of the frame with a comfortable margin, but then at least some like this one show tracks clearly confined to a much smaller frame, though the full `800`pix frame used throughout the dataset is covered at points within that dataset.\n\nπŸ€” So what gives? Is there a more coherent interpretation of the data that I haven't landed on? Is the quality control of entry on these metadata quantities so erratic that we should simply ensure that models learn strong scale-invariance from the outset? Has there been some corruption of these values at time of collation?\n\nAll suggestions welcome!\n\nπŸ“œ All analysis discussed here is [reproduced in this notebook](https://www.kaggle.com/code/willhirsch/arena-size-in-mabe-sarm).", "3292510": "Thank you for raising this important point! I'm reviewing some of the source data now, but have a strong suspicion I know what happened.\n\nWhen we asked labs for metadata, we requested the resolution and pix/cm of the raw videos they collected. However, sometimes groups downsize their videos before running pose estimation, to speed up processing time- I suspect this is what happened in Giraffe and Tapir. On the other hand, MABe22_movies pose estimates were rescaled after tracking so they could be released alongside videos that had been downsized for space concerns- we missed this rescaling in the metadata and will correct it.\n\nIn practice, some scale-invariance in your models is probably a good idea as arena size doesn't always get reported accurately. But egregious differences like you report here should be corrected in the metadata- we'll get right on it!", "3294374": "on a side note: i suggest you also color the blue (x,y) dots in the diagrams with behaviour class. i think you are going to see something.\n i think there are mice marked territory by scent etc" }, "source": "meta" }