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 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: Philips Gyroscan ACS-NT: Raw data format [message #16738] Fri, 20 August 1999 00:00
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
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 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
Re: Philips Gyroscan ACS-NT: Raw data format [message #16742 is a reply to message #16738] Fri, 20 August 1999 00:00 Go to previous message
Mike Smith is currently offline  Mike Smith
Messages: 1
Registered: August 1999
Junior Member
Jonas <jonas_2@hotmail.com> wrote in message
news:7pj827$55u$1@news.lth.se...
> 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 know nothing about this file format, but 42025472 divided by 50 divided by
65536 (the number of pixels per slice) yields 12.82515625 bytes per pixel.
I'm guessing this is really 12 bytes per pixel, plus the header (actually,
this ends up leaving 2703872 bytes for the header, so I'm not sure this is
right either). How the 12 bytes are used is beyond me. A pair of
Pascal-style 6-byte reals, maybe?

--
Mike Smith. No, the other one.
  Switch to threaded view of this topic Create a new topic Submit Reply
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 01:38:58 PDT 2025

Total time taken to generate the page: 1.19823 seconds