Answers inline...
> - which version of oiio would you recommend starting the development of the
> plugins with ? FYI, my Debian machine has got version 1.5.16 currently.
If you need OIIO "as is" and all the coding is on your end, then whatever is
the most recent tag in the RB-1.5 branch will be good.
But if you think you will make modifications on the OIIO side, then you might
want to work against the current master, since that's where new development
goes. Then, when you are ready to "ship" a stable version of your software, you
can lock off on a particular OIIO release (including backporting your fixes to
1.5, if it isn't something that would break backwards compatibility.
> - it seems that oiio does not ship with any mechanism for allowing easy
> detection in CMake (via a find module or a cmake config), unless I am missing
> something. Do you then recommend performing the development of the plugins
> from within an oiio fork ?
If you want to contribute the plugins back to the OIIO project, I recommend
that you develop them from within an oiio fork. But if you wish to keep them
entirely in your project, then you'll want the cmake code to find the OIIO
installation.
We don't ship with a canonical FindOpenImageIO.cmake but we should!
At the end of this email, I'm putting some cmake lines that I have from another
project, which finds OIIO. It works, but I admit that it's probably not super
robust and in the style of a standard cmake FindBlah file. If anybody reading
this is enough of a cmake guru to construct a proper FindOpenImageIO.cmake, I
would love to include it with OIIO. (Also, WHERE exactly in our distro is the
right place to put it?)
> - is there an existing plugin you recommend to use as a good, modern template
> for getting started, besides the JPEG one which is in the documentation ?
In the docs, JPEG is used because it's fairly simple. But it's not one I use as
a template for starting a new format.
I'm not intimately familiar with any of the three formats you mentioned, so I'm
not sure which of our formats would be the closest match in features. My very
quick web search of the formats you mentioned indicate that they are all geared
toward 3D biomedical data.
I'm not sure there's any single one that's best.
TIFF is fairly comprehensive, especially because it supports many data types
and arbitrary numbers of data channels, has provisions for 3D data, and
supports multiple subimages in a file. But it's also so feature-rich that it's
about as complex as things can get. DPX may also be good to look at (but don't
worry much about the stuff in libdpx, which is to read the raw files
themselves).
Field3D may be helpful because it's a 3D volumetric format.
Do you plan to write the whole thing from scratch (like we did for FITS)? Or
are you relying on existing libraries to read the data from the file, and are
then mainly "wrapping" the function of those libraries in the OIIO API (as we
do for libtiff or libjpeg)?
---- Example cmake code to find OpenImageIO ---
# If 'OPENIMAGEHOME' not set, use the env variable of that name if available
if (NOT OPENIMAGEIOHOME)
if (NOT $ENV{OPENIMAGEIOHOME} STREQUAL "")
set (OPENIMAGEIOHOME $ENV{OPENIMAGEIOHOME})
endif ()
endif ()
if (NOT OpenImageIO_FIND_QUIETLY)
MESSAGE ( STATUS "OPENIMAGEIOHOME = ${OPENIMAGEIOHOME}" )
endif ()
find_library ( OPENIMAGEIO_LIBRARY
NAMES OpenImageIO
HINTS ${OPENIMAGEIOHOME}
PATH_SUFFIXES lib64 lib
PATHS "${OPENIMAGEIOHOME}/lib" )
find_path ( OPENIMAGEIO_INCLUDES
NAMES OpenImageIO/imageio.h
HINTS ${OPENIMAGEIOHOME}
PATH_SUFFIXES include )
IF (OPENIMAGEIO_INCLUDES AND OPENIMAGEIO_LIBRARY )
SET ( OPENIMAGEIO_FOUND TRUE )
if (NOT OpenImageIO_FIND_QUIETLY)
MESSAGE ( STATUS "OpenImageIO includes = ${OPENIMAGEIO_INCLUDES}" )
MESSAGE ( STATUS "OpenImageIO library = ${OPENIMAGEIO_LIBRARY}" )
endif ()
ELSE ()
MESSAGE ( FATAL_ERROR "OpenImageIO not found" )
ENDIF ()
---
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
