History of AFNI updates
Suggested reading for beginners
Add yourself to the AFNI map!
|
Author: Dominic Cheng (---.psy.uwm.edu)
Date: 01-31-03 12:04
Hi
Has anyone enountered the following error when using to3d to generate 3d+time files?
DICOM ERROR: oversize length=989867264 in
element (0000, 2800) [there are too many of these errors to reproduce]
Fatal Signal 2 (SIGINT) received
mri_read
mri_read_file
T3D_read_images
to3d:main
The command line that I use is:
to3d -ncolor 10 -nosave -2swap -xFOV 120S-I -yFOV 120A-P -zSLAB 61L-67R -anatparent elvis.anat -session ./ -prefix 1elvis3d -epan -time:tz 294 17 2000 alt+z exp1/exp1\*
This error occurs on new and previously reconstructed data on two different linux machines (Caldera & RH). I've also updated to the latest AFNI version.
Thanks
dominic
|
|
Reply To This Message
|
|
Author: bob cox (---.nimh.nih.gov)
Date: 01-31-03 12:49
The error occurs because of the following confluence of situations:
1) If to3d can't guess the image file type from its name, then it tries to read it as a DICOM file.
2) DICOM files don't necessarily have any particular identifying marker in them, so the DICOM reading code just tries to read the DICOM attributes until an error occurs. If no error occurs, the file is assumed to be a DICOM image.
3) However, the DICOM reading code apparently can't recover from all errors.
What format are your images, anyway? That surely isn't obvious from the filenames.
bob cox
|
|
Reply To This Message
|
|
Author: Dominic Cheng (---.psy.uwm.edu)
Date: 01-31-03 14:17
The images are echo planar. Is this enforcement of -'type' new to the latest version of to3d? Older versions of to3d seem to be able to recognize the format without using the -'type' flag.
Thanks
dominic
|
|
Reply To This Message
|
|
Author: bob cox (---.nimh.nih.gov)
Date: 01-31-03 14:34
You are confusing the "-type" flag (which has to do with the dataset output) with the input image type. to3d tries to auto-detect the input image type. This is failing badly in your case.
I could add a flag to to3d to tell it to skip trying the DICOM image type. But I can't do that today - I'm too busy. If you are reading the typical 8192 byte long 64x64 files from MCW, then you can change the image filename specification from
exp1/exp1\*
to something like
'3D:0:0:64:64:1:exp1/exp1*'
which should force the input image files to be read in the correct way.
bob cox
|
|
Reply To This Message
|
