Open thewtex opened 9 years ago
@ctrueden
@thewtex , @bnorthan , @ctrueden , @tischi
Not sure what improvements you all had in mind, and that link is broken (no judgement, its been 4 years, I know).
I wasn't crazy about the fact that the repo as it is copies data, so started work on an in-memory imglib2 wrapper of itk images (accessible by SimpleITK).
Still early, but feedback most welcome.
Hi @bogovicj
This looks great. Thank you for picking up this project. One quick question have you done any performance testing on accessing and/or looping and modifying the wrapped ItkImageImg
vs a copied Img
?? Is there any overhead with the wrappers??
have you done any performance testing on accessing and/or looping and modifying the wrapped ItkImageImg vs a copied Img
Not yet
Is there any overhead with the wrappers??
Probably. Though there are improvements possible if we could get access to a lower level of storage. e.g. if it's the case that itk stores the image as a flat array, then working with that directly ( see imglib2-unsafe) would be better than the current state of affairs.
Yes, but I think the higher level API, even if slow, is really nice because it should work for many cases. So I would keep that for sure and implement something faster as an independent version, so the user could choose between safe
or fast
.
I feel like working with a flat native array directly would be ideal, then you could use it for both ITK, and other native code. However I don't know what guarantees ITK makes about the memory layout of the native array.
@bogovicj thanks for working on this!
. if it's the case that itk stores the image as a flat array
This is true.
Hi all, We are Fijiyama developers (registration plugin for Fij). The plugin involves a lot of conversion between ImageJ and Itk Image, and we found out that the old version of Simple ITK libs does not release the accessibility capacity to the Itk Image array of data. Thus we work on a circumvent of this, but that require a more recent version of simple itk, like the last ones (2..), see
https://github.com/SimpleITK/SimpleITK/issues/2110
However if we start working on this, that means that we should ship Fijiyama plugin on an installation including a recent version of simple itk. And we guess that there could be other plugin that rely on simple itk, and that changing the version of simple itk can have side-effect.
Could we discuss a bit this point ? Can you share a vision about this ?
See you !
Romain & Loai
More in the SimpleITK issue tracker: https://issues.itk.org/jira/browse/SIMPLEITK-40