Hi Naj

if you have your vector data in a file called 'vector.txt' (all 
components in one column), you could try with this shell scripting snippet:

---snip---
fslsplit data data_ -t

for counter in $(seq 0 <number_of_3d_volumes>); do
	fslmaths data_$(printf %04d $counter) -div $(cat vector.txt | head -n 
$counter | tail -n 1) divided_data_$(printf %04d $counter)
done

fslmerge -t divided_data divided_data_*
---snap---

Cheers,
Niklas

Najmeh Khalili-Mahani wrote:
> Hi Dave, I get it now.
> 
> To record, for future users:
> 
> I ran into trouble because of importing the nifti raw (INT16) to matlab,
> doing quantitative analyses and then saving  the result with the "same"
> header information (using save_untouch_nii), thus confusing FSL with an
> arbitrary scale slope (since it was already factored out of data through the
> analyses), hence magnifying my expected quantities by an order of ~2!
> 
> Thanks everyone for your help.
> 
> (Now, is there already a script to divide a 4D volume by a vector? ;) )
> Best
> Naj
> 
> 
> 
> 
> On Tue, Feb 23, 2010 at 3:20 PM, David Flitney <[log in to unmask]>wrote:
> 
>> I.e. the value IS 1165.95 regardless of underlying representation? This
>> would seem entirely correct to me. The fact that the INT16 value needs to be
>> scaled by 2.268.... is correct. Otherwise when viewing the INT16 image it
>> would, incorrectly, report an intensity of 514!!
>>
>> On 23 Feb 2010, at 13:19, Najmeh Khalili-Mahani wrote:
>>
>> Thanks Matthew,
>>
>> However,
>>
>> in "raw" file 4D file A      (INT16)      intensity of  voxel(36,26,8,0) is
>> 1165.95 and the  scl_slope = 2.268376.
>> in vol0 of 'fslsplit'ted file (FLOAT32) intensity of voxel (36,26,8)    is
>> 1165.95 and the scl_slope = 1.000000
>>
>> So, it seems to me that fslsplit has changed the data type, and the
>> scale-slope label, without scaling the actual intensities?
>>
>> ?
>>
>> Tnx,
>> Naj
>>
>>
>>
>>
>>
>>
>> On Tue, Feb 23, 2010 at 1:36 PM, Matthew Webster <[log in to unmask]>wrote:
>>
>>> Hi,
>>>      I just spotted that your file had a non-unitary scl_slope - this
>>> means that your file is read in as a float to honour the scl_slope value (
>>> e.g. for voxel (36,26,8,0) the "raw" stored value is 514, multiplied by the
>>> the scl_slope this gives 1165.95 which will be the value used in our tools,
>>> and the output files will be saved with the scaled values and a scl_slope of
>>> 1.0 ).
>>>
>>> Hope this helps,
>>> Many Regards
>>> Matthew
>>>
>>> Hi Matthew,
>>>
>>> While at it, it seems that the fslsplit also sets the scl_slope to 1.00
>>> (without scaling the intensities with the initial scl_slope?)?
>>>
>>> Many thanks
>>> Naj
>>>
>>>
>>> On Tue, Feb 23, 2010 at 10:10 AM, Matthew Webster <
>>> [log in to unmask]> wrote:
>>>
>>>> Hello!
>>>>            I've been able to replicate this behaviour locally ( it seems
>>>> to be for 4D splits only ) and we're looking into a fix...
>>>>
>>>> Many Regards
>>>> Matthew
>>>>
>>>> Hello;
>>>>
>>>> I just noticed that running fslsplit changed the data type?!
>>>>
>>>> I had a 4D image of (INT16) which is split into (FLOAT32) files.
>>>> Attached, the histograms. Top (float32), bottom (INT16).
>>>>
>>>> Many thanks
>>>> Naj
>>>>  <bad_top_good_below.tiff>
>>>>
>>>>
>>>>
>>>
>> --
>> Dave Flitney, IT Manager
>> Oxford Centre for Functional MRI of the Brain
>> E:[log in to unmask] W:+44-1865-222713 F:+44-1865-222717
>> URL: http://www.fmrib.ox.ac.uk/~flitney
>>
>>
>>
>>
> 


-- 
Pflichtangaben gemäß Gesetz über elektronische Handelsregister und Genossenschaftsregister sowie das Unternehmensregister (EHUG):

Universitätsklinikum Hamburg-Eppendorf
Körperschaft des öffentlichen Rechts
Gerichtsstand: Hamburg

Vorstandsmitglieder:
Prof. Dr. Jörg F. Debatin (Vorsitzender)
Dr. Alexander Kirstein
Prof. Dr. Dr. Uwe Koch-Gromus