[Insight-users] Filter with inputs which do not occupy the same physical space

[Dženan Zukić]

I solved it by transforming it into a function. If someone runs into a
similar issue, the function is below:

//define type of "pointer to function" (does the actual combination)
typedef float (*CombineFunction)(std::vector<float>);

InternalImageType::Pointer combineClassifiers
    (std::vector<InternalImageType::Pointer> classifiers,
    CombineFunction combinationMethod)
{
    InternalImageType::Pointer output=InternalImageType::New();
    output->CopyInformation(classifiers[0]);
    output->SetRegions(output->GetLargestPossibleRegion());
    output->Allocate();
    itk::ImageRegionIterator<InternalImageType> out(output,
output->GetLargestPossibleRegion());

    unsigned i=0,nIn=classifiers.size();
    std::vector<float> probabilities(nIn); //individual classifier results
    InternalImageType::PointType p;
    InternalImageType::IndexType ind0, indN;

    while(!out.IsAtEnd())
    {
        ind0=out.GetIndex();
        probabilities[0]=classifiers[0]->GetPixel(ind0);
        output->TransformIndexToPhysicalPoint(ind0, p);

        for (i=1; i<nIn; i++) //collect from input images into std::vector
        {
            classifiers[i]->TransformPhysicalPointToIndex(p, indN);
            probabilities[i]=classifiers[i]->GetPixel(indN);
        }

        out.Set(combinationMethod(probabilities)); //calculate output using
chosen method
        ++out;
    }
    return output;
}

2011/8/9 Dženan Zukić <dzenanz at gmail.com>

> Hi guys,
>
> I am trying to create a filter with n+m inputs and 1 output. n inputs have
> full size (the whole image), while the remaining m inputs are only a certain
> sub-region of that image (schematic attached).
>
> I have written all the code, and it works well for the case of 4 same-sized
> inputs. But when 3 cropped inputs are added, I hit and exception in
> d:\sdk\itk4\modules\core\common\include\itkImageToImageFilter.hxx, line 253
> Inputs do not occupy the same physical space!
> InputImage Origin: [26.107, -141.741, 231.561], InputImage4 Origin:
> [26.4835, -27.7276, 75.3783]
>
> The main reason I wrote this logic as a filter is that it is
> easily parallelizable and I wanted to take advantage of the filter
> multithreading infrastructure.
>
> Of course, I want to produce the output the same size (and position) as the
> smaller images, sampling larger images by voxel position, not index.
>
> Is there some workaround for this limitation or should I just abandon
> multithreading and write normal sequential function?
>
> Regards,
> Dženan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20110809/a7f24b0a/attachment.htm>