[ITK] [ITK-users] Buffered Region out of Range error

Michael Jackson mike.jackson at bluequartz.net
Mon Nov 2 16:36:41 EST 2015 

Your suspicions may be correct. We tried with a different filter (Sobel Edge) and get the following Exception from ITK:

"Failed to execute itk::SobelEdgeDetectionImageFilter filter. Error Message returned from ITK:
      itk::ERROR: Image(0x7fb12a112f60): itk::ImageBase::CopyInformation() cannot cast PKN3itk10DataObjectE to PKN3itk9ImageBaseILj3EEE”

Does this help diagnosing the issue?

We have also found that if our actual application is linked against ITK then the code will execute without issues. If the application is NOT linked against ITK but instead only the plugin itself is linked against ITK then the code will fail when multiple plugins are linked against ITK.

Again, thanks for all the help.
--
Mike Jackson  [mike.jackson at bluequartz.net]


> On Nov 2, 2015, at 1:12 PM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> 
> I still think it's a failing dynamic cast some place.
> 
> You could try adding SimpleITK's Explicit library[1] which explicitly instantiates common types used in SimpleITK. Its possible having some of the Core Common classes instated in a shared library resolves the problem. The library should be fairly independent and easy to separate.
> 
> HTH,
> Brad
> 
> [1] https://github.com/SimpleITK/SimpleITK/tree/master/Code/Explicit
> 
> On Nov 2, 2015, at 12:17 PM, Michael Jackson <mike.jackson at bluequartz.net> wrote:
> 
>> That did not seem to help either. Any more ideas? Does ITK build some intermediate static libraries that have “managers” that load filters? I ran into an issue with our own code where we had static libraries with singleton “manager” design patterns that turned out not to work due to each library getting its own singleton instance.
>> --
>> Mike Jackson  [mike.jackson at bluequartz.net]
>> 
>> 
>>> On Oct 30, 2015, at 4:07 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:
>>> 
>>> Thanks for the information.
>>> 
>>> It is hard to tell, but maybe it is related to factory registration.
>>> To test, try this:
>>> 
>>> In the plugin CMake code, add
>>> 
>>>  set(ITK_NO_IO_FACTORY_REGISTER_MANAGER 1)
>>> 
>>> before
>>> 
>>>  include(${ITK_USE_FILE})
>>> 
>>> Then see if neither plugins work, both plugins work, and one of the
>>> plugins works.
>>> 
>>> HTH,
>>> Matt
>>> 
>>> On Fri, Oct 30, 2015 at 1:36 PM, Michael Jackson
>>> <mike.jackson at bluequartz.net> wrote:
>>>> Some more data. If we create an intermediate library that links to ITK, called ITKSupport, and then have our plugins link against ITKSupport then the code executes correctly. Just another data point.
>>>> --
>>>> Michael A. Jackson
>>>> BlueQuartz Software, LLC
>>>> [e]: mike.jackson at bluequartz.net
>>>> 
>>>>> On Oct 30, 2015, at 12:57 PM, Michael Jackson <mike.jackson at bluequartz.net> wrote:
>>>>> 
>>>>> Yes. Verified. Both plugins are built as part of DREAM.3D and we don’t put any extra CXX_FLAGS in any of the CMake files. We also built with VERBOSE=1 and looked at the compile commands to ensure that what we wanted was actually being used. Then we looked at the libraries themselves with otool -L to ensure they all link against libC++. Which they do.
>>>>> 
>>>>> 
>>>>> --
>>>>> Michael A. Jackson
>>>>> BlueQuartz Software, LLC
>>>>> [e]: mike.jackson at bluequartz.net
>>>>> 
>>>>>> On Oct 30, 2015, at 12:05 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:
>>>>>> 
>>>>>> Hi Michael,
>>>>>> 
>>>>>> Sorry to be redundant, and just to be sure: are both A.plugin and
>>>>>> B.plugin built with the same C++ standard library, OSX deployment
>>>>>> target, and C++ standard?
>>>>>> 
>>>>>> Thanks,
>>>>>> Matt
>>>>>> 
>>>>>> On Fri, Oct 30, 2015 at 11:35 AM, Michael Jackson
>>>>>> <mike.jackson at bluequartz.net> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> On Oct 29, 2015, at 11:40 AM, Matt McCormick <matt.mccormick at kitware.com> wrote:
>>>>>>>> 
>>>>>>>> On Thu, Oct 29, 2015 at 10:00 AM, Michael Jackson
>>>>>>>> <mike.jackson at bluequartz.net> wrote:
>>>>>>>>> We also ran an experiment where we moved the ITK Dependency from just the
>>>>>>>>> plugin down into one of our lower level libraries. So now we have the plugin
>>>>>>>>> dependent on a lower level library which then is dependent on the ITK
>>>>>>>>> Libraries. Now the code seems to execute and produce results. This was on OS
>>>>>>>>> X 10.9 and 10.10. So it seems that there is some odd issue with loading the
>>>>>>>>> ITK libraries through a plugin mechanism? Does ITK need the “-fPIC” added to
>>>>>>>>> the list of compile commands?
>>>>>>>> 
>>>>>>>> If ITK is built in a plugin as shared libraries, then it will already
>>>>>>>> be built with -fPIC.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Qt is actually built WITHOUT C++11 support but still links against libc++.
>>>>>>>>> They (the Qt Devs) set the OS X Min Deployment Version to 10.7. I have no
>>>>>>>>> idea what that triggers or not.
>>>>>>>> 
>>>>>>>> All code should be built with the same C++ standard and OSX deployment
>>>>>>>> target. When building ITK and related code, set
>>>>>>>> CMAKE_OSX_DEPLOYMENT_TARGET [1] to 10.7 to ensure all binaries are
>>>>>>>> using consistent libraries.
>>>>>>>> 
>>>>>>>> HTH,
>>>>>>>> Matt
>>>>>>>> 
>>>>>>>> [1] https://cmake.org/cmake/help/v3.3/variable/CMAKE_OSX_DEPLOYMENT_TARGET.html
>>>>>>> 
>>>>>>> Matt,
>>>>>>> We have verified that ALL dependent libraries are built with libC++, 10.7 as the min deployment, C++11 enabled. This goes for Boost, HDF5, Eigen, ITK, and Qt 5.5.1. We still have the issue. We can also reproduce that if we move the dependency to a lower level then the issue goes away. So it would seem that there is a problem with multiple plugins being dependent on the same External library. in this case it is ITK. I’ll try to diagram below.
>>>>>>> ## Failure Mode ##
>>>>>>> A.plugin depends on ITK
>>>>>>> A.plugin depends on SIMPlib.
>>>>>>> 
>>>>>>> B.plugin depends on ITK
>>>>>>> B.plugin depends on SIMPlib.
>>>>>>> 
>>>>>>> B.plugin will fail to execute properly.
>>>>>>> 
>>>>>>> ## Success Mode ##
>>>>>>> A.plugin depends on SIMPlib.
>>>>>>> SIMPlib depends on ITK
>>>>>>> 
>>>>>>> B.plugin depends on SIMPlib.
>>>>>>> SIMPlib depends on ITK
>>>>>>> 
>>>>>>> The DREAM.3D filters both execute properly and give the proper output.
>>>>>>> 
>>>>>>> --
>>>>>>> Michael A. Jackson
>>>>>>> BlueQuartz Software, LLC
>>>>>>> [e]: mike.jackson at bluequartz.net
>>>>>>> _____________________________________
>>>>>>> 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.php
>>>>>>> 
>>>>>>> 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://public.kitware.com/mailman/listinfo/insight-users
>>>>> 
>>>> 
>> 
>> _____________________________________
>> 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.php
>> 
>> 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://public.kitware.com/mailman/listinfo/insight-users
> 

_____________________________________
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.php

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://public.kitware.com/mailman/listinfo/insight-users

More information about the Community mailing list