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 #16741 is a reply to message #16738] Fri, 20 August 1999 00:00 Go to previous messageGo to previous message
jajones is currently offline  jajones
Messages: 2
Registered: August 1999
Junior Member
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.

2) Some MR formats use multiple headers and footers, so as well as junk
before and after the 64 images there may be junk before and after each
image *and* before and after each row of the image.

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!

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

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

Good luck!

Jonathan
[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: Sat Oct 11 00:28:18 PDT 2025

Total time taken to generate the page: 0.56768 seconds