Create a New Forum Admin Login Member Login Contribute to Voyager Search VoyForums Help Desk VoyForums Exchange VoyForums Directory/Categories VoyForums Homepage VoyForums News FAQ - Frequently Asked Questions

[ Show ]

Support VoyForums

[ Shrink ]

VoyForums Announcement: Programming and providing support for this service has been a labor of love since 1997. We are one of the few services online who values our users' privacy, and have never sold your information. We have even fought hard to defend your privacy in legal cases; however, we've done it with almost no financial support -- paying out of pocket to continue providing the service. Due to the issues imposed on us by advertisers, we also stopped hosting most ads on the forums many years ago. We hope you appreciate our efforts.

Show your support by donating any amount. (Note: We are still technically a for-profit company, so your contribution is not tax-deductible.) PayPal Acct: Feedback:

Donate to VoyForums (PayPal):

[ Login ] [ Contact Forum Admin ] [ Main index ] [ Post a new message ] [ Search | Check update time | Archives: 1, [2] ]

[ Edit | View ]

[ Edit | View ]

Replies:

[> Re: siemens file formats -- Mark Elliott, 17:27:08 12/03/02 Tue

Dan,
Very good points. I have looked into this somewhat, and I'll give a brief summary here. The Siemens systems create
Dicom format images, and the scanner can be configured to
perform an automatic "dicom send" to a remote computer waiting to receive the images. We'll set up the CD-burner locally to let users leave with a CDrom as well. There is apparently a wrinkle with the images produced in functional runs, in that Siemens does not produce truly Dicom standard images when performing what they call "acquisition loop" sequences (that's what they call a repeat of the same image sequence temporally, as in any fmri run). These images use some non-standard scheme that regular dicom reading programs will choke on. There is a "fix-it" program which I will try to set up on the scanner to filter these files correctly. More on that when once the scanners arrive.
I don't know a whole lot more than this so far. It might be a good idea to get our hands on some typical Siemens EPI
images from another site to play with.

And congrats on being the first person to post to this board!

Mark.


>I hope this is the right place for this, but feel free
>to redirect me.
>
>I'm wondering about the formats of that data files
>coming off the new scanners (I'm thinking mostly of
>BOLD fMRI and ASL perfusion studies of the brain). It
>would be great if we could find out in advance what
>kind of format the data will come in, so that we can
>make sure everyone using our software will be able to
>process their data without having to wait for us to
>catch up.
>
>I don't know if this is something set in stone or
>something that has to be decided. I guess the
>questions are fairly obvious. If it's some
>proprietary Siemens format, whatever details we can
>get in advance would help. If it's something more
>standard, like DICOM, it would still help to have some
>idea what will be in the files (compressed or
>uncompressed data, what headers, etc.). It would also
>be helpful to know if we can get our functional images
>unreconstructed, or if that has to be done online.
>
>Any information would be greatly appreciated. Thanks,
>
>dan

[ Edit | View ]

[> [> Re: siemens file formats -- Dan Kimberg, 22:49:37 12/03/02 Tue

>Dan,
> Very good points. I have looked into this somewhat,
>and I'll give a brief summary here. The Siemens
>systems create
>Dicom format images, and the scanner can be configured
>to
>perform an automatic "dicom send" to a remote computer
>waiting to receive the images. We'll set up the
>CD-burner locally to let users leave with a CDrom as
>well. There is apparently a wrinkle with the images
>produced in functional runs, in that Siemens does not
>produce truly Dicom standard images when performing
>what they call "acquisition loop" sequences (that's
>what they call a repeat of the same image sequence
>temporally, as in any fmri run). These images use some
>non-standard scheme that regular dicom reading
>programs will choke on. There is a "fix-it" program
>which I will try to set up on the scanner to filter
>these files correctly. More on that when once the
>scanners arrive.

Good to know, and thanks for the quick reply. Non-standard tweaking is not a problem, since we're going to use custom code to import them regardless. As long as it's mostly DICOM-ish, it should be easy to handle.

> I don't know a whole lot more than this so far. It
>might be a good idea to get our hands on some typical
>Siemens EPI
>images from another site to play with.

I'll see if I can track some down (and I'll let you know if I do), but please let me know if you get hold of any. It would also be handy to have other images from the same session (e.g., high-res T1-weighted images), to get some idea what information's available to coregister the images.

>And congrats on being the first person to post to this
>board!

Thanks for setting it up. Although I have some reservations about the lavender background, I think it's a great way to keep CAMRIS users connected.

dan

[ Edit | View ]

[ Edit | View ]

Replies:

[> Re: x offset in BOLD data -- Mark Elliott, 15:25:20 12/17/02 Tue

Dan,
We've got to get at least one other person to use this bulletin board. Otherwise, this is just a really inconvenient way to do email.

As to your shift observation, I haven't observed this. But I also haven't looked for it. My reaction is that you shouldn't be seeing this if the techs aer careful to use the same slice positions (at leat in X-Y) between the structurals and the EPIs. About how big is the shift? If it's about 4 pixels or less (in structural pixel units), then it MIGHT just be from the interpolation of the EPIs (64x64) up to the structural size (256x256) when displaying. Many algorithms do this by "anchoring" to the left when they interpolate up in size. But then one would expect to see a shift in the vertical direction as well.
I'll look at some of my data to see if I observe the same thing.

Mark.

[ Edit | View ]

[ Edit | View ]

[ Edit | View ]

[ Edit | View ]