\n(aneurysm labelled 8)
\n
![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F3537669%2F7300ff8242c8b045e3ee8e2b2de1a9db%2F1.2.826.0.1.3680043.8.498.10134365079002163886508836892471866754.58.png?generation=1755935140188984&alt=media\")
Hi @evancalabrese,
\nI found two issues relating to the update of the train_localizer.csv file, specifically with respect to the coordinates for the multi-frame MR series:
Series 1.2.826.0.1.3680043.8.498.10733938921373716882398209756836684843: both aneurysms have the same coordinates! One set must be right, the other set be wrong… (and we need the correct set for the latter)
It appears that the 'f' value has been established on a 1-to-n range, instead of a 0-to-n range, which is the Python standard. I'll provide two examples:
Series 1.2.826.0.1.3680043.8.498.10134365079002163886508836892471866754, frame 58
\n(aneurysm labelled 8)
\n
Series 1.2.826.0.1.3680043.8.498.10134365079002163886508836892471866754, frame 57
\n(the aneurysm is more visible here)
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F3537669%2F9345101d5721bb15c7ac452fdf93bd15%2F1.2.826.0.1.3680043.8.498.10134365079002163886508836892471866754.57.png?generation=1755935214151478&alt=media\")
Series 1.2.826.0.1.3680043.8.498.11575194956143871922194716810612477350, frame 8
\n(where is the aneurysm which should appear the 7 label?)
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F3537669%2F6c3e7fd4ae5ac268a83041b629b37f79%2F1.2.826.0.1.3680043.8.498.11575194956143871922194716810612477350.7.png?generation=1755935305224330&alt=media\")
Series 1.2.826.0.1.3680043.8.498.11575194956143871922194716810612477350, frame 7
\n(oh, here it is!)
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F3537669%2F1dd0b234719ec248bd34005645dc6395%2F1.2.826.0.1.3680043.8.498.11575194956143871922194716810612477350.6.png?generation=1755935343472672&alt=media\")
For the moment, I guess everybody should deduct 1 from the frame number provided until the train_localizer.csv file is fixed.
Hi @evancalabrese,
\nI found two issues relating to the update of the train_localizer.csv file, specifically with respect to the coordinates for the multi-frame MR series:
Series 1.2.826.0.1.3680043.8.498.10733938921373716882398209756836684843: both aneurysms have the same coordinates! One set must be right, the other set be wrong… (and we need the correct set for the latter)
It appears that the 'f' value has been established on a 1-to-n range, instead of a 0-to-n range, which is the Python standard. I'll provide two examples:
Series 1.2.826.0.1.3680043.8.498.10134365079002163886508836892471866754, frame 58
\n(aneurysm labelled 8)
\n
Series 1.2.826.0.1.3680043.8.498.10134365079002163886508836892471866754, frame 57
\n(the aneurysm is more visible here)
\n
Series 1.2.826.0.1.3680043.8.498.11575194956143871922194716810612477350, frame 8
\n(where is the aneurysm which should appear the 7 label?)
\n
Series 1.2.826.0.1.3680043.8.498.11575194956143871922194716810612477350, frame 7
\n(oh, here it is!)
\n
For the moment, I guess everybody should deduct 1 from the frame number provided until the train_localizer.csv file is fixed.
The DICOM standard is that frames start at 1, not zero. So in that case the frame number is correct right? I certainly see your point though. The pythonic way is to index frames starting from zero… Not sure how to best address this. Would welcome your suggestion.
", "rawMarkdown": "The DICOM standard is that frames start at 1, not zero. So in that case the frame number is correct right? I certainly see your point though. The pythonic way is to index frames starting from zero... Not sure how to best address this. Would welcome your suggestion.", "replies": [ { "id": 3274513, "postDate": "2025-08-24T23:32:46.890Z", "content": "I guess there are mainly two solutions: 1- amend the train_localizer.csv file so that 'f' is on a 0-to-n scale; 2- clearly communicate, both on the data page and in the next data update, that 'f' is on a 1-to-n scale. The latter would just require a trivial programmatical modification for the participants (and the obligation for them to read the instructions/details, which some don't always do).
Yes, good point. I will suggest to the rest of the team that we change the csv.
", "rawMarkdown": "Yes, good point. I will suggest to the rest of the team that we change the csv." } ] } ] } ], "comments": [ { "id": 3274508, "author_name": "Evan Calabrese", "author_url": "", "post_date": "2025-08-24T23:22:21.860000", "content": "The DICOM standard is that frames start at 1, not zero. So in that case the frame number is correct right? I certainly see your point though. The pythonic way is to index frames starting from zero… Not sure how to best address this. Would welcome your suggestion.
", "votes": 0, "replies": [ { "id": 3274513, "author_name": "Patrick Robitaille", "author_url": "", "post_date": "2025-08-24T23:32:46.890000", "content": "I guess there are mainly two solutions: 1- amend the train_localizer.csv file so that 'f' is on a 0-to-n scale; 2- clearly communicate, both on the data page and in the next data update, that 'f' is on a 1-to-n scale. The latter would just require a trivial programmatical modification for the participants (and the obligation for them to read the instructions/details, which some don't always do).
Yes, good point. I will suggest to the rest of the team that we change the csv.
", "votes": 0, "replies": [] } ] } ] } ], "raw_markdown_by_id": { "3273704": "Hi @evancalabrese,\n\nI found two issues relating to the update of the `train_localizer.csv` file, specifically with respect to the coordinates for the multi-frame MR series:\n\n1. Series 1.2.826.0.1.3680043.8.498.10733938921373716882398209756836684843: both aneurysms have the same coordinates! One set must be right, the other set be wrong... (and we need the correct set for the latter)\n\n2. It appears that the 'f' value has been established on a 1-to-n range, instead of a 0-to-n range, which is the Python standard. I'll provide two examples:\n\nSeries 1.2.826.0.1.3680043.8.498.10134365079002163886508836892471866754, frame 58\n(aneurysm labelled 8)\n\n\nSeries 1.2.826.0.1.3680043.8.498.10134365079002163886508836892471866754, frame 57\n(the aneurysm is more visible here)\n\n\nSeries 1.2.826.0.1.3680043.8.498.11575194956143871922194716810612477350, frame 8\n(where is the aneurysm which should appear the 7 label?)\n\n\nSeries 1.2.826.0.1.3680043.8.498.11575194956143871922194716810612477350, frame 7\n(oh, here it is!)\n\n\nFor the moment, I guess everybody should deduct 1 from the frame number provided until the `train_localizer.csv` file is fixed.", "3274508": "The DICOM standard is that frames start at 1, not zero. So in that case the frame number is correct right? I certainly see your point though. The pythonic way is to index frames starting from zero... Not sure how to best address this. Would welcome your suggestion." } }