On 20/07/15 19:15, [email protected] wrote:
On Jul 20, 2015, at 4:11 AM, Ghislain Vaillant<[email protected]> wrote:
>
>I have used the find module from the Blender project initially. Ideally, since
this is a CMake project, a CMake config exporting the right targets and macros
would be much more helpful.
Oh, that's a good idea. They are GPL, I think, so the license doesn't allow me
to incorporate it into our project directly. But maybe it will inspire me to
cook up one of my own using its layout as guidance.
Better idea would be to ship a cmake project config [1]. Then,
find_package would be handled transparently, and you can provide the
helper macros to add a new oiio plugin and test suite additionally.
>GIPL will be written from scratch, since no official library was written for
it. There is a reasonably well working MATLAB implementation that illustrates how
the format works.
>
>Nifti has an official library that I plan to use.
>
>Not sure about ANALYZE. Will have to do further research on that one.
As with the existing plugins, I recommend that any time the dependent library
is not found, that OIIO simply skips building support for that format, rather
than being a fatal build break. These aren't common formats for OIIO's main
user base, so I want it to be completely painless for them to build OIIO
without these libraries being installed.
Will do.
But I do think it's cool for OIIO's format support to extend to those used for
medical imaging.
And there are a lot of them.
Just to fill the rest of us in, how are these three formats used? I mean, under
what circumstances is one chosen over another, and/or why any of them over
DICOM?
GIPL, ANALYZE, Nifti and many more exists because no standardization
exists to express medical data in a relatively *simple* format.
DICOM is supposed to be that standard, but has been often considered too
complicated to deal with. So much, that different research institutions
and commercial vendors proposed their respective format.
Whether to use one over the other depends on which product / software
you are planning to use down the pipeline.
Do you think it would be helpful for us to also have direct support for DICOM
images?
For use in biomedical applications, it would be tremendous. DICOM is
infamous for being difficult to deal with right. Perhaps these recent
C++ wrappers [2] will improve things.
Meanwhile and a proper abstraction using the OIIO primitives would
definitely be appealing, at least for us.
[1]
http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file
[2] https://github.com/lamyj/dcmtkpp/tree/master
Best regards,
Ghislain
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
