[caret-users] FW: Problems during/after flattening

Mon Jul 21 11:28:37 CDT 2008

Hi Traci,

I can replicate your problem:  When I extract 
Traci.Sandoval.NPRLab2.tar.gz ; launch caret5; select Human.115.L.spec; 
and select All, I get the attached stickup.  But the only gzipped files 
are the three volume files:

gwbr_s115_mprage_do_susan_bias_acpc.nii.gz
gwbr_s115_mprage_do_susan_bias.nii.gz
gwbr_s115_mprage_do_susan_bias_right_hem.nii.gz

And I can use Toolbar: Spec to open each of them without errors, and 
each of them shows fine in VOLUME view.

In fact, I tried opening each of the files in the spec file, and each 
opened fine.  They all looked reasonable, too, except for 
Human.115.L.InitialFlat._aligned.070708.44857.coord (see attached 
capture initialFlatAligned.jpg).  But 
Human.115.L.InitialFlat.44857.coord looked fine, making me wonder how 
you came to save an aligned version of the initial flat map.  Typically, 
one saves an aligned version of the flat and spherical map at the end of 
morphing, when the aligned flat map looks more like the attached 
FlatAligned.jpg capture (after excising the node that is causing the big 
crossover in the front lobe).  Other than the presence of a cropped 
right hem volume in a left hem spec, I didn't see anything else noteworthy.

Maybe John Harwell will have a better explanation for the premature EOF 
stickup.  Meanwhile, I don't see evidence that it is causing any harm.  
I would ignore it.

Donna

On 07/18/2008 03:08 PM, Sandoval, Traci I wrote:
> I have uploaded the dataset again with the missing files and deleting
> the second mesh. The reading files error is still occurring. Sorry about
> the last upload, this is happening 7/10 times I save after flattening.
> Thank you for your help. Traci
>
>
> Traci Sandoval
> Research Assistant
> NPR Lab
> Center for Brain Health
> University of Texas at Dallas
> University of Texas Southwestern
>
>
>
>
> -----Original Message-----
> From: caret-users-bounces at brainvis.wustl.edu
> [mailto:caret-users-bounces at brainvis.wustl.edu] On Behalf Of Donna
> Dierker
> Sent: Friday, July 18, 2008 11:42 AM
> To: Caret, SureFit, and SuMS software users
> Subject: Re: [caret-users] FW: Problems during/after flattening
>
> Hi Traci,
>
> This doesn't seem to be the same dataset as the one you reference below.
>
> This one is a different case number (115 vs 121), and I can't replicate 
> the problem.  When I open Human.115.L.spec and select all, the only 
> errors I get are for volumes that are missing from the archive you 
> uploaded.  It opens all the files in the spec file.  It is worth noting,
>
> however, that there are files of two distinct meshes in the archive you 
> uploaded:  One with 44857 nodes (covered by the spec) and another with 
> 45350 nodes.  You can't mix files across meshes, of course, but I see no
>
> evidence where the spec file contains files of different meshes.
>
> Donna
>
> On 07/18/2008 10:27 AM, Sandoval, Traci I wrote:
>   
>> I have uploaded the zip file, Traci.Sandoval.NPRLab.archive.tar.gz
>> the number of bytes it is trying to read is exactly 3 times the amount
>>     
> that is being read? Thank you for your help. 
>   
>> Traci Sandoval
>> NPR Lab
>> University of Texas at Dallas 
>>
>>
>> -----Original Message-----
>> From: caret-users-bounces at brainvis.wustl.edu on behalf of Donna
>>     
> Dierker
>   
>> Sent: Wed 7/16/2008 1:30 PM
>> To: Caret, SureFit, and SuMS software users
>> Subject: Re: [caret-users] FW: Problems during/after flattening
>>  
>> Hi Traci,
>>
>> See inline replies below.
>>
>> Donna
>>
>> On 07/16/2008 12:11 PM, Sandoval, Traci I wrote:
>>   
>>     
>>> After I completed the flattening process and go to save all my files,
>>>       
>
>   
>>> I receive an error when I try to save the bordercolor file, it says
>>>       
> it 
>   
>>> is open for writing and cannot save?
>>>
>>>     
>>>       
>> I can think of a few reasons why writing the bordercolor might fail:
>>
>> * Caret doesn't like the filename for some reason.
>> * The file system is full.
>> * You don't have write permission to the current directory.
>>
>> If you have ruled out the second and third reasons, then try a simple 
>> name with no special characters or spaces (e.g., test.bordercolor). We
>>     
>
>   
>> don't really save the flattening bordercolor, anyway; we use the 
>> registration bordercolor set here:
>>
>> http://sumsdb.wustl.edu/sums/archivelist.do?archive_id=6057499
>>   
>>     
>>> Once I close everything and try to open the files again I receive the
>>>       
>
>   
>>> following errors. I receive the bordercolor error everytime, but do 
>>> not always receive the reading files error.
>>>
>>> You have selected border files that require a border
>>> color file but no border color file is selected.
>>>
>>>     
>>>       
>> Again, you could open the 
>> ForSPHERICAL.REGISTRATION_Human.Class3.bordercolor in the dataset
>>     
> linked 
>   
>> above, but its bordercolors won't match the pre-flattening border
>>     
> names; 
>   
>> they will match the post-flattening border color names in the 
>> *fromFlattening*borderproj file.
>>   
>>     
>>> Error Human.121.L.SPHERE_aligned.071008.65070.coord: contains a 
>>> different number of nodes than Human.121.L.Raw.65070.coord
>>> Error .: Premature EOF reading zipped file. Tried to read
>>> 6690888bytes. Actually read 2230296.
>>>
>>>     
>>>       
>> This is a different, more serious problem. The filenames suggest both 
>> coords have 65070 nodes, but the error claims otherwise. The "Tried to
>>     
>
>   
>> read 6690888bytes" seems excessive for a coord file. The 2230296
>>     
> number 
>   
>> seems more reasonable. Was this imported from another format? If you 
>> could upload it here, I could have a look at it:
>>
>> http://pulvinar.wustl.edu/cgi-bin/upload.cgi
>>
>> Often, though, it helps to have the whole dataset (i.e., the spec
>>     
> files 
>   
>> and all files listed in it, or the current working directory) archived
>>     
>
>   
>> in .zip or .tar.gz form.
>>   
>>     
>>> Thank you for your help.
>>>
>>> Traci Sandoval
>>>
>>> Research Assistant
>>>
>>> University of Texas at Dallas
>>>
>>> Center for Brain Health
>>>
>>> NPR Lab
>>>
>>>
>>>       
> ------------------------------------------------------------------------
>   
>>> _______________________________________________
>>> caret-users mailing list
>>> caret-users at brainvis.wustl.edu
>>> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>>>   
>>>     
>>>       
>> _______________________________________________
>> caret-users mailing list
>> caret-users at brainvis.wustl.edu
>> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>>
>>   
>>
>>     
> ------------------------------------------------------------------------
>   
>> _______________________________________________
>> caret-users mailing list
>> caret-users at brainvis.wustl.edu
>> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>>   
>>     
>
> _______________________________________________
> caret-users mailing list
> caret-users at brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>
> _______________________________________________
> caret-users mailing list
> caret-users at brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: prematureEOF.jpg
Type: image/jpeg
Size: 68540 bytes
Desc: not available
Url : http://brainvis.wustl.edu/pipermail/caret-users/attachments/20080721/866b944b/attachment.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: initialFlatAligned.jpg
Type: image/jpeg
Size: 61261 bytes
Desc: not available
Url : http://brainvis.wustl.edu/pipermail/caret-users/attachments/20080721/866b944b/attachment-0001.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FlatAligned.jpg
Type: image/jpeg
Size: 55406 bytes
Desc: not available
Url : http://brainvis.wustl.edu/pipermail/caret-users/attachments/20080721/866b944b/attachment-0002.jpg 