StandardsInterfaces - Revision history

Megason at 15:59, 24 June 2010

2010-06-24T15:59:59Z

Megason: /* Greatest Common Denominator */

2010-06-24T15:58:08Z

Greatest Common Denominator

Megason: /* Microscopy Filter IO Types */

2010-06-24T15:47:43Z

Microscopy Filter IO Types

Megason: /* Progress */

2010-06-24T15:45:32Z

Progress

Megason: /* Progress */

2010-06-24T15:37:28Z

Progress

Megason: /* Progress */

2010-06-24T15:36:48Z

Progress

Megason: /* Progress */

2010-06-24T15:35:11Z

Progress

Megason: /* Progress */

2010-06-24T15:34:43Z

Progress

Megason: /* Progress */

2010-06-24T15:33:50Z

Progress

Megason: /* Progress */

2010-06-24T15:16:19Z

Progress

← Older revision		Revision as of 15:59, 24 June 2010
Line 1:		Line 1:
−	~~__NOTOC__~~
−
	We are intreated in getting feedback on creating standards and interfaces for microscopy image analysis in ITK		We are intreated in getting feedback on creating standards and interfaces for microscopy image analysis in ITK

@@ Line 39: / Line 39: @@
 ===Greatest Common Denominator===
 We also discussed what the "greatest common denominator" of interchange between microscopy image analysis groups is.
-* '''ITK filters''': A preferred method for sharing microscopy processing filters is by submitting a paper to the Insight Journal and a class or classes to ITK
+* '''ITK filters''': A preferred method for sharing microscopy processing filters is by submitting a paper to the Insight Journal and a class or classes to ITK. This mechanism provides for peer reviewed publication, automatic testing, and easy access to the code.

@@ Line 35: / Line 35: @@
 ===Microscopy Filter IO Types===
-I met with Luis Ibanez and Jim Miller to discuss how related issues have been handled in ITK previously. They suggested itk::SpatialObject and itk::LabelObject. LabelObject seems like a good intermediate between an image based representation and an object(cell) based representation, and allows for either perspective depending on which is more convenient. LabelObject uses run-length enconding of objects in an image which results in a lot of compression. LabelObject also allows for objects to be attributed with values (e.g. cell size, intensity, velocity). One downside is that there are not currently many filters in ITK that use LabelObjects. In our research, we (Kishore) have already been working with LabelObjects as the output to segmentation filters. This seems like a promising approach. We need to standardize the representation of cells in xy, xyt, xyz, xyzt, xyzt+division using LabelObjects and the associated cellular attributes. We are also working on a filter for converting LabelObjects into a GoFigure IO file format.
+I met with Luis Ibanez and Jim Miller to discuss how the best representation for filter I/O issues have been handled in ITK previously. They suggested itk::SpatialObject and itk::LabelObject. LabelObject seems like a good intermediate between an image based representation and an object(cell) based representation, and allows for either perspective depending on which is more convenient. LabelObject uses run-length enconding of objects in an image which results in a lot of compression. LabelObject also allows for objects to be attributed with values (e.g. cell size, intensity, velocity). One downside is that there are not currently many filters in ITK that use LabelObjects. In our research, we (Kishore) have already been working with LabelObjects as the output to segmentation filters. This seems like a promising approach. We need to standardize the representation of cells in xy, xyt, xyz, xyzt, xyzt+division using LabelObjects and the associated cellular attributes. We are also working on a filter for converting LabelObjects into a GoFigure IO file format.
 ===Greatest Common Denominator===
 We also discussed what the "greatest common denominator" of interchange between microscopy image analysis groups is.
 * '''ITK filters''': A preferred method for sharing microscopy processing filters is by submitting a paper to the Insight Journal and a class or classes to ITK

@@ Line 27: / Line 27: @@
 ==Progress==
-We also discussed standards for '''image formats''' at the Microscopy Breakout session. We broke this issue down into 3 components:
+===Image Formats===
 * '''File Types''': e.g. jpg, png, tif, lsm. The problem of needing to read a bunch of different file types has been around a long time. This problem is still not ideally solved (there is no BSD licensed library that will read all microscopy formats), but there are enough workarounds that this issue is now more of an inconvenience than a road block. In practice most groups only use 1 maybe 2 types of microscopes and have solved their problem locally. A global solution would make it easier for groups to work together and would thus be preferable. However, current file types do not meet the needs of advanced imaging applications anyway (see "meta" file types below) so efforts should be aimed at both creating BSD readers for existing file types as well as meta file types.
 * '''Metadata''': metadata refers to all the nonimage data that is part of an imaging experiment. Metadata include image acquisition parameters (objective, laser power, PMT gain, filters, pixel dwell time) much of which is microscope specific. It can also include information about how the specimen was labeled and and its stage and orientation for imaging. It can even include a full description of the experiment (genotype, drugs...). Current solutions are to store the data in XML files, databases, and image headers. Metadata is very heterogeneous and user-specific and thus needs a flexible format.
 * '''Meta image formats''': For advanced microscopy applications, an experimental unit almost never corresponds to a single image file. Many microscopy file formats (e.g. Zeiss LSM) are designed for the one experiment one file paradigm with encapsulated metadata, but these scale very poorly. For advanced microscopy applications, it is more common to use a "meta" format consisting of many image files of some standard file type along with an XML or database schema that organizes the data across experimental dimensions and stores experimental metadata. This meta format approach has been widely and independently adopted because of its flexibility and scalability. In our own work we use something called the MegaCapture format which consists of an XML file for metadata along with a set of image files. These image files are stored as 2d, single channel images in any common format (TIF, JPG, PNG), and their file names reflect their coordinates in the dimensions of z, time, x-tile, y-tile, row, column, and plate. This schema is reflected in the database used by GoFigure. Several other groups have developed similar meta approaches. To the extent possible it would be nice for these formats to be compatible to allow for interchange between groups and perhaps more importantly to allow for the creation of ITK filters where the input is a meta image rather than a single image. ITK filters with meta image input are important for streamlined, HPC based processing for advanced microscopy applications.

@@ Line 29: / Line 29: @@
 I met with Luis Ibanez and Jim Miller to discuss how related issues have been handled in ITK previously. They suggested itk::SpatialObject and itk::LabelObject. LabelObject seems like a good intermediate between an image based representation and an object(cell) based representation, and allows for either perspective depending on which is more convenient. LabelObject uses run-length enconding of objects in an image which results in a lot of compression. LabelObject also allows for objects to be attributed with values (e.g. cell size, intensity, velocity). One downside is that there are not currently many filters in ITK that use LabelObjects. In our research, we (Kishore) have already been working with LabelObjects as the output to segmentation filters. This seems like a promising approach. We need to standardize the representation of cells in xy, xyt, xyz, xyzt, xyzt+division using LabelObjects and the associated cellular attributes. We are also working on a filter for converting LabelObjects into a GoFigure IO file format.
-We also discussed standards for ''image formats'' at the Microscopy Breakout session. We broke this issue down into 3 components:
+We also discussed standards for '''image formats''' at the Microscopy Breakout session. We broke this issue down into 3 components:
-* ''File Types'': e.g. jpg, png, tif, lsm. The problem of needing to read a bunch of different file types has been around a long time. This problem is still not ideally solved (there is no BSD licensed library that will read all microscopy formats), but there are enough workarounds that this issue is now more of an inconvenience than a road block. In practice most groups only use 1 maybe 2 types of microscopes and have solved their problem locally. A global solution would make it easier for groups to work together and would thus be preferable. However, current file types do not meet the needs of advanced imaging applications anyway (see "meta" file types below) so efforts should be aimed at both creating BSD readers for existing file types as well as meta file types.
+* '''File Types''': e.g. jpg, png, tif, lsm. The problem of needing to read a bunch of different file types has been around a long time. This problem is still not ideally solved (there is no BSD licensed library that will read all microscopy formats), but there are enough workarounds that this issue is now more of an inconvenience than a road block. In practice most groups only use 1 maybe 2 types of microscopes and have solved their problem locally. A global solution would make it easier for groups to work together and would thus be preferable. However, current file types do not meet the needs of advanced imaging applications anyway (see "meta" file types below) so efforts should be aimed at both creating BSD readers for existing file types as well as meta file types.
-* ''Metadata'': metadata refers to all the nonimage data that is part of an imaging experiment. Metadata include image acquisition parameters (objective, laser power, PMT gain, filters, pixel dwell time) much of which is microscope specific. It can also include information about how the specimen was labeled and and its stage and orientation for imaging. It can even include a full description of the experiment (genotype, drugs...). Current solutions are to store the data in XML files, databases, and image headers. Metadata is very heterogeneous and user-specific and thus needs a flexible format.
+* '''Metadata''': metadata refers to all the nonimage data that is part of an imaging experiment. Metadata include image acquisition parameters (objective, laser power, PMT gain, filters, pixel dwell time) much of which is microscope specific. It can also include information about how the specimen was labeled and and its stage and orientation for imaging. It can even include a full description of the experiment (genotype, drugs...). Current solutions are to store the data in XML files, databases, and image headers. Metadata is very heterogeneous and user-specific and thus needs a flexible format.
-* ''Meta image formats'': For advanced microscopy applications, an experimental unit almost never corresponds to a single image file. Many microscopy file formats (e.g. Zeiss LSM) are designed for the one experiment one file paradigm with encapsulated metadata, but these scale very poorly. For advanced microscopy applications, it is more common to use a "meta" format consisting of many image files of some standard file type along with an XML or database schema that organizes the data across experimental dimensions and stores experimental metadata. This meta format approach has been widely and independently adopted because of its flexibility and scalability. In our own work we use something called the MegaCapture format which consists of an XML file for metadata along with a set of image files. These image files are stored as 2d, single channel images in any common format (TIF, JPG, PNG), and their file names reflect their coordinates in the dimensions of z, time, x-tile, y-tile, row, column, and plate. This schema is reflected in the database used by GoFigure. Several other groups have developed similar meta approaches. To the extent possible it would be nice for these formats to be compatible to allow for interchange between groups and perhaps more importantly to allow for the creation of ITK filters where the input is a meta image rather than a single image. ITK filters with meta image input are important for streamlined, HPC based processing for advanced microscopy applications.
+* '''Meta image formats''': For advanced microscopy applications, an experimental unit almost never corresponds to a single image file. Many microscopy file formats (e.g. Zeiss LSM) are designed for the one experiment one file paradigm with encapsulated metadata, but these scale very poorly. For advanced microscopy applications, it is more common to use a "meta" format consisting of many image files of some standard file type along with an XML or database schema that organizes the data across experimental dimensions and stores experimental metadata. This meta format approach has been widely and independently adopted because of its flexibility and scalability. In our own work we use something called the MegaCapture format which consists of an XML file for metadata along with a set of image files. These image files are stored as 2d, single channel images in any common format (TIF, JPG, PNG), and their file names reflect their coordinates in the dimensions of z, time, x-tile, y-tile, row, column, and plate. This schema is reflected in the database used by GoFigure. Several other groups have developed similar meta approaches. To the extent possible it would be nice for these formats to be compatible to allow for interchange between groups and perhaps more importantly to allow for the creation of ITK filters where the input is a meta image rather than a single image. ITK filters with meta image input are important for streamlined, HPC based processing for advanced microscopy applications.

@@ Line 29: / Line 29: @@
 I met with Luis Ibanez and Jim Miller to discuss how related issues have been handled in ITK previously. They suggested itk::SpatialObject and itk::LabelObject. LabelObject seems like a good intermediate between an image based representation and an object(cell) based representation, and allows for either perspective depending on which is more convenient. LabelObject uses run-length enconding of objects in an image which results in a lot of compression. LabelObject also allows for objects to be attributed with values (e.g. cell size, intensity, velocity). One downside is that there are not currently many filters in ITK that use LabelObjects. In our research, we (Kishore) have already been working with LabelObjects as the output to segmentation filters. This seems like a promising approach. We need to standardize the representation of cells in xy, xyt, xyz, xyzt, xyzt+division using LabelObjects and the associated cellular attributes. We are also working on a filter for converting LabelObjects into a GoFigure IO file format.
-We also discussed standards for *image formats* at the Microscopy Breakout session. We broke this issue down into 3 components:
+We also discussed standards for **image formats** at the Microscopy Breakout session. We broke this issue down into 3 components:
 * *File Types*: e.g. jpg, png, tif, lsm. The problem of needing to read a bunch of different file types has been around a long time. This problem is still not ideally solved (there is no BSD licensed library that will read all microscopy formats), but there are enough workarounds that this issue is now more of an inconvenience than a road block. In practice most groups only use 1 maybe 2 types of microscopes and have solved their problem locally. A global solution would make it easier for groups to work together and would thus be preferable. However, current file types do not meet the needs of advanced imaging applications anyway (see "meta" file types below) so efforts should be aimed at both creating BSD readers for existing file types as well as meta file types.
 * *Metadata*: metadata refers to all the nonimage data that is part of an imaging experiment. Metadata include image acquisition parameters (objective, laser power, PMT gain, filters, pixel dwell time) much of which is microscope specific. It can also include information about how the specimen was labeled and and its stage and orientation for imaging. It can even include a full description of the experiment (genotype, drugs...). Current solutions are to store the data in XML files, databases, and image headers. Metadata is very heterogeneous and user-specific and thus needs a flexible format.
 * *Meta image formats*: For advanced microscopy applications, an experimental unit almost never corresponds to a single image file. Many microscopy file formats (e.g. Zeiss LSM) are designed for the one experiment one file paradigm with encapsulated metadata, but these scale very poorly. For advanced microscopy applications, it is more common to use a "meta" format consisting of many image files of some standard file type along with an XML or database schema that organizes the data across experimental dimensions and stores experimental metadata. This meta format approach has been widely and independently adopted because of its flexibility and scalability. In our own work we use something called the MegaCapture format which consists of an XML file for metadata along with a set of image files. These image files are stored as 2d, single channel images in any common format (TIF, JPG, PNG), and their file names reflect their coordinates in the dimensions of z, time, x-tile, y-tile, row, column, and plate. This schema is reflected in the database used by GoFigure. Several other groups have developed similar meta approaches. To the extent possible it would be nice for these formats to be compatible to allow for interchange between groups and perhaps more importantly to allow for the creation of ITK filters where the input is a meta image rather than a single image. ITK filters with meta image input are important for streamlined, HPC based processing for advanced microscopy applications.

@@ Line 27: / Line 27: @@
 ==Progress==
-I met with Luis Ibanez and Jim Miller to discuss how related issues have been handled in ITK previously. They suggested itk::SpatialObject and itk::LabelObject. LabelObject seems like a good intermediate between an image based representation and an object(cell) based representation, and allows for either perspective depending on which is more convenient. LabelObject uses run-length enconding of objects in an image which results in a lot of compression. LabelObject also allows for objects to be attributed with values (e.g. cell size, intensity, velocity). One downside is that there are not currently many filters in ITK that use LabelObjects. In our research, we (Kishore) have already been working with LabelObjects as the output to segmentation filters. This seems like a promising approach. We need to standardize the representation of cells in xy, xyt, xyz, xyzt, xyzt+division using LabelObjects and the associated cellular attributes, and complete a LabelObjectToGoFigure filter.
+I met with Luis Ibanez and Jim Miller to discuss how related issues have been handled in ITK previously. They suggested itk::SpatialObject and itk::LabelObject. LabelObject seems like a good intermediate between an image based representation and an object(cell) based representation, and allows for either perspective depending on which is more convenient. LabelObject uses run-length enconding of objects in an image which results in a lot of compression. LabelObject also allows for objects to be attributed with values (e.g. cell size, intensity, velocity). One downside is that there are not currently many filters in ITK that use LabelObjects. In our research, we (Kishore) have already been working with LabelObjects as the output to segmentation filters. This seems like a promising approach. We need to standardize the representation of cells in xy, xyt, xyz, xyzt, xyzt+division using LabelObjects and the associated cellular attributes. We are also working on a filter for converting LabelObjects into a GoFigure IO file format.
 We also discussed standards for image formats at the Microscopy Breakout session. We broke this issue down into 3 components:
 * File Types: e.g. jpg, png, tif, lsm. The problem of needing to read a bunch of different file types has been around a long time. This problem is still not ideally solved (there is no BSD licensed library that will read all microscopy formats), but there are enough workarounds that this issue is now more of an inconvenience than a road block. In practice most groups only use 1 maybe 2 types of microscopes and have solved their problem locally. A global solution would make it easier for groups to work together and would thus be preferable. However, current file types do not meet the needs of advanced imaging applications anyway (see "meta" file types below) so efforts should be aimed at both creating BSD readers for existing file types as well as meta file types.
 * Metadata: metadata refers to all the nonimage data that is part of an imaging experiment. Metadata include image acquisition parameters (objective, laser power, PMT gain, filters, pixel dwell time) much of which is microscope specific. It can also include information about how the specimen was labeled and and its stage and orientation for imaging. It can even include a full description of the experiment (genotype, drugs...). Current solutions are to store the data in XML files, databases, and image headers. Metadata is very heterogeneous and user-specific and thus needs a flexible format.
-* Meta image formats: For
+* Meta image formats: For advanced microscopy applications, an experimental unit almost never corresponds to a single image file. Many microscopy file formats (e.g. Zeiss LSM) are designed for the one experiment one file paradigm with encapsulated metadata, but these scale very poorly. For advanced microscopy applications, it is more common to use a "meta" format consisting of many image files of some standard file type along with an XML or database schema that organizes the data across experimental dimensions and stores experimental metadata. This meta format approach has been widely and independently adopted because of its flexibility and scalability. In our own work we use something called the MegaCapture format which consists of an XML file for metadata along with a set of image files. These image files are stored as 2d, single channel images in any common format (TIF, JPG, PNG), and their file names reflect their coordinates in the dimensions of z, time, x-tile, y-tile, row, column, and plate. This schema is reflected in the database used by GoFigure. Several other groups have developed similar meta approaches. To the extent possible it would be nice for these formats to be compatible to allow for interchange between groups and perhaps more importantly to allow for the creation of ITK filters where the input is a meta image rather than a single image. ITK filters with meta image input are important for streamlined, HPC based processing for advanced microscopy applications.