[Insight-developers] PhilipsRecImageIO
Hi Kent, I noticed that the change 966fcb62c859229f9b421403c4faf3e6ef5e2b81 included the line: metaDict-Clear(); to the function ReadImageInformation from itkPhilipsRECImageIO.cxx. This gives a compile error: /usr/local/toolkits/ITK/latest_release/src/Modules/IO/PhilipsREC/src/itkPhilipsRECImageIO.cxx: In member function âvirtual void itk::PhilipsRECImageIO::ReadImageInformation()â: /usr/local/toolkits/ITK/latest_release/src/Modules/IO/PhilipsREC/src/itkPhilipsRECImageIO.cxx:744:3: error: âmetaDictâ was not declared in this scope Did you not mean: thisDic-Clear(); ? If this was not discovered at the dashboard, then probably the option Module_ITKIOPhilipsREC was not enabled. By default it is OFF. Regards, Marius Marius Staring, PhD Division of Image Processing (LKEB) Department of Radiology Leiden University Medical Center PO Box 9600, 2300 RC Leiden, The Netherlands phone: +31 (0)71 526 2137, fax: +31 (0)71 524 8256 m.star...@lumc.nl ___ 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://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://www.itk.org/mailman/listinfo/insight-developers
Re: [Insight-developers] PhilipsRecImageIO
Marius, I also just discovered this on a system I have not build on for a while. Must be the only system I have with Philips IO turned on. I'll submit a gerrit patch. Actually, thisDic-Clear() should be thisDic.Clear(). Bill On Tue, Dec 18, 2012 at 5:08 AM, m.star...@lumc.nl wrote: Hi Kent, I noticed that the change 966fcb62c859229f9b421403c4faf3e6ef5e2b81 included the line: metaDict-Clear(); to the function ReadImageInformation from itkPhilipsRECImageIO.cxx. This gives a compile error: /usr/local/toolkits/ITK/latest_release/src/Modules/IO/PhilipsREC/src/itkPhilipsRECImageIO.cxx: In member function âvirtual void itk::PhilipsRECImageIO::ReadImageInformation()â: /usr/local/toolkits/ITK/latest_release/src/Modules/IO/PhilipsREC/src/itkPhilipsRECImageIO.cxx:744:3: error: âmetaDictâ was not declared in this scope Did you not mean: thisDic-Clear(); ? If this was not discovered at the dashboard, then probably the option Module_ITKIOPhilipsREC was not enabled. By default it is OFF. Regards, Marius Marius Staring, PhD Division of Image Processing (LKEB) Department of Radiology Leiden University Medical Center PO Box 9600, 2300 RC Leiden, The Netherlands phone: +31 (0)71 526 2137, fax: +31 (0)71 524 8256 m.star...@lumc.nl ___ 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://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://www.itk.org/mailman/listinfo/insight-developers -- Unpaid intern in BillsBasement at noware dot com ___ 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://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://www.itk.org/mailman/listinfo/insight-developers
[Insight-developers] Need to patch itk4.3.0
Matt, Marius Staring just reported that PhilipRECImageIO does not compile. Apparently, none of our dashboards have it enabled. I verified it this morning on one of my systems. I have fixed the problem and submited a gerrit patch: http://review.source.kitware.com/#/c/8979/ Once approved, this must be added to the new release. I don't think we can wait for a patch release. We also need to turn this module on and probably others on at least one nightly. We may have issues with other modules. Bill -- Unpaid intern in BillsBasement at noware dot com ___ 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://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://www.itk.org/mailman/listinfo/insight-developers
Re: [Insight-developers] Need to patch itk4.3.0
Hi Bill, Marius, Thanks for identifying the error and the patch. Yes, we should definitely have the code tested on the dashboard if we want this class to work. The 4.3.0 tag has already been pushed, and it cannot be changed. I can make a 4.3.1 release on Friday. Thanks, Matt On Tue, Dec 18, 2012 at 8:23 AM, Bill Lorensen bill.loren...@gmail.comwrote: Matt, Marius Staring just reported that PhilipRECImageIO does not compile. Apparently, none of our dashboards have it enabled. I verified it this morning on one of my systems. I have fixed the problem and submited a gerrit patch: http://review.source.kitware.com/#/c/8979/ Once approved, this must be added to the new release. I don't think we can wait for a patch release. We also need to turn this module on and probably others on at least one nightly. We may have issues with other modules. Bill -- Unpaid intern in BillsBasement at noware dot com ___ 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://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://www.itk.org/mailman/listinfo/insight-developers
[Insight-developers] Why are FFTW CMake variables different?
Hello,
I was looking to pass some CMake variable from my SimpleITK superbuild down to
the ITK external project build. So I assembled a list for cmake varaibles that
began with ITK_:
get_cmake_property( _varNames VARIABLES )
foreach (_varName ${_varNames})
if(_varName MATCHES ^ITK_ )
message( Variable defined ${_varName}: ${${_varName}})
list(APPEND ITK_VARS ${_varName})
endif()
endforeach()
And passed to those to my ITK external project. While these ITK cmake variables
are not defined in the top level, a user could base say
-DITK_USE_SYSTEM_TIFF:BOOL=ON to the top level superbuild, and ITK would be
configured and build with this user specified option. (This will get a lot more
interesting when enabling module could also be passes.)
Only problem is that the FFTW cmake variables don't match. These are the ones I
am talking about:
USE_SYSTEM_FFTW
USE_FFTWD
USE_FFTWF
I think that these variable should begin with ITK to match the reset of the
similar variable in ITK.
Does anyone else have an opinion on this?
Thanks,
Brad
___
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://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://www.itk.org/mailman/listinfo/insight-developers
Re: [Insight-developers] PhilipsRecImageIO
Mea Maxima Culpa. This was meant to fix a problem where re-use of ImageIO objects was putting metadata from one file read into the next file read. I should have caught this but like you I didn't have PHilipsRecImageIO turned on. Is there a good reason not to have this ON by default? And I'm all for making all the factory builds turn on everything that's practical to turn on. On 12/18/12 4:08 AM, m.star...@lumc.nl m.star...@lumc.nl wrote: Hi Kent, I noticed that the change 966fcb62c859229f9b421403c4faf3e6ef5e2b81 included the line: metaDict-Clear(); to the function ReadImageInformation from itkPhilipsRECImageIO.cxx. This gives a compile error: /usr/local/toolkits/ITK/latest_release/src/Modules/IO/PhilipsREC/src/itkPh ilipsRECImageIO.cxx: In member function âvirtual void itk::PhilipsRECImageIO::ReadImageInformation()â: /usr/local/toolkits/ITK/latest_release/src/Modules/IO/PhilipsREC/src/itkPh ilipsRECImageIO.cxx:744:3: error: âmetaDictâ was not declared in this scope Did you not mean: thisDic-Clear(); ? If this was not discovered at the dashboard, then probably the option Module_ITKIOPhilipsREC was not enabled. By default it is OFF. Regards, Marius Marius Staring, PhD Division of Image Processing (LKEB) Department of Radiology Leiden University Medical Center PO Box 9600, 2300 RC Leiden, The Netherlands phone: +31 (0)71 526 2137, fax: +31 (0)71 524 8256 m.star...@lumc.nl Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ___ 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://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://www.itk.org/mailman/listinfo/insight-developers
Re: [Insight-developers] PhilipsRecImageIO
I think it is not on be default because it seems to have limited usage. On Tue, Dec 18, 2012 at 10:48 AM, Williams, Norman K norman-k-willi...@uiowa.edu wrote: Mea Maxima Culpa. This was meant to fix a problem where re-use of ImageIO objects was putting metadata from one file read into the next file read. I should have caught this but like you I didn't have PHilipsRecImageIO turned on. Is there a good reason not to have this ON by default? And I'm all for making all the factory builds turn on everything that's practical to turn on. On 12/18/12 4:08 AM, m.star...@lumc.nl m.star...@lumc.nl wrote: Hi Kent, I noticed that the change 966fcb62c859229f9b421403c4faf3e6ef5e2b81 included the line: metaDict-Clear(); to the function ReadImageInformation from itkPhilipsRECImageIO.cxx. This gives a compile error: /usr/local/toolkits/ITK/latest_release/src/Modules/IO/PhilipsREC/src/itkPh ilipsRECImageIO.cxx: In member function âvirtual void itk::PhilipsRECImageIO::ReadImageInformation()â: /usr/local/toolkits/ITK/latest_release/src/Modules/IO/PhilipsREC/src/itkPh ilipsRECImageIO.cxx:744:3: error: âmetaDictâ was not declared in this scope Did you not mean: thisDic-Clear(); ? If this was not discovered at the dashboard, then probably the option Module_ITKIOPhilipsREC was not enabled. By default it is OFF. Regards, Marius Marius Staring, PhD Division of Image Processing (LKEB) Department of Radiology Leiden University Medical Center PO Box 9600, 2300 RC Leiden, The Netherlands phone: +31 (0)71 526 2137, fax: +31 (0)71 524 8256 m.star...@lumc.nl Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ___ 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://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://www.itk.org/mailman/listinfo/insight-developers -- Unpaid intern in BillsBasement at noware dot com ___ 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://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://www.itk.org/mailman/listinfo/insight-developers
Re: [Insight-developers] PhilipsRecImageIO
On Tue, 18 Dec 2012 15:48:40 +, Williams, Norman K said: I should have caught this but like you I didn't have PHilipsRecImageIO turned on. Is there a good reason not to have this ON by default? And I'm all for making all the factory builds turn on everything that's practical to turn on. I'd like to turn it on on my dashboards, as I use that code. In fact, I had assumed it was on. I have ITK_BUILD_ALL_MODULES=1, but apparently that doesn't mean what I thought... Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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://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://www.itk.org/mailman/listinfo/insight-developers
Re: [Insight-developers] Why are FFTW CMake variables different?
I think you're exactly right. Those variables are named the way they are
because when I chose those names USE_something names were all over the
place. As we've all progressed as developers and refined the conventions
used in ITK, things like that have gone away.
I see no reason not to change this to make it consistent. As far as
'backwards compatibility' -- we promise code compatibility not CMake
compatibility. Since FFTW is not on by default, someone has to go looking
when they run CMake for the FFTW variables to turn on. They'll find them
whether they're properly prefixed ITK_ or not.
And that little snippet of CMake code is something I never thought about.
CMake programming sure can be powerful. At this point we could probably
re-write ITK in CMake.
On 12/18/12 9:38 AM, Bradley Lowekamp blowek...@mail.nih.gov wrote:
Hello,
I was looking to pass some CMake variable from my SimpleITK superbuild
down to the ITK external project build. So I assembled a list for cmake
varaibles that began with ITK_:
get_cmake_property( _varNames VARIABLES )
foreach (_varName ${_varNames})
if(_varName MATCHES ^ITK_ )
message( Variable defined ${_varName}: ${${_varName}})
list(APPEND ITK_VARS ${_varName})
endif()
endforeach()
And passed to those to my ITK external project. While these ITK cmake
variables are not defined in the top level, a user could base say
-DITK_USE_SYSTEM_TIFF:BOOL=ON to the top level superbuild, and ITK
would be configured and build with this user specified option. (This will
get a lot more interesting when enabling module could also be passes.)
Only problem is that the FFTW cmake variables don't match. These are the
ones I am talking about:
USE_SYSTEM_FFTW
USE_FFTWD
USE_FFTWF
I think that these variable should begin with ITK to match the reset of
the similar variable in ITK.
Does anyone else have an opinion on this?
Thanks,
Brad
___
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://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://www.itk.org/mailman/listinfo/insight-developers
Notice: This UI Health Care e-mail (including attachments) is covered by the
Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and
may be legally privileged. If you are not the intended recipient, you are
hereby notified that any retention, dissemination, distribution, or copying of
this communication is strictly prohibited. Please reply to the sender that you
have received the message in error, then delete it. Thank you.
___
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://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://www.itk.org/mailman/listinfo/insight-developers
Re: [Insight-developers] PhilipsRecImageIO
Kent, I'd also like to point out that we have had two release candidates since this patch was merged. So the community also was not able to detect this bug since then either. Brad On Dec 18, 2012, at 10:48 AM, Williams, Norman K norman-k-willi...@uiowa.edu wrote: Mea Maxima Culpa. This was meant to fix a problem where re-use of ImageIO objects was putting metadata from one file read into the next file read. I should have caught this but like you I didn't have PHilipsRecImageIO turned on. Is there a good reason not to have this ON by default? And I'm all for making all the factory builds turn on everything that's practical to turn on. On 12/18/12 4:08 AM, m.star...@lumc.nl m.star...@lumc.nl wrote: Hi Kent, I noticed that the change 966fcb62c859229f9b421403c4faf3e6ef5e2b81 included the line: metaDict-Clear(); to the function ReadImageInformation from itkPhilipsRECImageIO.cxx. This gives a compile error: /usr/local/toolkits/ITK/latest_release/src/Modules/IO/PhilipsREC/src/itkPh ilipsRECImageIO.cxx: In member function âvirtual void itk::PhilipsRECImageIO::ReadImageInformation()â: /usr/local/toolkits/ITK/latest_release/src/Modules/IO/PhilipsREC/src/itkPh ilipsRECImageIO.cxx:744:3: error: âmetaDictâ was not declared in this scope Did you not mean: thisDic-Clear(); ? If this was not discovered at the dashboard, then probably the option Module_ITKIOPhilipsREC was not enabled. By default it is OFF. Regards, Marius Marius Staring, PhD Division of Image Processing (LKEB) Department of Radiology Leiden University Medical Center PO Box 9600, 2300 RC Leiden, The Netherlands phone: +31 (0)71 526 2137, fax: +31 (0)71 524 8256 m.star...@lumc.nl Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ___ 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://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://www.itk.org/mailman/listinfo/insight-developers ___ 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://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://www.itk.org/mailman/listinfo/insight-developers
Re: [Insight-developers] PhilipsRecImageIO
Sean, It is not on by default. Bill On Tue, Dec 18, 2012 at 11:11 AM, Sean McBride s...@rogue-research.com wrote: On Tue, 18 Dec 2012 15:48:40 +, Williams, Norman K said: I should have caught this but like you I didn't have PHilipsRecImageIO turned on. Is there a good reason not to have this ON by default? And I'm all for making all the factory builds turn on everything that's practical to turn on. I'd like to turn it on on my dashboards, as I use that code. In fact, I had assumed it was on. I have ITK_BUILD_ALL_MODULES=1, but apparently that doesn't mean what I thought... Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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://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://www.itk.org/mailman/listinfo/insight-developers -- Unpaid intern in BillsBasement at noware dot com ___ 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://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://www.itk.org/mailman/listinfo/insight-developers
Re: [Insight-developers] Why are FFTW CMake variables different?
I agree that they should follow a consistent style, but an attempt at
backwards compatibility should be made. Those variables are hard set in
many people's ExternalProject's, build scripts, etc.
Matt
On Tue, Dec 18, 2012 at 4:25 PM, Williams, Norman K
norman-k-willi...@uiowa.edu wrote:
I think you're exactly right. Those variables are named the way they are
because when I chose those names USE_something names were all over the
place. As we've all progressed as developers and refined the conventions
used in ITK, things like that have gone away.
I see no reason not to change this to make it consistent. As far as
'backwards compatibility' -- we promise code compatibility not CMake
compatibility. Since FFTW is not on by default, someone has to go looking
when they run CMake for the FFTW variables to turn on. They'll find them
whether they're properly prefixed ITK_ or not.
And that little snippet of CMake code is something I never thought about.
CMake programming sure can be powerful. At this point we could probably
re-write ITK in CMake.
On 12/18/12 9:38 AM, Bradley Lowekamp blowek...@mail.nih.gov wrote:
Hello,
I was looking to pass some CMake variable from my SimpleITK superbuild
down to the ITK external project build. So I assembled a list for cmake
varaibles that began with ITK_:
get_cmake_property( _varNames VARIABLES )
foreach (_varName ${_varNames})
if(_varName MATCHES ^ITK_ )
message( Variable defined ${_varName}: ${${_varName}})
list(APPEND ITK_VARS ${_varName})
endif()
endforeach()
And passed to those to my ITK external project. While these ITK cmake
variables are not defined in the top level, a user could base say
-DITK_USE_SYSTEM_TIFF:BOOL=ON to the top level superbuild, and ITK
would be configured and build with this user specified option. (This will
get a lot more interesting when enabling module could also be passes.)
Only problem is that the FFTW cmake variables don't match. These are the
ones I am talking about:
USE_SYSTEM_FFTW
USE_FFTWD
USE_FFTWF
I think that these variable should begin with ITK to match the reset of
the similar variable in ITK.
Does anyone else have an opinion on this?
Thanks,
Brad
___
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://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://www.itk.org/mailman/listinfo/insight-developers
Notice: This UI Health Care e-mail (including attachments) is covered by
the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
confidential and may be legally privileged. If you are not the intended
recipient, you are hereby notified that any retention, dissemination,
distribution, or copying of this communication is strictly prohibited.
Please reply to the sender that you have received the message in error,
then delete it. Thank you.
___
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://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://www.itk.org/mailman/listinfo/insight-developers
___
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://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://www.itk.org/mailman/listinfo/insight-developers
Re: [Insight-developers] Patches for 4.3.1
My gerrit patch: http://review.source.kitware.com/#/c/8951/ addresses prevention of duplicate dynamic libraries. But it need review. I'm not sure if it merits inclusion in 4.3.1. On Tue, Dec 18, 2012 at 1:42 PM, Jean-Christophe Fillion-Robin jchris.filli...@kitware.com wrote: Hi Matt, If there are any, would be great to include patches involving the ITK factory that are related to Slicer issue: #2813 Thanks Jc On Tue, Dec 18, 2012 at 1:37 PM, Matt McCormick matt.mccorm...@kitware.com wrote: Hi, I will delay sending out the release announcement until we get a 4.3.1 packaged on Friday to include the PhilipsRecImageIO patch. What other patches would we like to include? Right now, merged changes are ENH: Get the internal transforms of SyN registration filter COMP: Remove unnecessary BORLAND code COMP: Turn on -fpic in options for DCMTK External Project COMP: Fix HDF5 unused function for long long on Unix. ENH: Bump CMake version numbers to 4.4.0. Currently, what I think should be applied to 4.3.1: COMP: Remove unnecessary BORLAND code COMP: Fix HDF5 unused function for long long on Unix. Not merged yet, but should be added: BUG: Remove unused metric test content link. COMP: Fix compile error in PhilipsRECImageIO COMP: Add DLL to PATH for Python tests on Visual Studio. COMP: Make type conversions explicit/consistent I am not sure about this patch: COMP: Turn on -fpic in options for DCMTK External Project Since it is not tested on the dashboard, can we get Experimental builds on all three platforms? Thanks, Matt ___ 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://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://www.itk.org/mailman/listinfo/insight-developers -- +1 919 869 8849 ___ 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://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://www.itk.org/mailman/listinfo/insight-developers -- Unpaid intern in BillsBasement at noware dot com ___ 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://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://www.itk.org/mailman/listinfo/insight-developers
Re: [Insight-developers] [ANNOUNCEMENT] ITK-MINC Hackathon
Hi all, I have created a Google Event within the ITK BarCamp Google+ Community: https://plus.google.com/u/0/events/cb0tnl4sa36i3jh3ma1imnc922s?authkey=CKK1ktSWua3ZeQ And a Google Doc: https://docs.google.com/document/d/1i2ibaZMS_vxzLocGVeElz6t5DVF7CWHfyFrB2WldF1c/edit#heading=h.r7h4uqn8p8ld to track our progress. Looking forward to working with you all, Matt On Sat, Dec 15, 2012 at 6:26 PM, Matt McCormick matt.mccorm...@kitware.comwrote: Topics of interest in MINC. ___ 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://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://www.itk.org/mailman/listinfo/insight-developers
Re: [Insight-developers] ITKv4 / ITK Factories and CppMicroServices library
Hi Jc, Sascha, Nolden,
Thank you very much for the link and discussion! Very interesting!
The library appears to solve many issues we have been struggling with
or need to solve.
The fact that it is small, C++, Apache 2.0 licensed, compact, tightly
focused, feature-rich, and well vetted are all pluses.
I would be interested to get your opinion on the following issues:
1) Could we maintain a backwards compatible API with the ObjectFactory?
2) Would we *need* to use shared libraries? Could be maybe use some
CMake magic instead/as an alternative? Maybe it would be an option
for packages like Slicer to use the shared libraries. As it stands,
ITK can be built with all static libraries, which is a feature would
want to keep (nice for clusters, etc). Also, the only Module on
Windows that is built as a shared library is ITKCommon. I am not sure
how feasible it is to get all the IO modules to be shared
I will add it to the agenda for the Montreal, Hackathon tomorrow.
https://docs.google.com/document/d/1i2ibaZMS_vxzLocGVeElz6t5DVF7CWHfyFrB2WldF1c/edit#heading=h.r7h4uqn8p8ld
I am also CC'ing the itk-developers mailing list. There are many
smarter people than myself that may have more ideas on this ;-).
Thanks,
Matt
On Mon, Dec 17, 2012 at 6:22 PM, Jean-Christophe Fillion-Robin
jchris.filli...@kitware.com wrote:
Hi Matt,
Attending the CTK Hackfest in Bologna, I discussed with MITK folks about
their experience with the ITK (IO) Factories. While the system in place gets
the job done, they shared with me some of their concerns and helped me
redacting the following text:
Registering new overrides involves quite a lot of boilerplate code (the
object plus a factory) and the usage is non-intuitive for beginners (this
could be improved by more detailed Doxygen documentation for the
ObjectFactoryBase::RegisterOverride method and a code example.
The handling and prioritisation of multiple overrides for the same class
type is difficult. ITKv4 seems to have added a position argument to the
RegisterFactory method but the order returned by e.g. CreateAllInstance
still depends on the registration order.
Type checking must be done by the user. Object factories registered as
overrides for certain class names may return any subclass of LightObject.
Typos in the class name are hard to debug and actual class names and their
override strings may get out-of-sync.
The life-cycle of registered object factories is not communicated. While
probably not in the original scope of ITK object factories, notifications
about registered/unregistered factories at runtime would make sense for some
use cases.
While discussing, they introduced me with the cross-platform C++ library
named “CppMicroServices”[1] that could help addressing some of the
challenges encountered while using the current ITKIOFactory system.
From the website:
“The C++ Micro Services library provides a dynamic service registry based on
the service layer as specified in the OSGi R4.2 specifications. It enables
users to realize a service oriented approach within their software stack.
The advantages include higher reuse of components, looser coupling, better
organization of responsibilities, cleaner API contracts, etc.”
This is a pure C++ implementation of the OSGi service model and does not
have any third-party library dependencies.”
The idea would be to leverage this library to provide either a replacement
or an alternative system to register ITK IOPlugin. The following code
snippets show the different approaches taken by ITK and CppMicroServices for
“overriding” a class type :
General (using itk::ImageIOBase as the “interface”)
===
namespace itk {
class ImageIOBase : public LightProcessObject
{
// public interface
// ...
}
}
// The following macro allows type-safe APIs in CppMicroServices plus
// the handling of versions for evolving interfaces
US_DECLARE_SERVICE_INTERFACE(itk::ImageIOBase,
“org.itk.ImageIOBase/1.0.0”)
class MyImageIO : public itk::ImageIOBase
{
// implementation details
// ...
}
ITK
===
// usually one factory for each registered override
class MyImageIOFactory : public itk::ObjectFactoryBase
{
typedef MyImageIOFactory Self;
virtual const char* GetITKSourceVersion() const { … }
itkFactorylessNewMacro(Self);
itkTypeMacro(MyImageIOFactory, itk::ObjectFactoryBase)
static void RegisterOneFactory()
{
MyImageIOFactory::Pointer myFactory = MyImageIOFactory::New();
// Try to give it top priority
itk::ObjectFactoryBase::RegisterFactory(myFactory,
INSERT_AT_FRONT);
}
protected:
MyImageIOFactory()
{
// use strings for class names
this-RegisterOverride(“itkImageIOBase”, “MyImageIO”,
“My custom image IO”, 1,
Re: [Insight-developers] Patches for 4.3.1
You are correct. I thought was the issue we had with Slicer, that each CLI was loading run-times. What are the duplicates we saw in Slicer and is there a similar preventive measure we can take. Bill On Tue, Dec 18, 2012 at 2:35 PM, Bradley Lowekamp blowek...@mail.nih.gov wrote: Bill, If I understand your patch correctly, this only effects those libraries loaded at run-time in the ITK_AUTOLOAD_PATH? If so I don't see how this would help the issues Slicer has with loading too many factories. Brad On Dec 18, 2012, at 2:24 PM, Bill Lorensen bill.loren...@gmail.com wrote: My gerrit patch: http://review.source.kitware.com/#/c/8951/ addresses prevention of duplicate dynamic libraries. But it need review. I'm not sure if it merits inclusion in 4.3.1. On Tue, Dec 18, 2012 at 1:42 PM, Jean-Christophe Fillion-Robin jchris.filli...@kitware.com wrote: Hi Matt, If there are any, would be great to include patches involving the ITK factory that are related to Slicer issue: #2813 Thanks Jc On Tue, Dec 18, 2012 at 1:37 PM, Matt McCormick matt.mccorm...@kitware.com wrote: Hi, I will delay sending out the release announcement until we get a 4.3.1 packaged on Friday to include the PhilipsRecImageIO patch. What other patches would we like to include? Right now, merged changes are ENH: Get the internal transforms of SyN registration filter COMP: Remove unnecessary BORLAND code COMP: Turn on -fpic in options for DCMTK External Project COMP: Fix HDF5 unused function for long long on Unix. ENH: Bump CMake version numbers to 4.4.0. Currently, what I think should be applied to 4.3.1: COMP: Remove unnecessary BORLAND code COMP: Fix HDF5 unused function for long long on Unix. Not merged yet, but should be added: BUG: Remove unused metric test content link. COMP: Fix compile error in PhilipsRECImageIO COMP: Add DLL to PATH for Python tests on Visual Studio. COMP: Make type conversions explicit/consistent I am not sure about this patch: COMP: Turn on -fpic in options for DCMTK External Project Since it is not tested on the dashboard, can we get Experimental builds on all three platforms? Thanks, Matt ___ 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://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://www.itk.org/mailman/listinfo/insight-developers -- +1 919 869 8849 ___ 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://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://www.itk.org/mailman/listinfo/insight-developers -- Unpaid intern in BillsBasement at noware dot com ___ 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://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://www.itk.org/mailman/listinfo/insight-developers -- Unpaid intern in BillsBasement at noware dot com ___ 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://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://www.itk.org/mailman/listinfo/insight-developers
Re: [Insight-developers] PhilipsRecImageIO
Bill, Indeed. But what I meant is that the name ITK_BUILD_ALL_MODULES is rather deceptive (reminds me of -Wall). Perhaps it should be named ITK_BUILD_MOST_MODULES or ITK_BUILD_COMMON_MODULES is what I was getting at. Sean On Tue, 18 Dec 2012 12:02:38 -0500, Bill Lorensen said: Sean, It is not on by default. Bill On Tue, Dec 18, 2012 at 11:11 AM, Sean McBride s...@rogue-research.com wrote: On Tue, 18 Dec 2012 15:48:40 +, Williams, Norman K said: I should have caught this but like you I didn't have PHilipsRecImageIO turned on. Is there a good reason not to have this ON by default? And I'm all for making all the factory builds turn on everything that's practical to turn on. I'd like to turn it on on my dashboards, as I use that code. In fact, I had assumed it was on. I have ITK_BUILD_ALL_MODULES=1, but apparently that doesn't mean what I thought... ___ 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://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://www.itk.org/mailman/listinfo/insight-developers
Re: [Insight-developers] PhilipsRecImageIO
Maybe it should be BUILD_DEFAULT_MODULES? I agree that BUILD_ALL_MODULES is deceptive. On Tue, Dec 18, 2012 at 5:13 PM, Sean McBride s...@rogue-research.com wrote: Bill, Indeed. But what I meant is that the name ITK_BUILD_ALL_MODULES is rather deceptive (reminds me of -Wall). Perhaps it should be named ITK_BUILD_MOST_MODULES or ITK_BUILD_COMMON_MODULES is what I was getting at. Sean On Tue, 18 Dec 2012 12:02:38 -0500, Bill Lorensen said: Sean, It is not on by default. Bill On Tue, Dec 18, 2012 at 11:11 AM, Sean McBride s...@rogue-research.com wrote: On Tue, 18 Dec 2012 15:48:40 +, Williams, Norman K said: I should have caught this but like you I didn't have PHilipsRecImageIO turned on. Is there a good reason not to have this ON by default? And I'm all for making all the factory builds turn on everything that's practical to turn on. I'd like to turn it on on my dashboards, as I use that code. In fact, I had assumed it was on. I have ITK_BUILD_ALL_MODULES=1, but apparently that doesn't mean what I thought... -- Unpaid intern in BillsBasement at noware dot com ___ 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://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://www.itk.org/mailman/listinfo/insight-developers
Re: [Insight-developers] PhilipsRecImageIO
BUILD_ALL_MODULES really has turned into just the defaults ones and I am not sure that is should change much. What is really needed is to turn everything on for dashboards and robots. I wonder if we could use a new variable... say BUILD_ALL (similar to BUILD_TESTING, BUILD_EXAMPLES etc..), but not have it in the cache so it's no it's not exposed to users. It could be defined, in the common nightly build script, or individual build scripts. If this variable is defined it could be used as the default to turn on most options and modules. This would make it so that people would have to turn off features on the dashboard instead of enabling them ie turn off GPU or MINC or what not... Just a brainstorming thought... Brad On Dec 18, 2012, at 6:28 PM, Bill Lorensen bill.loren...@gmail.com wrote: Maybe it should be BUILD_DEFAULT_MODULES? I agree that BUILD_ALL_MODULES is deceptive. On Tue, Dec 18, 2012 at 5:13 PM, Sean McBride s...@rogue-research.com wrote: Bill, Indeed. But what I meant is that the name ITK_BUILD_ALL_MODULES is rather deceptive (reminds me of -Wall). Perhaps it should be named ITK_BUILD_MOST_MODULES or ITK_BUILD_COMMON_MODULES is what I was getting at. Sean On Tue, 18 Dec 2012 12:02:38 -0500, Bill Lorensen said: Sean, It is not on by default. Bill On Tue, Dec 18, 2012 at 11:11 AM, Sean McBride s...@rogue-research.com wrote: On Tue, 18 Dec 2012 15:48:40 +, Williams, Norman K said: I should have caught this but like you I didn't have PHilipsRecImageIO turned on. Is there a good reason not to have this ON by default? And I'm all for making all the factory builds turn on everything that's practical to turn on. I'd like to turn it on on my dashboards, as I use that code. In fact, I had assumed it was on. I have ITK_BUILD_ALL_MODULES=1, but apparently that doesn't mean what I thought... -- Unpaid intern in BillsBasement at noware dot com ___ 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://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://www.itk.org/mailman/listinfo/insight-developers ___ 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://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://www.itk.org/mailman/listinfo/insight-developers
Re: [Insight-developers] PhilipsRecImageIO
+1 to renaming BUILD_ALL_MODULES to BUILD_DEFAULT_MODULES for clarity. +1 to an unexposed BUILD_ALL variable that is enabled for all dashboard builds. I think we should also then turn BUILD_TESTING and BUILD_EXAMPLES OFF by default. A bad impression is made on many beginners by the time a stock build takes. Matt On Tue, Dec 18, 2012 at 8:26 PM, Bradley Lowekamp blowek...@mail.nih.gov wrote: BUILD_ALL_MODULES really has turned into just the defaults ones and I am not sure that is should change much. What is really needed is to turn everything on for dashboards and robots. I wonder if we could use a new variable... say BUILD_ALL (similar to BUILD_TESTING, BUILD_EXAMPLES etc..), but not have it in the cache so it's no it's not exposed to users. It could be defined, in the common nightly build script, or individual build scripts. If this variable is defined it could be used as the default to turn on most options and modules. This would make it so that people would have to turn off features on the dashboard instead of enabling them ie turn off GPU or MINC or what not... Just a brainstorming thought... Brad On Dec 18, 2012, at 6:28 PM, Bill Lorensen bill.loren...@gmail.com wrote: Maybe it should be BUILD_DEFAULT_MODULES? I agree that BUILD_ALL_MODULES is deceptive. On Tue, Dec 18, 2012 at 5:13 PM, Sean McBride s...@rogue-research.com wrote: Bill, Indeed. But what I meant is that the name ITK_BUILD_ALL_MODULES is rather deceptive (reminds me of -Wall). Perhaps it should be named ITK_BUILD_MOST_MODULES or ITK_BUILD_COMMON_MODULES is what I was getting at. Sean On Tue, 18 Dec 2012 12:02:38 -0500, Bill Lorensen said: Sean, It is not on by default. Bill On Tue, Dec 18, 2012 at 11:11 AM, Sean McBride s...@rogue-research.com wrote: On Tue, 18 Dec 2012 15:48:40 +, Williams, Norman K said: I should have caught this but like you I didn't have PHilipsRecImageIO turned on. Is there a good reason not to have this ON by default? And I'm all for making all the factory builds turn on everything that's practical to turn on. I'd like to turn it on on my dashboards, as I use that code. In fact, I had assumed it was on. I have ITK_BUILD_ALL_MODULES=1, but apparently that doesn't mean what I thought... -- Unpaid intern in BillsBasement at noware dot com ___ 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://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://www.itk.org/mailman/listinfo/insight-developers ___ 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://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://www.itk.org/mailman/listinfo/insight-developers ___ 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://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://www.itk.org/mailman/listinfo/insight-developers
Re: [Insight-developers] ITKv4 / ITK Factories and CppMicroServices library
Thanks for the feedback, Sascha. Forwarding to insight-developers... On Tue, Dec 18, 2012 at 6:38 PM, Sascha Zelzer s.zel...@dkfz-heidelberg.de wrote: Hi Matt, please see my comments inline. On 12/18/2012 09:10 PM, Matt McCormick wrote: I would be interested to get your opinion on the following issues: 1) Could we maintain a backwards compatible API with the ObjectFactory? Without having thought about all the details yet, I would say yes. The implementation of the itk::ObjectFactoryBase class could probably be modified to register and use corresponding services internally. But to make sure, we would have to prototype something. 2) Would we *need* to use shared libraries? Could be maybe use some CMake magic instead/as an alternative? Maybe it would be an option for packages like Slicer to use the shared libraries. As it stands, ITK can be built with all static libraries, which is a feature would want to keep (nice for clusters, etc). Also, the only Module on Windows that is built as a shared library is ITKCommon. I am not sure how feasible it is to get all the IO modules to be shared The CppMicroServices library explicitly supports static modules, see http://cppmicroservices.org/doc_latest/MicroServices_StaticModules.html. I will add it to the agenda for the Montreal, Hackathon tomorrow. https://docs.google.com/document/d/1i2ibaZMS_vxzLocGVeElz6t5DVF7CWHfyFrB2WldF1c/edit#heading=h.r7h4uqn8p8ld Great, we are very interested about the feedback. I would also be available on Google Chat (sascha.zel...@gmail.com) tomorrow for potential questions during the Hackathon. Here is some more background information about the library itself: As Jc said, the API of the library is considered stable and there is only one small feature missing which we want to get in before doing a 1.0 release. The planned feature is a very lightweight resources system allowing users to embed arbitrary resources into a module (similar to the Qt resource system but lighter) and retrieve the resource as an std::ostream object via a convenient API. After the 1.0 release, I plan to make the API even more compile-time type-checking friendly and remove the requirement of a common base class for service objects. This would then be version 2.0 and should be finished around March next year. I am also CC'ing the itk-developers mailing list. There are many smarter people than myself that may have more ideas on this ;-). Thanks for your input! I kept the itk-developers list as CC but it will probably not arrive without a subscription. Please feel free to forward it if you think it is of general interest. Best, Sascha Thanks, Matt On Mon, Dec 17, 2012 at 6:22 PM, Jean-Christophe Fillion-Robin jchris.filli...@kitware.com wrote: Hi Matt, Attending the CTK Hackfest in Bologna, I discussed with MITK folks about their experience with the ITK (IO) Factories. While the system in place gets the job done, they shared with me some of their concerns and helped me redacting the following text: Registering new overrides involves quite a lot of boilerplate code (the object plus a factory) and the usage is non-intuitive for beginners (this could be improved by more detailed Doxygen documentation for the ObjectFactoryBase::RegisterOverride method and a code example. The handling and prioritisation of multiple overrides for the same class type is difficult. ITKv4 seems to have added a position argument to the RegisterFactory method but the order returned by e.g. CreateAllInstance still depends on the registration order. Type checking must be done by the user. Object factories registered as overrides for certain class names may return any subclass of LightObject. Typos in the class name are hard to debug and actual class names and their override strings may get out-of-sync. The life-cycle of registered object factories is not communicated. While probably not in the original scope of ITK object factories, notifications about registered/unregistered factories at runtime would make sense for some use cases. While discussing, they introduced me with the cross-platform C++ library named “CppMicroServices”[1] that could help addressing some of the challenges encountered while using the current ITKIOFactory system. From the website: “The C++ Micro Services library provides a dynamic service registry based on the service layer as specified in the OSGi R4.2 specifications. It enables users to realize a service oriented approach within their software stack. The advantages include higher reuse of components, looser coupling, better organization of responsibilities, cleaner API contracts, etc.” This is a pure C++ implementation of the OSGi service model and does not have any third-party library dependencies.” The idea would be to leverage this library to provide either a replacement or an alternative system to register ITK IOPlugin. The following
