Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Invalid streamlines for software

Abierto
  • ¿Algo no está bien?
#7 7 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
python
Área
data

Línea de trabajo

Comienza revisando el issue según la especificación TRX y el comportamiento existente de scil_remove_invalid_streamlines.py. Define el manejo predeterminado acordado para streamlines vacíos, de un solo punto, superpuestos, fuera de los límites y con coordenadas infinitas, y luego identifica la implementación y las pruebas afectadas; se considera terminado cuando el alcance y el comportamiento esperado están documentados y verificados.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
27
Forks
20
Merge medio
2 d 25 min
PR fusionados (30 d)
1

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de tee-ar-ex/trx-python

Todos los issues de tee-ar-ex/trx-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.