[ismrmrd] 11/281: Spell check on README
Ghislain Vaillant
ghisvail-guest at moszumanska.debian.org
Wed Jan 14 20:00:49 UTC 2015
This is an automated email from the git hooks/post-receive script.
ghisvail-guest pushed a commit to annotated tag ismrmrd0.5
in repository ismrmrd.
commit 6c86c88f015507d8426b83d17977871b46400ec5
Author: Michael S. Hansen <michael.hansen at nih.gov>
Date: Fri Aug 10 22:00:55 2012 -0400
Spell check on README
---
README.html | 24 ++++++++++++------------
doc/README.rst | 24 ++++++++++++------------
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/README.html b/README.html
index d35a3b8..01a602d 100644
--- a/README.html
+++ b/README.html
@@ -369,8 +369,8 @@ ul.auto-toc {
<h1>Overview</h1>
<p>The raw data format combines a mix of flexible data structures (XML header) and fixed structures (equivalent to C-structs). A raw data set consist of 2 sections:</p>
<ol class="arabic simple">
-<li>A flexible XML format document that can contain an arbitrary number of fields and accomodate everything from simple values (b-values, etc.) to entire vendor protocols, etc. This purpose of this XML document is to provide parameters that may be meaningful for some experiments but not for others. This XML format is defined by an XML Schema Definition file (ismrmrd.xsd).</li>
-<li>Raw data section. This section contains all the acquired data in the experiment. Each data item is preceeded by a C-struct with encoding numbers, etc. Following this data header is a channel header and data for each acquired channel. The raw data headers are defined in a C/C++ header file (ismrmrd.h)</li>
+<li>A flexible XML format document that can contain an arbitrary number of fields and accommodate everything from simple values (b-values, etc.) to entire vendor protocols, etc. This purpose of this XML document is to provide parameters that may be meaningful for some experiments but not for others. This XML format is defined by an XML Schema Definition file (ismrmrd.xsd).</li>
+<li>Raw data section. This section contains all the acquired data in the experiment. Each data item is preceded by a C-struct with encoding numbers, etc. Following this data header is a channel header and data for each acquired channel. The raw data headers are defined in a C/C++ header file (ismrmrd.h)</li>
</ol>
<div class="section" id="flexible-data-header">
<h2>Flexible Data Header</h2>
@@ -445,7 +445,7 @@ ul.auto-toc {
</pre>
-<p>The most critical elements for image reconstruction are contained in the <tt class="docutils literal"><encoding></tt> section of the document, which describes the encoded spaced and also the target reconstructed space. Along with the <tt class="docutils literal"><encodingLimits></tt> this section allows the reconstruction program to determine matrix sizes, oversampling factors, partial fourier, etc. In the example above, data is acquired with two-fold oversampling in the r [...]
+<p>The most critical elements for image reconstruction are contained in the <tt class="docutils literal"><encoding></tt> section of the document, which describes the encoded spaced and also the target reconstructed space. Along with the <tt class="docutils literal"><encodingLimits></tt> this section allows the reconstruction program to determine matrix sizes, oversampling factors, partial Fourier, etc. In the example above, data is acquired with two-fold oversampling in the r [...]
<pre class="literal-block">
0 70 139
|-------------------------------------|-------------------------------------------|
@@ -453,9 +453,9 @@ ul.auto-toc {
^ ^ ^
0 28 83
</pre>
-<p>After FFT, only the central 116 lines are kept, i.e. there is a reduced field of view in the phase encoding direction. Center and encoding limits for the readout dimension is not given in the XML header. This is to accomodate sequences where the center of the readout may change from readout to readout (alternating directions of readout). There is a field on the individual data headers (see below) to indicate the center of the readout.</p>
+<p>After FFT, only the central 116 lines are kept, i.e. there is a reduced field of view in the phase encoding direction. Center and encoding limits for the readout dimension is not given in the XML header. This is to accommodate sequences where the center of the readout may change from readout to readout (alternating directions of readout). There is a field on the individual data headers (see below) to indicate the center of the readout.</p>
<p>An experiment can have multiple encoding spaces and it is possible to indicate on each acquired data readout, which encoding space the data belongs to (see below).</p>
-<p>In addition to the defined field in the xml header, it is possible to add an arbitrary number of user defined parameters to accomodate special sequence parameters. Please consult the xml <a class="reference internal" href="#schema">schema</a> to see how user parameters are defined. Briefly, the XML header can have a section at the end which looks like:</p>
+<p>In addition to the defined field in the xml header, it is possible to add an arbitrary number of user defined parameters to accommodate special sequence parameters. Please consult the xml <a class="reference internal" href="#schema">schema</a> to see how user parameters are defined. Briefly, the XML header can have a section at the end which looks like:</p>
<pre class="literal-block">
<userParameters>
<userParameterLong>
@@ -472,7 +472,7 @@ ul.auto-toc {
</div>
<div class="section" id="fixed-data-structures">
<h2>Fixed Data structures</h2>
-<p>Each acquisition is preceeded by the following fixed layout structure:</p>
+<p>Each acquisition is preceded by the following fixed layout structure:</p>
<pre class="literal-block">
struct AcquisitionHeader
{
@@ -517,9 +517,9 @@ ul.auto-toc {
};
</pre>
-<p>The interpretation of some of these fields may vary from sequence to sequence, i.e. for a Cartesian sequence, <tt class="docutils literal">kspace_encode_step_1</tt> would be the phase encoding step, for a spiral sequence where phase encoding direction does not make sense, it would be the spiral interleave number. The <tt class="docutils literal">encoding_space_ref</tt> enables the user to tie an acquisition to a specific encoding space (see above) in case there are multiple, e.g. in s [...]
-<p>The flags field is a bitmask, which in principle can be used freely by the user, but suggested flag values are given in <tt class="docutils literal">ismrmrd.h</tt>, it is recommended not to use already designated flag bits for custom purposes. Ther are a set of bits reserved for prototyping (bits 57-64), please see <tt class="docutils literal">ismrmrd.h</tt> for details.</p>
-<p>The header contains a <tt class="docutils literal">trajectory_dimensions</tt> field. If the value of this field is larger than 0, it means that trajectories are stored with each invidual acquisition. For a 2D acquisition, the <tt class="docutils literal">trajectory_dimensions</tt> would typically be 2 and the convention (for memory layout) is that the header is followed immediately by the trajectory before the complex data. There is an example of how this memory layout could be implem [...]
+<p>The interpretation of some of these fields may vary from sequence to sequence, i.e. for a Cartesian sequence, <tt class="docutils literal">kspace_encode_step_1</tt> would be the phase encoding step, for a spiral sequence where phase encoding direction does not make sense, it would be the spiral interleave number. The <tt class="docutils literal">encoding_space_ref</tt> enables the user to tie an acquisition to a specific encoding space (see above) in case there are multiple, e.g. in s [...]
+<p>The flags field is a bit mask, which in principle can be used freely by the user, but suggested flag values are given in <tt class="docutils literal">ismrmrd.h</tt>, it is recommended not to use already designated flag bits for custom purposes. There are a set of bits reserved for prototyping (bits 57-64), please see <tt class="docutils literal">ismrmrd.h</tt> for details.</p>
+<p>The header contains a <tt class="docutils literal">trajectory_dimensions</tt> field. If the value of this field is larger than 0, it means that trajectories are stored with each individual acquisition. For a 2D acquisition, the <tt class="docutils literal">trajectory_dimensions</tt> would typically be 2 and the convention (for memory layout) is that the header is followed immediately by the trajectory before the complex data. There is an example of how this memory layout could be impl [...]
<pre class="literal-block">
class Acquisition
{
@@ -538,12 +538,12 @@ float* data_; //Actual data, elements = head_.number_of_samples*head_
};
</pre>
-<p>This suggested memory layout is only a suggestion. The HDF5 interface (see below) can be used to read the data into many different datastructures. In fact, the user can choose to read only part of the header or not read the data, etc.</p>
+<p>This suggested memory layout is only a suggestion. The HDF5 interface (see below) can be used to read the data into many different data structures. In fact, the user can choose to read only part of the header or not read the data, etc.</p>
</div>
</div>
<div class="section" id="file-storage">
<h1>File Storage</h1>
-<p>The ISMRM Raw Data format is stored in HDF5 format. Details on this format can be found at the <a class="reference external" href="http://www.hdfgroup.org/HDF5/">HDF5</a> website. Briefly it is a hierarchical dataformat (much like a file system), which can contain multiple variable organized in groups (like folders in a file system). The variables can contain arrays of data values, custom defined structs, or simple text fields. It is the convention (but not a requirement) that the ISM [...]
+<p>The ISMRM Raw Data format is stored in HDF5 format. Details on this format can be found at the <a class="reference external" href="http://www.hdfgroup.org/HDF5/">HDF5</a> website. Briefly it is a hierarchical data format (much like a file system), which can contain multiple variable organized in groups (like folders in a file system). The variables can contain arrays of data values, custom defined structs, or simple text fields. It is the convention (but not a requirement) that the IS [...]
<pre class="literal-block">
>> data = h5read('simple_gre.h5', '/dataset/data');
>> data
@@ -631,7 +631,7 @@ try {
//Use the configuration, e.g.:
std::cout << "Number of encoding spaces: " << cfg->encoding().size() << std::endl;
</pre>
-<p>Again, this is not a requirement for using the ISMRMRD format, the XML can be parsed with numerous other xml parsing libraries. The schema file <tt class="docutils literal">schema/ismrmrd.xsd</tt> gives the user the option of validating the XML header before parsing, which is recommeded to reduce the chance of hard to detect errors in your code due to missing or malformed parameters.</p>
+<p>Again, this is not a requirement for using the ISMRMRD format, the XML can be parsed with numerous other xml parsing libraries. The schema file <tt class="docutils literal">schema/ismrmrd.xsd</tt> gives the user the option of validating the XML header before parsing, which is recommended to reduce the chance of hard to detect errors in your code due to missing or malformed parameters.</p>
</div>
<div class="section" id="matlab-example-code-and-datasets">
<h1>Matlab Example Code and Datasets</h1>
diff --git a/doc/README.rst b/doc/README.rst
index 628ac1a..d80eca8 100644
--- a/doc/README.rst
+++ b/doc/README.rst
@@ -47,8 +47,8 @@ Overview
The raw data format combines a mix of flexible data structures (XML header) and fixed structures (equivalent to C-structs). A raw data set consist of 2 sections:
-1. A flexible XML format document that can contain an arbitrary number of fields and accomodate everything from simple values (b-values, etc.) to entire vendor protocols, etc. This purpose of this XML document is to provide parameters that may be meaningful for some experiments but not for others. This XML format is defined by an XML Schema Definition file (ismrmrd.xsd).
-2. Raw data section. This section contains all the acquired data in the experiment. Each data item is preceeded by a C-struct with encoding numbers, etc. Following this data header is a channel header and data for each acquired channel. The raw data headers are defined in a C/C++ header file (ismrmrd.h)
+1. A flexible XML format document that can contain an arbitrary number of fields and accommodate everything from simple values (b-values, etc.) to entire vendor protocols, etc. This purpose of this XML document is to provide parameters that may be meaningful for some experiments but not for others. This XML format is defined by an XML Schema Definition file (ismrmrd.xsd).
+2. Raw data section. This section contains all the acquired data in the experiment. Each data item is preceded by a C-struct with encoding numbers, etc. Following this data header is a channel header and data for each acquired channel. The raw data headers are defined in a C/C++ header file (ismrmrd.h)
Flexible Data Header
.....................
@@ -60,7 +60,7 @@ An example of an XML file for a Cartesian 3D acquisition could look like:
.. include:: ../schema/ismrmrd_example.xml
:literal:
-The most critical elements for image reconstruction are contained in the ``<encoding>`` section of the document, which describes the encoded spaced and also the target reconstructed space. Along with the ``<encodingLimits>`` this section allows the reconstruction program to determine matrix sizes, oversampling factors, partial fourier, etc. In the example above, data is acquired with two-fold oversampling in the read-out (``x``) direction, which is reflected in the larger matrix size in [...]
+The most critical elements for image reconstruction are contained in the ``<encoding>`` section of the document, which describes the encoded spaced and also the target reconstructed space. Along with the ``<encodingLimits>`` this section allows the reconstruction program to determine matrix sizes, oversampling factors, partial Fourier, etc. In the example above, data is acquired with two-fold oversampling in the read-out (``x``) direction, which is reflected in the larger matrix size in [...]
::
@@ -70,11 +70,11 @@ The most critical elements for image reconstruction are contained in the ``<enco
^ ^ ^
0 28 83
-After FFT, only the central 116 lines are kept, i.e. there is a reduced field of view in the phase encoding direction. Center and encoding limits for the readout dimension is not given in the XML header. This is to accomodate sequences where the center of the readout may change from readout to readout (alternating directions of readout). There is a field on the individual data headers (see below) to indicate the center of the readout.
+After FFT, only the central 116 lines are kept, i.e. there is a reduced field of view in the phase encoding direction. Center and encoding limits for the readout dimension is not given in the XML header. This is to accommodate sequences where the center of the readout may change from readout to readout (alternating directions of readout). There is a field on the individual data headers (see below) to indicate the center of the readout.
An experiment can have multiple encoding spaces and it is possible to indicate on each acquired data readout, which encoding space the data belongs to (see below).
-In addition to the defined field in the xml header, it is possible to add an arbitrary number of user defined parameters to accomodate special sequence parameters. Please consult the xml schema_ to see how user parameters are defined. Briefly, the XML header can have a section at the end which looks like:
+In addition to the defined field in the xml header, it is possible to add an arbitrary number of user defined parameters to accommodate special sequence parameters. Please consult the xml schema_ to see how user parameters are defined. Briefly, the XML header can have a section at the end which looks like:
::
@@ -94,7 +94,7 @@ In addition to the defined field in the xml header, it is possible to add an arb
Fixed Data structures
......................
-Each acquisition is preceeded by the following fixed layout structure:
+Each acquisition is preceded by the following fixed layout structure:
.. include:: ../ismrmrd.h
:literal:
@@ -108,11 +108,11 @@ Where EncodingCounters are defined as:
:start-line: 100
:end-line: 112
-The interpretation of some of these fields may vary from sequence to sequence, i.e. for a Cartesian sequence, ``kspace_encode_step_1`` would be the phase encoding step, for a spiral sequence where phase encoding direction does not make sense, it would be the spiral interleave number. The ``encoding_space_ref`` enables the user to tie an acquisition to a specific encoding space (see above) in case there are multiple, e.g. in situations where a calibration scan may be integrated in the acq [...]
+The interpretation of some of these fields may vary from sequence to sequence, i.e. for a Cartesian sequence, ``kspace_encode_step_1`` would be the phase encoding step, for a spiral sequence where phase encoding direction does not make sense, it would be the spiral interleave number. The ``encoding_space_ref`` enables the user to tie an acquisition to a specific encoding space (see above) in case there are multiple, e.g. in situations where a calibration scan may be integrated in the acq [...]
-The flags field is a bitmask, which in principle can be used freely by the user, but suggested flag values are given in ``ismrmrd.h``, it is recommended not to use already designated flag bits for custom purposes. Ther are a set of bits reserved for prototyping (bits 57-64), please see ``ismrmrd.h`` for details.
+The flags field is a bit mask, which in principle can be used freely by the user, but suggested flag values are given in ``ismrmrd.h``, it is recommended not to use already designated flag bits for custom purposes. There are a set of bits reserved for prototyping (bits 57-64), please see ``ismrmrd.h`` for details.
-The header contains a ``trajectory_dimensions`` field. If the value of this field is larger than 0, it means that trajectories are stored with each invidual acquisition. For a 2D acquisition, the ``trajectory_dimensions`` would typically be 2 and the convention (for memory layout) is that the header is followed immediately by the trajectory before the complex data. There is an example of how this memory layout could be implemented with a C++ class in the ``ismrmrd.h`` file:
+The header contains a ``trajectory_dimensions`` field. If the value of this field is larger than 0, it means that trajectories are stored with each individual acquisition. For a 2D acquisition, the ``trajectory_dimensions`` would typically be 2 and the convention (for memory layout) is that the header is followed immediately by the trajectory before the complex data. There is an example of how this memory layout could be implemented with a C++ class in the ``ismrmrd.h`` file:
::
@@ -133,12 +133,12 @@ The header contains a ``trajectory_dimensions`` field. If the value of this fiel
};
-This suggested memory layout is only a suggestion. The HDF5 interface (see below) can be used to read the data into many different datastructures. In fact, the user can choose to read only part of the header or not read the data, etc.
+This suggested memory layout is only a suggestion. The HDF5 interface (see below) can be used to read the data into many different data structures. In fact, the user can choose to read only part of the header or not read the data, etc.
File Storage
-------------
-The ISMRM Raw Data format is stored in HDF5 format. Details on this format can be found at the HDF5_ website. Briefly it is a hierarchical dataformat (much like a file system), which can contain multiple variable organized in groups (like folders in a file system). The variables can contain arrays of data values, custom defined structs, or simple text fields. It is the convention (but not a requirement) that the ISMRMRD datasets are stored in a group called ``/dataset``. The XML configur [...]
+The ISMRM Raw Data format is stored in HDF5 format. Details on this format can be found at the HDF5_ website. Briefly it is a hierarchical data format (much like a file system), which can contain multiple variable organized in groups (like folders in a file system). The variables can contain arrays of data values, custom defined structs, or simple text fields. It is the convention (but not a requirement) that the ISMRMRD datasets are stored in a group called ``/dataset``. The XML configu [...]
::
@@ -238,7 +238,7 @@ Since the XML part of the header is defined in the ``schema/ismrmrd.xsd`` file,
//Use the configuration, e.g.:
std::cout << "Number of encoding spaces: " << cfg->encoding().size() << std::endl;
-Again, this is not a requirement for using the ISMRMRD format, the XML can be parsed with numerous other xml parsing libraries. The schema file ``schema/ismrmrd.xsd`` gives the user the option of validating the XML header before parsing, which is recommeded to reduce the chance of hard to detect errors in your code due to missing or malformed parameters.
+Again, this is not a requirement for using the ISMRMRD format, the XML can be parsed with numerous other xml parsing libraries. The schema file ``schema/ismrmrd.xsd`` gives the user the option of validating the XML header before parsing, which is recommended to reduce the chance of hard to detect errors in your code due to missing or malformed parameters.
Matlab Example Code and Datasets
--------------------------------
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/debian-science/packages/ismrmrd.git
More information about the debian-science-commits
mailing list