Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Invalid streamlines for software

オープン
  • 何か問題がありますか？
#7 コメント 7 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
python
領域
data

調査の方向性

まず、TRX 仕様および既存の scil_remove_invalid_streamlines.py の動作に照らして issue を確認します。空の streamline、単一点の streamline、重複する streamline、範囲外の streamline、無限座標を持つ streamline に対する合意済みのデフォルト処理を定義し、影響を受ける実装とテストを特定します。完了とは、スコープと期待される動作が文書化され、検証されていることを意味します。

索引モデルが issue の本文から書いたものです。

説明

This is outside of the scope of the specification, but it is related to what is written inside of the 'container'.

Even if it is true that someone could write what he/she wants in the file and get away with it for internal use, it could be nice to discuss what we DO NOT want to see when we share files.

  1. For example, at the SCIL (and to some extend in Dipy), streamlines with 0 points are problematic (I think it cannot be written or loaded by Nibabel. I believe no software should play with this idea. In the TRX that would be achieved by having two sequential identical offset values. This should absolutely be against the specification, offsets should have unique, always increasing values.

  2. At the SCIL, streamlines with 1 point are not considered streamlines. It can be written in TRK/TCK and is somewhat useful for some visualization (Workaround some tools to show only endpoints) and mostly debug. I think that for "normal" data generation of tractogram streamlines with only 1 point should be removed by default. Leaving a --debug_single_point is acceptable.

  3. Streamlines with 2 perfectly overlapping point, a step-size below 1x10^-6, are problematic for some software. Furthermore, since TRX supports float16 this would become perfect zero and that could be a problem. I think these should be removed by default. Leaving a --debug_overlap_point is acceptable.

  4. Finally, it would be nice that streamlines do not end up out of the volume used to generate them. That's true in RASMM as well as VOX. Why would a streamline be outside of the data? Of course, it can be written and even loaded in most software and be usable data. BUT it would be nice if we had an agreement not to write streamline like that in "normal" data generation of tractogram. Leaving a --debug_outside_bbox is acceptable.

Related to this issue, I saw more than once single point streamlines or entire streamlines at -INF or +INF, or streamlines having their last/first points at -INF or +INF, which was causing rendering issues with automatic camera position (MITK, TrackVis), etc. So removing them not only makes sense it could help a bit.

Internally we have a scil_remove_invalid_streamlines.py that removes any streamline of these 3 cases, so I am sure we can deal with this ourselves. But in an effort to bring more unity to the field and facilitate the exchange of data and limits corner case for everyone in every tools/library it would be nice that the default case is more stable.
This is similar to reserved keyword/tag for metadata and header, nothing is forcing anyone except the desire to make it easy to exchange data.

PS : I mentioned the TRX for 'fun fact', but this is actually relevant for any file format past, present or future.

主要言語
Python
スター
27
フォーク
20
平均マージ
2日 25分
マージ済み PR（30日）
1

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

tee-ar-ex/trx-python のほかの issue

tee-ar-ex/trx-python の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。