Job Jar/Streamline library - Revision history

Nathan Malkin at 22:49, 17 May 2010

2010-05-17T22:49:25Z

← Older revision		Revision as of 22:49, 17 May 2010
Line 13:		Line 13:

	[[Jadrian]] has already written a lot of code to do this kind of thing, so it might make sense to talk to him and leverage his work in the process of creating this library. [[User:Cagatay Demiralp\|Cagatay]] also works with streamlines a lot and would probably have useful input.		[[Jadrian]] has already written a lot of code to do this kind of thing, so it might make sense to talk to him and leverage his work in the process of creating this library. [[User:Cagatay Demiralp\|Cagatay]] also works with streamlines a lot and would probably have useful input.



			== Implementation ==
			See ''$G/common/libcurvecollection'' for implementation

Jadrian Miles at 16:19, 8 February 2010

2010-02-08T16:19:35Z

← Older revision		Revision as of 16:19, 8 February 2010
Line 8:		Line 8:
	This job jar task is to create a C++ library to represent this sort of data in memory, provide a useful program interface for interacting with it (based on standard types such as STL containers and possible standard C arrays), and to read from and write to all of the four formats listed above (Tubegen, FSL, Camino, and DTK).		This job jar task is to create a C++ library to represent this sort of data in memory, provide a useful program interface for interacting with it (based on standard types such as STL containers and possible standard C arrays), and to read from and write to all of the four formats listed above (Tubegen, FSL, Camino, and DTK).

	The [[http://www.trackvis.org/docs/?subsect=fileformat DTK streamline format]] is excellently designed and would be a great starting point. It already fulfills most of the data representation requirements listed above (with the exception of per-segment scalars) but is based on a pretty gnarly C struct representation. Rewriting this in C++ and adding the appropriate I/O and interface functions would pretty much fulfill this job description.		The [http://www.trackvis.org/docs/?subsect=fileformat DTK streamline format] is excellently designed and would be a great starting point. It already fulfills most of the data representation requirements listed above (with the exception of per-segment scalars) but is based on a pretty gnarly C struct representation. Rewriting this in C++ and adding the appropriate I/O and interface functions would pretty much fulfill this job description.

	Matlab I/O code would also be very useful but is less essential.		Matlab I/O code would also be very useful but is less essential.

	[[Jadrian]] has already written a lot of code to do this kind of thing, so it might make sense to talk to him and leverage his work in the process of creating this library. [[User:Cagatay Demiralp\|Cagatay]] also works with streamlines a lot and would probably have useful input.		[[Jadrian]] has already written a lot of code to do this kind of thing, so it might make sense to talk to him and leverage his work in the process of creating this library. [[User:Cagatay Demiralp\|Cagatay]] also works with streamlines a lot and would probably have useful input.

Jadrian Miles at 21:00, 26 January 2010

2010-01-26T21:00:42Z

← Older revision		Revision as of 21:00, 26 January 2010
Line 13:		Line 13:

	[[Jadrian]] has already written a lot of code to do this kind of thing, so it might make sense to talk to him and leverage his work in the process of creating this library. [[User:Cagatay Demiralp\|Cagatay]] also works with streamlines a lot and would probably have useful input.		[[Jadrian]] has already written a lot of code to do this kind of thing, so it might make sense to talk to him and leverage his work in the process of creating this library. [[User:Cagatay Demiralp\|Cagatay]] also works with streamlines a lot and would probably have useful input.

	~~[[Category:Diffusion MRI]]~~

Jadrian Miles at 20:24, 26 January 2010

2010-01-26T20:24:04Z

← Older revision		Revision as of 20:24, 26 January 2010
Line 6:		Line 6:
	The data format should also include a description (say, a string) for each scalar value so that its interpretation is unambiguous.		The data format should also include a description (say, a string) for each scalar value so that its interpretation is unambiguous.

	~~Ideally, we want~~ to ~~be able~~ to ~~transparently read and write streamlines generated by each~~ of ~~the four programs listed above, as well as interact with the~~ data in memory ~~using~~ standard ~~interfaces (~~STL containers and ~~possibly~~ standard C arrays)~~. The [[http://www.trackvis.org/docs/?subsect=fileformat~~ DTK ~~streamline format]] is excellently designed and would be a great starting point~~.		This job jar task is to create a C++ library to represent this sort of data in memory, provide a useful program interface for interacting with it (based on standard types such as STL containers and possible standard C arrays), and to read from and write to all of the four formats listed above (Tubegen, FSL, Camino, and DTK).

	Matlab I/O code would also be very useful.		The [[http://www.trackvis.org/docs/?subsect=fileformat DTK streamline format]] is excellently designed and would be a great starting point. It already fulfills most of the data representation requirements listed above (with the exception of per-segment scalars) but is based on a pretty gnarly C struct representation. Rewriting this in C++ and adding the appropriate I/O and interface functions would pretty much fulfill this job description.

			Matlab I/O code would also be very useful but is less essential.

	[[Jadrian]] has already written a lot of code to do this kind of thing, so it might make sense to talk to him and leverage his work in the process of creating this library. [[User:Cagatay Demiralp\|Cagatay]] also works with streamlines a lot and would probably have useful input.		[[Jadrian]] has already written a lot of code to do this kind of thing, so it might make sense to talk to him and leverage his work in the process of creating this library. [[User:Cagatay Demiralp\|Cagatay]] also works with streamlines a lot and would probably have useful input.

	[[Category:Diffusion MRI]]		[[Category:Diffusion MRI]]

Jadrian Miles: New page: Tubegen represents streamlines/tubes in several different formats in memory and on disk, and this format is distinct from the representations used by well-established [[3rd Party Diffu...

2010-01-26T20:18:53Z

New page: Tubegen represents streamlines/tubes in several different formats in memory and on disk, and this format is distinct from the representations used by well-established [[3rd Party Diffu...

New page

[[Tubegen]] represents streamlines/tubes in several different formats in memory and on disk, and this format is distinct from the representations used by well-established [[3rd Party Diffusion MRI Software|third parties]], for example [http://www.fmrib.ox.ac.uk/fsl/ FSL], [http://www.cs.ucl.ac.uk/research/medic/camino/ Camino], and [http://www.trackvis.org/ DTK]. The core of any representation, though, is quite simple: a collection of streamlines, in which each streamline is just an ordered list of vertex points in 3-space. The tricky bit is that we want to be able to associate scalars with these datasets at many levels:
* the whole collection (for example, the average length of the streamlines)
* each individual streamline (ex: the length of the streamline)
* each segment of each streamline (ex: distance to the nearest segment; color values related to the orientation of the segment)
* each vertex point of each streamline (ex: the interpolated FA value at that point)
The data format should also include a description (say, a string) for each scalar value so that its interpretation is unambiguous.

Ideally, we want to be able to transparently read and write streamlines generated by each of the four programs listed above, as well as interact with the data in memory using standard interfaces (STL containers and possibly standard C arrays). The [[http://www.trackvis.org/docs/?subsect=fileformat DTK streamline format]] is excellently designed and would be a great starting point.

Matlab I/O code would also be very useful.

[[Jadrian]] has already written a lot of code to do this kind of thing, so it might make sense to talk to him and leverage his work in the process of creating this library. [[User:Cagatay Demiralp|Cagatay]] also works with streamlines a lot and would probably have useful input.

[[Category:Diffusion MRI]]