[ocs-dev] OCS v0.5.5 posted


Jeremy Selan <jeremy...@...>
 

The use of tr1 shared_ptr is only a stub. When we get multi-platform
stuff sorted out that section will definitely be replaced with
platform / compiler specific #ifdefs. Any shared_ptr that provides a
dynamic_cast will suffice. (tr1 does work on osx already though :) )

First a justification of shared_ptrs in general...
We've spend a long time thinking about object ownership and object
lifetimes, and the choice to expose a smart pointer was not arrived at
lightly. I do not see a graceful alternative. If people are
interested we should probably discuss this further to bring everyone
on board. (Or to prove me wrong!) The quick summary is that in the
context of multi-threaded apps, where there exists a 'global' config
people can get/set, you need to have some form of reference counting
to assure that configs aren't destroyed while still in use. I would
have ended up just re inventing a shared_ptr / intrusive_ptr, so it
seemed expedient to just use a real one. It will also allow for a
more simper python use model, as objects can now be created on either
side of the fence (C++ or python) and passed back and forth without
concern for object lifetime. (Keeping a reference to the python
object will keep the C++ object alive, which is very desirable). This
will particularly be useful in python UIs that make use of the mutable
API. (To create and edit configs 'live')

One related thing of note - all exposed objects which use shared-ptrs
have private constructors; the only way to create them is with static
factory functions. Example: ColorSpaceRcPtr ColorSpace::Create() .
This is done so that the shared pointer is always created with a
custom object deallocator. Our hope is this will work solve the
windows dll memory management issue. (And we hope to verify this
soon).

OCS::ImageDesc
The init functions could definitely be constructors. My concerns is
that it would then rely on type signatures to maintain uniqueness, and
this has hosed me in the past. (Particularly where default values /
int / bools are involved). You can accidentally create a change which
is binary compatible, but not source compatible.

I really like having super explicit names such as initRGBA,
initSingleBuffer, initMultiBuffer. This will also let us add new
convenience constructors should they be desired without worrying about
compatibility. (Consider 'initRGB', which would have the same type
signature as initRGBA.

But I agree the current init functions aren't ideal. Does anyone have ideas?


Soon enough we will have a live share of the GIT repo, and which point
everyone can start contributing... ;)

-- Jeremy


On Fri, Jun 4, 2010 at 4:09 AM, Bruno Nicoletti
<bruno.j....@googlemail.com> wrote:
Hi Jeremy,

looking much nicer. However, I have The Fear as you are using C++ TR1
for smart pointer magic. We are on Visual Studio 2005 for Windows and
there is no TR1 for VS5 (we won't be changing in the near future, long
story). A #ifndef around SharedPtr and DynamicPtrCast would help, as
we could redirect this to boost.

Another minor quibble, should not the OCS::ImageDesc have ctors rather
than the initRGBA/initSingleBuffer/initMultiBuffer methods? Similarly
for other classes?

b

On 4 June 2010 00:44, Jeremy Selan <jeremy...@gmail.com> wrote:
This one will actually build on other people's machines...

please see INSTALL file for instructions on how to build the Nuke
example (posted here as well):

Make a build directory, cd into it:
mkdir -p build
cd build
Configure cmake, pointing at your nuke include dir:
cmake -D NUKE:FILEPATH=/usr/local/nuke6.0.3/include/ -D CMAKE_BUILD_TYPE=Release ../
Build all targets:
make
You will now see the built .so files:
ls
Set the environment variable pointing at which configuration to use:
(Point this to your install)
setenv OCS /net/homedirs/jeremys/git/Color/configs/spivfx/config.ocs
Launch nuke (the same version you used for the include files), then
load the plugin (this can also go in your init.py)

nuke.load('/net/homedirs/jeremys/git/Color//build/libNukeColorSpaceConversion.so')
nuke.menu('Nodes').addMenu('Color').addCommand('OCSColorSpaceConversion', 'nuke.createNode("OCSColorSpaceConversion")')
Connect an image to the OCSColorSpaceConversion node.
Our 'spivfx' config has only a few example colorspaces, this one
demonstrates a conversion between scene linear and a film-log
colorspace.


--
Bruno Nicoletti


Bruno Nicoletti <bruno.j....@...>
 

Hi Jeremy,

thanks for the reply. I'm a firm believer in smart pointers, choosing
what to expose can be problematic in an API like this when there is no
firm standard. #ifndefs is the way around it.

As for the ctors, derive thin classes from the base one, which have
nothing but ctors in them.

class PackedImageDesc : public ImageDesc {
public : PackedImageDesc(....);
};

class PlanarImageDesc : public ImageDesc {
public : PlanarImageDesc(....);
};

All you functions should take const references to ImageDesc, and it
will all work happily.

That should do it.

On 4 June 2010 16:41, Jeremy Selan <jeremy...@gmail.com> wrote:
The use of tr1 shared_ptr is only a stub.  When we get multi-platform
stuff sorted out that section will definitely be replaced with
platform / compiler specific #ifdefs. Any shared_ptr that provides a
dynamic_cast will suffice. (tr1 does work on osx already though  :) )

First a justification of shared_ptrs in general...
We've spend a long time thinking about object ownership and object
lifetimes, and the choice to expose a smart pointer was not arrived at
lightly.  I do not see a graceful alternative.  If people are
interested we should probably discuss this further to bring everyone
on board.  (Or to prove me wrong!)  The quick summary is that in the
context of multi-threaded apps, where there exists a 'global' config
people can get/set, you need to have some form of reference counting
to assure that configs aren't destroyed while still in use.   I would
have ended up just re inventing a shared_ptr / intrusive_ptr, so it
seemed expedient to just use a real one.  It will also allow for a
more simper python use model, as objects can now be created on either
side of the fence (C++ or python) and passed back and forth without
concern for object lifetime.  (Keeping a reference to the python
object will keep the C++ object alive, which is very desirable). This
will particularly be useful in python UIs that make use of the mutable
API. (To create and edit configs 'live')

One related thing of note - all exposed objects which use shared-ptrs
have private constructors; the only way to create them is with static
factory functions.   Example: ColorSpaceRcPtr ColorSpace::Create() .
This is done so that the shared pointer is always created with a
custom object deallocator.  Our hope is this will work solve the
windows dll memory management issue.  (And we hope to verify this
soon).

OCS::ImageDesc
The init functions could definitely be constructors. My concerns is
that it would then rely on type signatures to maintain uniqueness, and
this has hosed me in the past. (Particularly where default values /
int / bools are involved).  You can accidentally create a change which
is binary compatible, but not source compatible.

I really like having super explicit names such as initRGBA,
initSingleBuffer, initMultiBuffer.  This will also let us add new
convenience constructors should they be desired without worrying about
compatibility.   (Consider 'initRGB', which would have the same type
signature as initRGBA.

But I agree the current init functions aren't ideal.  Does anyone have ideas?


Soon enough we will have a live share of the GIT repo, and which point
everyone can start contributing... ;)

-- Jeremy


On Fri, Jun 4, 2010 at 4:09 AM, Bruno Nicoletti
<bruno.j....@googlemail.com> wrote:
Hi Jeremy,

looking much nicer. However, I have The Fear as you are using C++ TR1
for smart pointer magic. We are on Visual Studio 2005 for Windows and
there is no TR1 for VS5 (we won't be changing in the near future, long
story). A #ifndef around SharedPtr and DynamicPtrCast would help, as
we could redirect this to boost.

Another minor quibble, should not the OCS::ImageDesc have ctors rather
than the initRGBA/initSingleBuffer/initMultiBuffer methods? Similarly
for other classes?

b

On 4 June 2010 00:44, Jeremy Selan <jeremy...@gmail.com> wrote:
This one will actually build on other people's machines...

please see INSTALL file for instructions on how to build the Nuke
example (posted here as well):

Make a build directory, cd into it:
mkdir -p build
cd build
Configure cmake, pointing at your nuke include dir:
cmake -D NUKE:FILEPATH=/usr/local/nuke6.0.3/include/ -D CMAKE_BUILD_TYPE=Release ../
Build all targets:
make
You will now see the built .so files:
ls
Set the environment variable pointing at which configuration to use:
(Point this to your install)
setenv OCS /net/homedirs/jeremys/git/Color/configs/spivfx/config.ocs
Launch nuke (the same version you used for the include files), then
load the plugin (this can also go in your init.py)

nuke.load('/net/homedirs/jeremys/git/Color//build/libNukeColorSpaceConversion.so')
nuke.menu('Nodes').addMenu('Color').addCommand('OCSColorSpaceConversion', 'nuke.createNode("OCSColorSpaceConversion")')
Connect an image to the OCSColorSpaceConversion node.
Our 'spivfx' config has only a few example colorspaces, this one
demonstrates a conversion between scene linear and a film-log
colorspace.


--
Bruno Nicoletti
--
Bruno Nicoletti