Is FieldOfViewImageFilter broken?

[acoussat]

Hi!

I am trying to use FieldOfViewImageFilter from three files of mine: phantom.mha, geo.xml and projections.mha (available here). The following command line works and produces the expected result:

rtkfieldofview -g geo.xml -o /tmp/fov.mha -p . -r projections.mha -m --reconstruction phantom.mha

I have now translated this command line into a Python script as follows:

import itk
from itk import RTK as rtk

Dimension = 3
PixelType = itk.F
ImageType = itk.Image[PixelType, Dimension]

ref_itk = itk.imread("phantom.mha")

geo_reader = rtk.ThreeDCircularProjectionGeometryXMLFileReader.New(Filename="geo.xml")
geo_reader.GenerateOutputInformation()
geometry = geo_reader.GetOutputObject()

projections_itk = itk.imread("projections.mha")

fov_filter = rtk.FieldOfViewImageFilter[ImageType, ImageType].New()
fov_filter.SetGeometry(geometry)
fov_filter.SetInput(ref_itk)
fov_filter.SetProjectionsStack(projections_itk)
fov_filter.SetMask(True)
fov_filter.Update()

fov_itk = fov_filter.GetOutput()
itk.imwrite(fov_itk, "/tmp/fov.mha")

However, the script produces a segmentation fault when reaching the line fov_filter.Update(). Have I done something wrong, or is the Python wrapping of FieldOfViewImageFilter broken in some way? I am using ITK 5.0.1 and RTK's master (b0ee95e).

Thanks!

[SimonRit]

The same code works for me. Can you provide your geometry and mhd headers? Or maybe, can you test in a new virtual environment if you have the same problem with the python package compiled here?

[acoussat]

The same code works for me. Can you provide your geometry and mhd headers?

Sure, here you go!

Or maybe, can you test in a new virtual environment if you have the same problem with the python package compiled here?

It works fine using this compiled version. As far as I understand it was also compiled from commit b0ee95e. The only difference I can imagine is ITK's version. What version of ITK is used on Azure? (Sorry, this information is probably available somewhere but I don't know where to look it up.)

[arobert01]

Hi Aurélien,

I think it's ITK 5.0.1 used on Azure for the python package compilation. You can check the ITK version in Python using these commands:

import itk
version = itk.Version.New() 
version.GetITKVersion()

[SimonRit]

Yes. Maybe something is wrong with your compilation or installation? For example, I would check with pip list that itk has not also been installed with pip as a dependency. You could create a new environment with only your compilation to verify that this is really the compilation which is wrong.

[acoussat]

Yes. Maybe something is wrong with your compilation or installation? For example, I would check with pip list that itk has not also been installed with pip as a dependency.

Good call! However, I hadn't any ITK-related packages installed. I also checked where my ITK was coming from using

import itk
itk.__path__

which output my own compiled wrappings.

You could create a new environment with only your compilation to verify that this is really the compilation which is wrong.

I recompiled everything from scratch from a clean ITK 5.0.1 (aaa9989c5fa5731f4597afb536aee7d2f3b055e5) and RTK at b0ee95e. Out of curiosity, I have also compiled both a CUDA and a CUDA-free version. Both of them still produce the segmentation fault.

[SimonRit]

I guess you need to build with CMAKE_BUILD_TYPE equal to RelWithDebInfo to generate a core file and investigate where the crash occurs...

[SimonRit]

Have you managed to progress on this issue?

[acoussat]

No. Since it works using the Azure pipeline wrappings at b0ee95e, I suspect that some library used during compilation produces the error (probably a wrong version). A quick glance at the stacktrace suggests that the error might come from the MKL library, but I don't have any other hint. I have tried to have a look through Valgrind, but since the program is written in Python, it requires some Valgrind trickery that I am unaware of. I have put this issue aside at the moment, but I would like to get back to it and figure it out in the near future. In the meantime, if you have any idea or suggestion, I would gladly listen to them!

[HongweiShao]

No. Since it works using the Azure pipeline wrappings at b0ee95e, I suspect that some library used during compilation produces the error (probably a wrong version). A quick glance at the stacktrace suggests that the error might come from the MKL library, but I don't have any other hint. I have tried to have a look through Valgrind, but since the program is written in Python, it requires some Valgrind trickery that I am unaware of. I have put this issue aside at the moment, but I would like to get back to it and figure it out in the near future. In the meantime, if you have any idea or suggestion, I would gladly listen to them!

I met the same problem when I would like to try the example 'FirstReconstruction.py'. Do you have any solution? I'm using itk 5.1.0 and itk-rtk 2.0.1.

[acoussat]

Unfortunately no, I am still stuck on this. I am currently using the workaround of installing the latest packages from the Azure pipelines artifacts.

[acoussat]

Really small update about this issue: I can reproduce the problem using itk-rtk 2.2.0 but not using itk-rtk 2.1.0. Any idea of what could have changed between these two versions?

[SimonRit]

Not really. I suggest running a git bisect... Some variables are initialized in the latest version of rtk::FieldOfViewImageFilter, maybe that's the issue. I would run a git-bisect to identify the commit causing the issue.