Minor note below...
On Fri, Apr 20, 2012 at 9:23 AM, chm <[email protected]> wrote:
> 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.
>>
>
For packing/unpacking a real C struct, including proper byte alignments and
all, Convert::Binary::C is a real gem: p3rl.org/Convert::Binary::C
It has a built-in C preprocessor and parser that can boil any struct down
to the true C datatypes. The underlying code is written in C using Flex
and/or Bison, so it's fast and reliable.
David
> 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<http://mailman.jach.hawaii.edu/mailman/listinfo/perldl>
>
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
