Luis,
As you told me I have done some change in ImageReadWrite so that it
can handle 3 dim data. Now as I told you I have to file ascii.vtk and
bin.vtk which are exactly the same if you use python+vtk. One is
structured points binary and the other ascii.
I used ImageReadWrite to generate some mha file:
ImageReadWrite ascii.vtk ascii.mha
ImageReadWrite bin.vtk bin.mha
If I diff bin.mha and ascii.mha they are the same (except
ElementDataFile of course)
I have download hexdiff on the internet to diff the raw file. And I find
somthing very weird. There is something like a shift (Little /big endian
related stuff ?) in the file (have a look at line 80 and following):
--[ Visuel HexDiff v 0.0.33 (g) tTh 2002 ]------------------------ hex -
7bits -
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000080 04 00 08 00 0c 00 08 00 07 00 0b 00 0d 00 0d 00
00000090 0d 00 0c 00 0c 00 08 00 05 00 03 00 04 00 05 00
000000a0 06 00 0e 00 12 00 0d 00 07 00 08 00 07 00 08 00
000000b0 0c 00 0c 00 0b 00 09 00 0b 00 0d 00 09 00 08 00
000000c0 0c 00 0d 00 0b 00 09 00 0e 00 11 00 0b 00 06 00
000000d0 0a 00 0a 00 07 00 0b 00 0d 00 0e 00 0e 00 0d 00
000000e0 0b 00 0d 00 10 00 10 00 0d 00 09 00 07 00 09 00
000000f0 0c 00 0f 00 0e 00 0d 00 0e 00 10 00 0f 00 0a 00
00000100 10 00 15 00 15 00 10 00 0b 00 08 00 0a 00 0c 00
00000110 0d 00 0e 00 0e 00 0d 00 0d 00 0c 00 0b 00 0c 00
** /home/malat/Kitware/InsightData/voutay07-origin-a33554432 0 0%
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000080 00 04 00 08 00 0c 00 08 00 07 00 0b 00 0d 00 0d
00000090 00 0d 00 0c 00 0c 00 08 00 05 00 03 00 04 00 05
000000a0 00 06 00 0e 00 12 00 0d 00 07 00 08 00 07 00 08
000000b0 00 0c 00 0c 00 0b 00 09 00 0b 00 0d 00 09 00 08
000000c0 00 0c 00 0d 00 0b 00 09 00 0e 00 11 00 0b 00 06
000000d0 00 0a 00 0a 00 07 00 0b 00 0d 00 0e 00 0e 00 0d
000000e0 00 0b 00 0d 00 10 00 10 00 0d 00 09 00 07 00 09
000000f0 00 0c 00 0f 00 0e 00 0d 00 0e 00 10 00 0f 00 0a
00000100 00 10 00 15 00 15 00 10 00 0b 00 08 00 0a 00 0c
00000110 00 0d 00 0e 00 0e 00 0d 00 0d 00 0c 00 0b 00 0c
If you want the whole hexdump + diff file you can have it on:
http://www.imaging.robarts.ca/~mmalat/vtk/diff.txt.gz (beware it's a
38Mo file !)
HTH,
mathieu
Ps: ImageReadWrite doesn't handle dicom file format. So I haven't been
able to check also with dicom file (nor Gipl and Analyze which I don't
know).
Luis Ibanez wrote:
>
> Hi Mathieu,
>
> I see your point...
> But I would suggest to make the modification in the
> normalization of the Gaussians.
>
> We may want to keep a consistent spacing signs, in
> particular if you are interested in doing registration
> with this image. Spacing will be used to map world
> coordinates to grid points. A negative spacing put the
> image reflected over the origin. The interpolators,
> metrics and resampling filters will use this for
> computing positions.
>
> Now, in registration we compute Metrics derivatives by
> multiplying the Jacobian of the transform by the Gradient
> of one of the images. The Jacobian of the transform will
> be using the reflected coordinate system resulting from
> negative spacing. If we fabs() the spacing in the derivative
> filter this will change the direction of the Metric derivatives.
>
> So,
> The RecursiveGaussianFilter has been corrected in order
> to use fabs( spacing ) in all the computations, but still
> use the spacing sign in the normalization factor.
>
> That should take care of the problem.
>
> Now about other filters... it is good to keep eyes open.
> Chances are that many of them are not checking for the
> spacing sign.
>
> -----
>
> About the file format ...
>
> ITK is templated over pixel type. There is not restriction
> to 8bit data. This particular application is using an input
> pixel type of 'signed short' and then promoting it to 'float'
> pixel type in order to apply the anisotropic diffusion filters.
>
> So, there is no limitation to 8bit data here, It may rather be
> a limitation of the VTKImageIO reader. Have you tried loading
> other image formats ?
>
> Possible choices are : Dicom, MetaImage, Gipl, Analyze.
>
> Please let us know what you find,
>
> Thanks
>
>
> Luis
>
>
> -------------------------------------
>
> Mathieu Malaterre wrote:
>
>> Luis,
>> I am still amazed that you can find time to answer emails and
>> continue developping ITK. Give your trick !
>> Anyway I still have some questions about my preceeding email.
>>
>> - What if I add (in itkRecursiveGaussianImageFilter.txx ):
>> m_Spacing = fabs(m_Spacing); //line 52 before if( m_Spacing <
>> spacingTolerance)
>>
>> this shouldn't make any difference as finite difference are magnitude
>> based.
>> What I don't know is if other filters might complain about that. What
>> do you think ?
>>
>> - I am using CT image with a scalar range of :(0.0, 870.0). If I read
>> my image in binary or ascii through a python+vtk script this is ok.
>> But when I use RegionGrowingSegmentation there is a difference.
>> RegionGrowingSegmentation can only read properly ascii data file. Is
>> ITK although assuming a range of (0, 255) all over the place ?
>>
>> thanks
>> mathieu
>>
>>
>
>
>
>
>