comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: Philips Gyroscan ACS-NT: Raw data format
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: Philips Gyroscan ACS-NT: Raw data format [message #16738] Fri, 20 August 1999 00:00 Go to previous message
Jonas is currently offline  Jonas
Messages: 23
Registered: May 1998
Junior Member
Thank you for your interesting comments. See furhter comments below

Jonathan Jones <jajones@ermine.ox.ac.uk> skrev i
diskussionsgruppsmeddelandet:7pjmtp$19o$1@news.ox.ac.uk...
> In article <7pj827$55u$1@news.lth.se>, Jonas <jonas_2@hotmail.com> wrote:
>> I have some MR image raw data exported from a Philips Gyroscan ACS-NT MRI
>> scanner.
>> I have never worked with images from Philips MR scanners before,
therefore
>> having trouble opening the images. Has anyone out there any experience of
>> the file format used?
>> The images are acquired using a 3-D sequence and the whole image volume
(50
>> images) are stored in one single file, 42,025,472 bytes large.
>> I do not really understand the size of the file, since the images have a
>> resolution of 256*256, and I suppose that each pixel is a complex number
>> (4+4 byte), i.e. the file size should be 256*256*8*50+header =
>> 26,214,400+header byte. A 16 MB large header???
>> I would appreciate any info on header size, position of image data within
>> file, how the image data is stored, big/little-endian etc....
>
> Some things to bear in mind:
>
> 1) The data is probably stored as 64 256*256 images (not 50), which at
> 8 bytes per point gives 33554432 bytes = 32 Mb of data, leaving a mere
> 8Mb or so of headers.

why 64 images? in order to simplify fft-reconstruction?


> 3) The actual data is probably floating point numbers in the standard
> format; headers are often a mixture of integers and text. You can often
> locate the data regions by just reading the raw file as floats and looking
> for regions that "make sense". Decoding the header, rather than just
> locating it, is much trickier!
>

I'll try that

> 4) The complex data could be stored as interleaved real and imag, or all
> real followed by all imag.
>

As I see it there is three possibilites:
interleaved for each pixel
interleaved for each image
interleaved for the whole volume
Phew, I have some serious trial and error in front of me...
In fact the only time I have obtained anything similar to MR image raw data
is when I read the file as 16-bit integer. Think I'll have to keep trying
that way
Earlier I have only been working with images produced on Siemens scanners.
The raw data from those scanners are saved in separate files for each image
and with a 6144 byte header followed by complex data pixel interleaved.

> 5) If you have a 2D image to hand it may be easier to start work on that.

Well, I have the corresponding images as well, but so far I have not been
able to produce any images looking anything like those when i reconstruct
them...


sincerely
Jonas
[Message index]
 
Read Message
Read Message
Read Message
Previous Topic: bounds check in array subscripts
Next Topic: Re: Common trouble

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Oct 10 19:19:26 PDT 2025

Total time taken to generate the page: 0.95477 seconds