[Insight-users] LinearInterpolateImageFunction tries to access out of bounds pixels even if IsInsideBuffer() check is positive

[Ivan Macia]

Hi Luis, all,

My fault, seems a false alarm :S I was pretty sure I had an InsideBuffer()
check in all Evaluate() calls (I have several of these) but this one was
missing. Then it reminded me the linear interpolator bug I had, but this
seem to have been fixed when ITK_USE_PIXEL_CENTERED_COORDINATES_CONSISTENTLY
is used (thanks for this to the author btw). I tried several times and it
seems to be robust, at least I could not reproduce any error at the image
borders. I will try to check that the rest of programs that were failing due
to this old bug are now working with the latest changes in this class.

Anyway, a method or something could be considered in order to check which is
actually the image region covered by the interpolator.

Sorry for the inconvenience

Iván


2010/6/17 Luis Ibanez <luis.ibanez at kitware.com>

> Hi Ivan,
>
> From your description, this looks like a bug in the IsInsideBuffer()
> method.
>
> It would seem that the method that we use in the IsInsideBuffer() method
> is not consistent with what we do when we call Evaluate().
>
> Could you provide a minimal example that illustrates this problem ?
>
>
>     Thanks
>
>
>          Luis
>
>
> -------------------------------------------------------------
> 2010/6/17 Iván Macía <imacia at vicomtech.org>
>
>>  Dear all,
>>
>>
>>
>> I am experiencing an extremely annoying problem again and again in recent
>> developments when I perform calculations that rely on linear interpolators.
>> This is related to the fact that, even if I check if the point is inside the
>> buffer ( interpolator->IsInsideBuffer( point ), when performing the
>> interpolation sometimes the buffer tries to access and index that is outside
>> bounds and the program crashes, because the interpolated point lies very
>> close to the boundaries. This at least happens with
>> LinearInterpolateImageFunction. I even had to implement my own dirty
>> interpolator with extra bounds checking, which is slower but safer.
>>
>>
>>
>> Should not the interpolator check if any of the indexes that it has to
>> access might be out of bounds? If so I can open an issue in Mantis with an
>> example test program (I cannot post this right now since I have to extract
>> the offending code from my prototype). How could this be handled without
>> severely affecting the performance? Somehow each interpolator knows which
>> would be the extent of pixels that will be accessed but I think this is not
>> made explicit anywhere in the interpolator.
>>
>>
>>
>> Any other ideas to tackle this problem?
>>
>>
>>
>> Thanks in advance.
>>
>>
>>
>> Iván Macía
>>
>>
>>
>>
>>
>> [image: Vicomtech logotipo]
>>
>> *Iván Macía Oliver*
>>
>> Investigador / Researcher
>>
>> eSalud & Aplicaciones Biomédicas / eHealth & Biomedical Applications
>>
>> imacia at vicomtech.org
>>
>>
>>
>> Mikeletegi Pasealekua, 57 - Parque Tecnológico
>>
>> 20009 Donostia - San Sebastián - Spain
>>
>> Tel:
>>
>> +[34] 943 30 92 30
>>
>> Fax:
>>
>> +[34] 943 30 93 93
>>
>> www.vicomtech.org
>>
>>
>>
>>
>>
>> Este mensaje se dirige exclusivamente a su destinatario. La información
>> incluida en el presente correo es confidencial sometida a secreto
>> profesional, especialmente en lo que respecta a los datos de carácter
>> personal, cuya divulgación está prohibida, en virtud de la legislación
>> vigente. Si usted no es el destinatario legítimo y lo ha recibido por error
>> o tiene conocimiento del mismo por cualquier motivo, le rogamos que nos lo
>> comunique por este medio y proceda a destruirlo o borrarlo. En todo caso
>> abstengase de utilizar, reproducir, alterar, archivar o comunicar a terceros
>> el presente mensaje así como los ficheros anexos, todo ello bajo pena de
>> incurrir en responsabilidades legales. Cualquier opinión contenida en este
>> correo es exclusiva de su autor y no representa necesariamente la opinión de
>> ASOCIACIÓN CENTRO DE TECNOLOGÍAS DE INTERACCIÓN VISUAL Y COMUNICACIONES
>> VICOMTech (en adelante Vicomtech) El emisor no garantiza la integridad,
>> rapidez o seguridad del presente correo, ni se responsabiliza de posibles
>> perjuicios derivados de la captura, incorporaciones de virus o cualesquiera
>> otras manipulaciones efectuadas por terceros.
>> Con motivo de la entrada en vigor de la Ley 34/2002, de 11 de julio, de
>> Servicios de la Sociedad de la Información y de Comercio Electrónico, le
>> informamos que pueden revocar en cualquier momento, de forma sencilla y
>> gratuita, el consentimiento para la recepción de mensajes de
>> vicomtech.org en info.lopd at vicomtech.org.
>>
>>
>>
>>
>>
>> _____________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Kitware offers ITK Training Courses, for more information visit:
>> http://www.kitware.com/products/protraining.html
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20100617/f38e350c/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1669 bytes
Desc: not available
URL: <http://www.itk.org/pipermail/insight-users/attachments/20100617/f38e350c/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2849 bytes
Desc: not available
URL: <http://www.itk.org/pipermail/insight-users/attachments/20100617/f38e350c/attachment-0003.gif>