[Vv] clitkMergeSequence

[Benoît Presles]

Hello Thomas,

Yes, the images are placed at the correct position. I have got the 
expected result.

Best regards,
Ben


Le 14/02/2019 à 11:01, Thomas BAUDIER a écrit :
>
> Hi Benoit,
>
> I investigated and I found 2 things:
>  - For nifti images, if the size of 4th dimension is 1, the image is 
> stored as a 3D Image by ITK
>  - More related to your problem, I look into the ITK code and the 
> problem comes from the reader:
> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/IO/ImageBase/include/itkImageSeriesReader.hxx#L203 
>
> The spacing of the merging dimension is computed from the origin of 
> the slices. In your example, you have your 66 images of dimension 
> 144x144x1 and spacing 4x4x1 each. The offset for the first image is 
> (for example) 0x0x0 and for the last image, it is 0x0x260 (260 = (66 
> images -1)*4). And to have the new spacing, the ITK reader divides the 
> difference of position between the last and the first image by the 
> number of slice (in our example the result is 4). So I think, your 
> images are placed at the correct position even if the spacing is 1, 
> right ?
>
> Regards
> Thomas
>
> On 2019-02-13 18:47, Benoît Presles wrote:
>> Hello Thomas,
>>
>> Le 13/02/2019 à 10:29, Thomas BAUDIER a écrit :
>>>
>>> Hi Benoit,
>>>
>>> On 2019-02-12 18:37, Benoît Presles wrote:
>>>> Hello Thomas,
>>>>
>>>> I am trying to use clitkMergeSequence with a stack of double 2D images
>>>> of size 144x144x1 pixels. The resulting image is a 3D float image...
>>>>
>>>> I have checked the source code and in particular
>>>> clitkMergeSequenceGenericFilter and indeed with one component images,
>>>> the input pixel type is taken into account only if it is short or
>>>> unsigned_char. Is there any reason for that ?
>>>
>>> Apparently, there is no reason. So I modify it, Thank you for your 
>>> remark.
>>> https://github.com/open-vv/vv/commit/e6929caa9906837ade57b84706fe0a38529dc93a 
>>>
>>>>
>>>> At last, in the help, it is written that "-s, --spacing=DOUBLE Spacing
>>>> for the new dimension  (default=`1')". In my case, I did not specify
>>>> any value and the spacing is 4, which is the value I expected.
>>>
>>> Your inputs are 3D images (with a size for the third dimension equal 
>>> to 1), so the output is a 4D image.
>>> If you open your output with vv, you cannot see the last dimension 
>>> because when the 4th dimension is 1, the image is read like a 3D image.
>>> You can see the new dimension displaying the mhd text file.
>>> And the spacing of the 4th dimension is given by the option spacing.
>>
>> Well no, my output image is a 3D double 144x144x66 4x4x4
>> (clitkImageInfo), which is exactly what I expected. I merged with
>> clitkMergeSequence 66 3D double 144x144x1 4x4x1 images
>> (clitkMergeSequence PT0000*_r.nii -o NEWImg.nii -v).
>>
>> Best regards,
>> Ben
>>
>>
>>>
>>> Regards
>>> Thomas
>>>
>>>>
>>>>
>>>> Thanks for your help,
>>>> Ben
>>>>
>>>> _______________________________________________
>>>> vv mailing list
>>>> vv at creatis.insa-lyon.fr
>>>> https://www.creatis.insa-lyon.fr/mailman/listinfo/vv
>>> _______________________________________________
>>> vv mailing list
>>> vv at creatis.insa-lyon.fr
>>> https://www.creatis.insa-lyon.fr/mailman/listinfo/vv
>>
>> _______________________________________________
>> vv mailing list
>> vv at creatis.insa-lyon.fr
>> https://www.creatis.insa-lyon.fr/mailman/listinfo/vv
> _______________________________________________
> vv mailing list
> vv at creatis.insa-lyon.fr
> https://www.creatis.insa-lyon.fr/mailman/listinfo/vv