[Insight-developers] Get/SetPixel() with taking an offset parameter

Karthik Krishnan karthik.krishnan at kitware.com
Wed Dec 13 17:08:58 EST 2006


On 12/12/06, Gaetan Lehmann <gaetan.lehmann at jouy.inra.fr> wrote:
>
>
> Hi,
>
> >
> > Hi Gaetan,
> >
> > That's an interesting option.
> >
> > However, please note that a better way of approaching this problem
> > is to create an Iterator that is specific to the way you want to
> > walk in your image.
> >
> > It seems that in your algorithm you are already defining a clever
> > way of finding the offsets that will lead you to the next pixel
> > of interest.  What we probably want to explore is the possibility
> > of creating a new Image Iterator that will do the equivalent job.
> >
>
> What is done in ReconstructionByDilationImageFilter currently work only
> with shape iterators, so having the same operators on the other iterators
> would be great. I'm not sure that a dedicated iterator is needed.
>
> > In general you want to avoid having direct access to the image buffer.
> > One of the reasons for it is that soon we will be introducing in ITK
> > an alternative memory layout where the pixel data is not stored in a
> > contiguous block of memory. Instead, the pixel data may be stored as
> > a collection of disconnected slices.
> >
> > Having a GetPixel()/SetPixel() methods with direct access to the
> > buffer data will not work in this memory layout. We already will have
> > to manage the modification of the existing ComputOffset() method.
> >
>
> I'm not sure that modifying the Get/SetPixel() method is the best way to
> go, but what is proposed has no extra cost, because the ComputeIndex() and
> ComputeOffset() are already exposed, and there is nothing more done that
> using these methods.


I agree with Luis here. There are already itk::Image classes in ITK where
this would not work. For instance itk::VectorImage does an internal
multiplicaiton with the m_VectorLength to any offset supplied to it as in :

  PixelType GetPixel(const IndexType &index)
    {
    OffsetValueType offset = m_VectorLength * this->ComputeOffset(index);
    PixelType p( &((*m_Buffer)[offset]), m_VectorLength );
    return p;
    }


The rationale here is that the mapping from "itk::Index" to "Offset",
although it is a one to one mapping;  the mapping is best determined
internally by the image and should not be exposed to the user.

I can think of OrientedImages doing internally manipulating the Index to
compute an offset. Or you could think of adding blanking support in ITK (VTK
added it not so long ago), where you can assign a entire block of pixels to
0, (intended for very large datasets). You could also think of
non-contiguous memory organization for images, (slice by slice etc). This
might be necessary for large datasets.

Exposing the offset parameter could hamper a flexible design later.

my 2 Rupees :)

-- 
karthik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.itk.org/mailman/private/insight-developers/attachments/20061213/6974aad0/attachment.html


More information about the Insight-developers mailing list