On 4/20/2012 9:43 AM, Ingo Schmid wrote:
Hi,
1., the basic IO is no problem. It's 348 bytes of header, read() and
unpack()ed based on what is defined in nifti.h.
2. The data is easy also, given readflex and the info present in the
header dim field(s).
The only tricky part is how to best represent the meta data.. Since
piddles are pure arrays from an application's point of view, best would
be to create a class and address the piddle and header elements through
methods.
For a start, I will just provide a read function, returning a data
piddle and header hash ref.
Writing is essentially the same but reversed, populating header fields
with user input.
Many times it is enough to just load/save imaging data.
Our specific needs are compatibility to matlabs's load_nii, and some FSL
tools, but I don't expect them to be too demanding.
The question bugging me was how to handle data in types not represented
in PDL when importing.
One option: use a "larger" containing datatype
that would not lose precision. If not convenient,
you could use a datatype of the right size and
then coerce the data to the needed type.
As a fallback, you could always read the data in
as a binary blob (i.e., a byte array). Then you
can use pack/unpack to massage the data directly
from the $pdl->get_dataref reference. Further
games could be done by writing Inline::C or Inline::PP
routines.
ushort I will map to short if the windowing is small enogh, otherwise
long, the same with ulong.
ushort is a supported PDL datatype
ulong is as well
An option should be present to be strict -- and possibly barf -- when
loading would mean potential data/precision loss or explicitly supply a
target type.
I will not provide conversion that would go beyond what is possible with
readflex, atm.
readflex doesn't do much/any conversions. It does
handle bad values in current PDL versions.
I've several programs using a lot of fft/ifft (PDL::FFT), it does what
it does, performance is ok, and, as you say, the fftw 2 bindings just
won't do it.
PDL::Complex works ok, in that most of the time you just need the basic
arithmetic functions, not worrying how to do +-*/, sqrt, sin, etc using
pairs of piddles.
Native support of all common c types and their complex counterparts
would of course be a nice feature, as was discussed a few weeks ago.
I've a complete MRI data reconstruction software almost ready, it's just
the output to a commonly used data format is missing, both nifti and
minc are good candidates, but our people do more in matlab/nifti.
You might look at the start of a PDL::IO::ENVI module
in the PDL distribution for some ideas.
I don't expect any major problem with this module, though, most of the
fields are explained, and probably ignored anyways. It's just that I
wanted to make sure I wasn't missing anything.
Ingo
On 04/20/2012 03:01 PM, chm wrote:
On 4/20/2012 5:27 AM, Ingo Schmid wrote:
Hi,
could you please confirm, looking at Types.pm, currently only the
following data types are supported:
Byte (unsigned) (8 bit)
signed and unsigned short 16bit
signed long 32 bit
signed longlong 64 bit
Correct?
Yes
I'm working on an IO::Nifti module.
How should I handle complex numbers? Use PDL::Complex or as 2 real
piddles for better compatibility?
For flexibility I usually try to implement
IO with a low-level ("raw") part that brings
the data in as simply as possible (keeping the
piddle data close to the actual input data or,
if you are using niftilib, as close as to that
input format as possible). Once you have that
direct layer, higher level features can be added
for the final user interface.
Some thoughts:
* You could have an option to select either
output format and let the users decide
* I see there are a number of other niftilib
based IO interfaces for other languages,
what choices did they make?
* What are the compatibility issues to which
you are referring?
* PDL complex support has not seen a lot of
development but that is directly related to
the number of users and developers working with
complex data.
* If you are processing complex data, do you
do any FFTs? The PDL FFTW bindings are for
FFTW version 2 while the FFTW library has been
version 3 for some time now.
--Chris
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
