nifti2_data_format
nifti2_data_format > RE: NIFTI-2 proposal
Mar 1, 2011 12:03 PM | Mark Horsfield - Xinapse Systems Ltd
RE: NIFTI-2 proposal
Hi Mark,
I don't see a problem with the 64-bit update, but this modifcation makes a problem I have with the current NIFTI-1 format even more acute.
The current problem I have (I don't know if anyone else does) is the location of the Extensions, just after the header, and before the image data. This means that when an image is created and the image data has been written to disk, it is not possible to add anything to the extensions. The image data is in a fixed location on disk, and the space between the header and the image data is set by the number of bytes in the extension at the time the image data is first written. I believe the current way to add information to the Extensions is to read the whole of the image data from disk (into memory), add to the extensions, and then write the image data back to disk at a new location.
For large datasets (which the modifcation is intended to support) it will not be possible to hold the whole of the image data in memory. The only other way then is to write some clever software to read the image data in chunks, starting at the end of the image data, and shuffling it about on the disk to accommodate the Extension data which has changed size. This isn't very practical if you just want to add a few bytes of Extension data.
This would be solved by moving the Extensions to the end of the image data.
Regards
Mark
I don't see a problem with the 64-bit update, but this modifcation makes a problem I have with the current NIFTI-1 format even more acute.
The current problem I have (I don't know if anyone else does) is the location of the Extensions, just after the header, and before the image data. This means that when an image is created and the image data has been written to disk, it is not possible to add anything to the extensions. The image data is in a fixed location on disk, and the space between the header and the image data is set by the number of bytes in the extension at the time the image data is first written. I believe the current way to add information to the Extensions is to read the whole of the image data from disk (into memory), add to the extensions, and then write the image data back to disk at a new location.
For large datasets (which the modifcation is intended to support) it will not be possible to hold the whole of the image data in memory. The only other way then is to write some clever software to read the image data in chunks, starting at the end of the image data, and shuffling it about on the disk to accommodate the Extension data which has changed size. This isn't very practical if you just want to add a few bytes of Extension data.
This would be solved by moving the Extensions to the end of the image data.
Regards
Mark
Threaded View
| Title | Author | Date |
|---|---|---|
| Mark Jenkinson | Feb 28, 2011 | |
| Mark Jenkinson | Mar 15, 2011 | |
| Cinly Ooi | Mar 15, 2011 | |
| Cinly Ooi | Mar 2, 2011 | |
| Ged Ridgway | Mar 7, 2011 | |
| Jon Clayden | Mar 5, 2011 | |
| Cinly Ooi | Mar 1, 2011 | |
| Andrew Janke | Mar 1, 2011 | |
| Cinly Ooi | Mar 2, 2011 | |
| Satrajit Ghosh | Mar 5, 2011 | |
| Cinly Ooi | Mar 1, 2011 | |
| Cinly Ooi | Mar 1, 2011 | |
| Cinly Ooi | Mar 1, 2011 | |
| Cinly Ooi | Mar 1, 2011 | |
| Denis Rivière | Feb 28, 2011 | |
| Cinly Ooi | Mar 1, 2011 | |
| Brandon Whitcher | Mar 1, 2011 | |
| Satrajit Ghosh | Feb 28, 2011 | |
| Jonas Larsson | Mar 1, 2011 | |
| Mark Horsfield | Mar 1, 2011 | |
| Andrew Janke | Mar 1, 2011 | |
| Jochen Weber | Feb 28, 2011 | |
| Randall Frank | Mar 1, 2011 | |
| Michael Martinez | Feb 28, 2011 | |
| Cinly Ooi | Feb 28, 2011 | |
| Chris Rorden | Feb 28, 2011 | |
