[Vv] clitkMergeSequence

[Thomas BAUDIER]

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