Date   

Re: Review: nuke ociolooktransform gets reload button

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

Yup, OCIOFileTransform has a reload button.  And it works in my testing.  Please let me know if you see otherwise?

-- Jeremy


On Tue, Mar 13, 2012 at 5:50 AM, Hugh Macdonald <hugh.ma...@...> wrote:
I'm not sure if it's already in there, but could (and sure, I know, I could do it myself, and will if nobody else does) OCIOFileTransform get a Reload button too? At the moment, it seems to cache the file, so when I'm testing a LUT, I can't keep overwriting the same one and getting OCIOFileTransform to reload the same file.

Hugh Macdonald
nvizibleVISUAL EFFECTS

hugh.ma...@...
+44(0) 20 3167 3860
+44(0) 7773 764 708

www.nvizible.com


Re: Review: nuke ociolooktransform gets reload button

Hugh Macdonald <hugh.ma...@...>
 

I'm not sure if it's already in there, but could (and sure, I know, I could do it myself, and will if nobody else does) OCIOFileTransform get a Reload button too? At the moment, it seems to cache the file, so when I'm testing a LUT, I can't keep overwriting the same one and getting OCIOFileTransform to reload the same file.

Hugh Macdonald
nvizibleVISUAL EFFECTS

hugh.ma...@...
+44(0) 20 3167 3860
+44(0) 7773 764 708

www.nvizible.com

On 12/03/12 23:43, Jeremy Selan wrote:


Review: nuke ociolooktransform gets reload button

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


Review: adds 'best' interpolation type

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


OCIO in CryEngine?

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

Cinema sandbox apparently includes OpenColorIO support.

http://mycryengine.com/index.php?conid=59

I wonder if they've just pulled out our lut reading code, or have full blown $OCIO profile support...

Anyone know more about the integration?

-- Jeremy


Re: OCIO + TuttleOFX

Est <rame...@...>
 

About the OFXizations of OCIO nodes, I had a chat with Esteban, the dev of
Ramen. He tried to do so but finally decided to support OCIO directly in
his app especially because it's not easy to update dynamically and to
detect user OCIO config change with OFX.
But the dynamic parameter creation is discussed for the 2.0 of OFX (cf 2.0
draft<http://openeffects.org/dokuwiki/doku.php?id=standards:draft:ofx_image...>
).
Till then, there's some more-or-less-cute workarounds like using secret
strings (something Esteban tested) or a python script to create the node on
the fly...
If I remember correctly, my biggest issue was on nodes that have two
dependent menus, like OCIODisplay. I didn't found a way to pick an
item in a popup menu and rebuild another one, based on the element
first picked. "Knobs" on OFX are static. My best solution, was to
flatten
all posibilities into a single menu. It wasn't nice. On top of that
popups on OFX
are internally ints. I had secret string params to save the actual
ocio data
and keep it in sync. In the end, I decided it was faster and better to
do a more
direct integration.

Est.


Re: Got Lut Formats?

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

Brainstorming here,

Once this round of internal op optimizations are complete, it may be time to thinking about a simple external OCIO API to allow for 3rd party image processing to plug into OCIO.  This would allow libraries with complex linking requirements to be integrated into OCIO in a manner where 3rd party vendors wouldnt have to worry about the build details.

Formats that would seem particularly well suited to this integration route include:
- Truelight (using the native Truelight library, not the baked 3d lut format)
- ICC
- CTL

For simple transform that dont require pulling in more than a file or two of code, I'd of course prefer to have it all built-in and dependency free.

-- Jeremy


On Thu, Feb 23, 2012 at 2:02 PM, dbr/Ben <dbr....@...> wrote:
A CTLTransform would be great!

There's a few tickets about formats:

https://github.com/imageworks/OpenColorIO/issues/179 (1D Flame lut)

https://github.com/imageworks/OpenColorIO/issues/145 (CMS format for FilmMaster)

https://github.com/imageworks/OpenColorIO/pull/87 (ICC, although this is less straight forward)

On 24/02/2012, at 6:32, Jeremy Selan <jeremy...@...> wrote:

> Are there color transform / LUT formats you use that aren't supported by OCIO?
>
> It's easy to add them if you let us know!  (hint, hint)
> These can even be internal formats that don't leave your building (as long as you provide example files and reference images).
>
> Currently Supported formats:
> Autodesk 3dl
> ASC CDL (cc,ccc)
> Cinespace csp
> Truelight cub
> Iridas cube
> Houdini hdl
> Pandora mga m3d
> Imageworks spi1d spi3d spimtx
> Inventor vf
>
> (And we're looking at adding runtime .ctl support already).
>
> -- Jeremy


Re: Got Lut Formats?

dbr/Ben <dbr....@...>
 

A CTLTransform would be great!

There's a few tickets about formats:

https://github.com/imageworks/OpenColorIO/issues/179 (1D Flame lut)

https://github.com/imageworks/OpenColorIO/issues/145 (CMS format for FilmMaster)

https://github.com/imageworks/OpenColorIO/pull/87 (ICC, although this is less straight forward)

On 24/02/2012, at 6:32, Jeremy Selan <jeremy...@...> wrote:

Are there color transform / LUT formats you use that aren't supported by OCIO?

It's easy to add them if you let us know! (hint, hint)
These can even be internal formats that don't leave your building (as long as you provide example files and reference images).

Currently Supported formats:
Autodesk 3dl
ASC CDL (cc,ccc)
Cinespace csp
Truelight cub
Iridas cube
Houdini hdl
Pandora mga m3d
Imageworks spi1d spi3d spimtx
Inventor vf

(And we're looking at adding runtime .ctl support already).

-- Jeremy


Re: Got Lut Formats?

Aaron Weintraub <aaw...@...>
 

Has anybody cracked the Red metadata format (rmd) yet?  I've only just got it working in our pipeline (though not in OCIO), but really just barely.  It would be great to have a proper implementation.

-A

On 02/23/2012 04:10 PM, Jeremy Selan wrote:

From an anonymous reply...

> - da Vinci resolve (dat)
> - Autodesk 1D luts (in particular, the 16bit floating point lut)



On Thu, Feb 23, 2012 at 12:02 PM, Jeremy Selan <jeremy...@...> wrote:
Are there color transform / LUT formats you use that aren't supported by OCIO?

It's easy to add them if you let us know!  (hint, hint)
These can even be internal formats that don't leave your building (as long as you provide example files and reference images).

Currently Supported formats:
Autodesk 3dl
ASC CDL (cc,ccc)
Cinespace csp
Truelight cub
Iridas cube
Houdini hdl
Pandora mga m3d
Imageworks spi1d spi3d spimtx
Inventor vf

(And we're looking at adding runtime .ctl support already).

-- Jeremy


Re: Got Lut Formats?

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

From an anonymous reply...

> - da Vinci resolve (dat)
> - Autodesk 1D luts (in particular, the 16bit floating point lut)



On Thu, Feb 23, 2012 at 12:02 PM, Jeremy Selan <jeremy...@...> wrote:
Are there color transform / LUT formats you use that aren't supported by OCIO?

It's easy to add them if you let us know!  (hint, hint)
These can even be internal formats that don't leave your building (as long as you provide example files and reference images).

Currently Supported formats:
Autodesk 3dl
ASC CDL (cc,ccc)
Cinespace csp
Truelight cub
Iridas cube
Houdini hdl
Pandora mga m3d
Imageworks spi1d spi3d spimtx
Inventor vf

(And we're looking at adding runtime .ctl support already).

-- Jeremy


Got Lut Formats?

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

Are there color transform / LUT formats you use that aren't supported by OCIO?

It's easy to add them if you let us know!  (hint, hint)
These can even be internal formats that don't leave your building (as long as you provide example files and reference images).

Currently Supported formats:
Autodesk 3dl
ASC CDL (cc,ccc)
Cinespace csp
Truelight cub
Iridas cube
Houdini hdl
Pandora mga m3d
Imageworks spi1d spi3d spimtx
Inventor vf

(And we're looking at adding runtime .ctl support already).

-- Jeremy


Re: OCIO + TuttleOFX

Marie Fétiveau <m...@...>
 

Yes, as Bruno told, there are many tools in which it will be appreciable to have OFX ocio nodes... like Scratch too :) 

OK, that's a good option to let Tuttle's plugs mature.
And I don't think that TuttleOCIOLut is really interesting for you (it's just a VectorField node). It was for us because the old Tuttle LUT node only accepted 3DL formats.
However it shouldn't be difficult to keep this node very close to the mainline OFX (I'll test).
(Would someone be interested by a binary version of TuttleOCIOLut ?)

About the OFXizations of OCIO nodes, I had a chat with Esteban, the dev of Ramen. He tried to do so but finally decided to support OCIO directly in his app especially because it's not easy to update dynamically and to detect user OCIO config change with OFX.
But the dynamic parameter creation is discussed for the 2.0 of OFX (cf 2.0 draft).
Till then, there's some more-or-less-cute workarounds like using secret strings (something Esteban tested) or a python script to create the node on the fly...

I'm very interested in making an OFX OCIOColorspace node but for the moment making a RC of Tuttle is priority :p


On Thu, Feb 23, 2012 at 2:54 AM, Jeremy Selan <jeremy...@...> wrote:
Hmm... That makes things interesting.  I'd love to get OCIO support (even in a limited form) in these apps.

Is anyone on this list interested in compiling / testing an OFX plugin version of OCIO?

-- Jeremy


On Wed, Feb 22, 2012 at 5:50 PM, Bruno Nicoletti <bruno.j....@...> wrote:
Base light, Sony Vegas and Toxik do as well. 

Bruno Nicoletti

On 22 Feb 2012, at 17:39, Jeremy Selan <jeremy...@...> wrote:

Hmm...

I say if your plugins are not validated against the mainline OFX (or you wouldnt trust them to work in that context) to leave it out for now.  There really no rush, so we can let the plugins mature as part of TuttleOFX, and then if someone else is interested in OFX support we can look at merging it then.

As nuke has native nodes, the only thing OFX would buy us is integration in other OFX compositors. (The only one that comes to mind is Fusion, but maybe there are others?)

Thoughts?

-- Jeremy

2012/2/22 Marie Fétiveau <m...@...>
Good question, no quick answer :)

TuttleOFX plugins are not classical OFX plugs, they are TuttlePlugins (ta-dah !).

TuttlePlugins is based on a patched version of OpenFX C++ wrapper (called by us : openfxHack). This version introduces some bug corrections and minor features.
TuttlePlugins has also some utils functions, mainly to manipulate GIL views.

It may be overkill for you to link with TuttlePlugins for such a little plugin...

Nonetheless TuttleOCIOLUT node is very simple and most of the process is done in OCIO lib. 
It uses some GIL features but it could (should) totally not use them.

This means that the node could only depend on openfxHack (we'll need to extract the openfxHack part from TuttlePlugins to create a lib).

We can almost say that it could compile with the original OpenFX wrapper but it's a buggy, unused and un-maintained version. So do we really want to do that ? :p

How about that ?


On Tue, Feb 21, 2012 at 6:52 PM, Jeremy Selan <jeremy...@...> wrote:
Do you think it would be appropriate to merge your OFX wrapper for OCIO into the main OCIO tree once they're stable?


-- Jeremy

2012/2/20 Marie Fétiveau <m...@...>
ocio.lut is an OFX plugin that link with OpenColorIO lib which means you can use it in Tuttle's command line (sam) or in Nuke (and any other tools that support OFX). 

For the moment Tuttle is built with a known version of OpenColorIO (1.0.4) which simplifies the Cmake To Bjam conversion.
A python script is used to download and extract the corresponding archive. 

On Mon, Feb 20, 2012 at 7:21 PM, Jeremy Selan <jeremy...@...> wrote:
Cool!

Can you tell use a bit about the integration? Have you added generic OFX support to OCIO?  Or have you directly integrated it natively into TuttleOFX?

-- Jeremy


2012/2/20 Marie Fétiveau <m...@...>
Hello !

TuttleOFX is now using OpenColorIO to read and apply LUT files on images.
This give me the chance to thank you for your great work : it rocks !

Of course that's a tiny first step in the OCIO+TuttleOFX relationship.
Next one : add an OCIOColorspace node.

But for the moment, Tuttle's developpements are focusing on making a beta version (some missing features and debug to do :) ).

++

Marie













Re: OCIO + TuttleOFX

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

Hmm... That makes things interesting.  I'd love to get OCIO support (even in a limited form) in these apps.

Is anyone on this list interested in compiling / testing an OFX plugin version of OCIO?

-- Jeremy

On Wed, Feb 22, 2012 at 5:50 PM, Bruno Nicoletti <bruno.j....@...> wrote:
Base light, Sony Vegas and Toxik do as well. 

Bruno Nicoletti

On 22 Feb 2012, at 17:39, Jeremy Selan <jeremy...@...> wrote:

Hmm...

I say if your plugins are not validated against the mainline OFX (or you wouldnt trust them to work in that context) to leave it out for now.  There really no rush, so we can let the plugins mature as part of TuttleOFX, and then if someone else is interested in OFX support we can look at merging it then.

As nuke has native nodes, the only thing OFX would buy us is integration in other OFX compositors. (The only one that comes to mind is Fusion, but maybe there are others?)

Thoughts?

-- Jeremy

2012/2/22 Marie Fétiveau <m...@...>
Good question, no quick answer :)

TuttleOFX plugins are not classical OFX plugs, they are TuttlePlugins (ta-dah !).

TuttlePlugins is based on a patched version of OpenFX C++ wrapper (called by us : openfxHack). This version introduces some bug corrections and minor features.
TuttlePlugins has also some utils functions, mainly to manipulate GIL views.

It may be overkill for you to link with TuttlePlugins for such a little plugin...

Nonetheless TuttleOCIOLUT node is very simple and most of the process is done in OCIO lib. 
It uses some GIL features but it could (should) totally not use them.

This means that the node could only depend on openfxHack (we'll need to extract the openfxHack part from TuttlePlugins to create a lib).

We can almost say that it could compile with the original OpenFX wrapper but it's a buggy, unused and un-maintained version. So do we really want to do that ? :p

How about that ?


On Tue, Feb 21, 2012 at 6:52 PM, Jeremy Selan <jeremy...@...> wrote:
Do you think it would be appropriate to merge your OFX wrapper for OCIO into the main OCIO tree once they're stable?


-- Jeremy

2012/2/20 Marie Fétiveau <m...@...>
ocio.lut is an OFX plugin that link with OpenColorIO lib which means you can use it in Tuttle's command line (sam) or in Nuke (and any other tools that support OFX). 

For the moment Tuttle is built with a known version of OpenColorIO (1.0.4) which simplifies the Cmake To Bjam conversion.
A python script is used to download and extract the corresponding archive. 

On Mon, Feb 20, 2012 at 7:21 PM, Jeremy Selan <jeremy...@...> wrote:
Cool!

Can you tell use a bit about the integration? Have you added generic OFX support to OCIO?  Or have you directly integrated it natively into TuttleOFX?

-- Jeremy


2012/2/20 Marie Fétiveau <m...@...>
Hello !

TuttleOFX is now using OpenColorIO to read and apply LUT files on images.
This give me the chance to thank you for your great work : it rocks !

Of course that's a tiny first step in the OCIO+TuttleOFX relationship.
Next one : add an OCIOColorspace node.

But for the moment, Tuttle's developpements are focusing on making a beta version (some missing features and debug to do :) ).

++

Marie












Re: OCIO + TuttleOFX

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

Base light, Sony Vegas and Toxik do as well. 

Bruno Nicoletti

On 22 Feb 2012, at 17:39, Jeremy Selan <jeremy...@...> wrote:

Hmm...

I say if your plugins are not validated against the mainline OFX (or you wouldnt trust them to work in that context) to leave it out for now.  There really no rush, so we can let the plugins mature as part of TuttleOFX, and then if someone else is interested in OFX support we can look at merging it then.

As nuke has native nodes, the only thing OFX would buy us is integration in other OFX compositors. (The only one that comes to mind is Fusion, but maybe there are others?)

Thoughts?

-- Jeremy

2012/2/22 Marie Fétiveau <m...@...>
Good question, no quick answer :)

TuttleOFX plugins are not classical OFX plugs, they are TuttlePlugins (ta-dah !).

TuttlePlugins is based on a patched version of OpenFX C++ wrapper (called by us : openfxHack). This version introduces some bug corrections and minor features.
TuttlePlugins has also some utils functions, mainly to manipulate GIL views.

It may be overkill for you to link with TuttlePlugins for such a little plugin...

Nonetheless TuttleOCIOLUT node is very simple and most of the process is done in OCIO lib. 
It uses some GIL features but it could (should) totally not use them.

This means that the node could only depend on openfxHack (we'll need to extract the openfxHack part from TuttlePlugins to create a lib).

We can almost say that it could compile with the original OpenFX wrapper but it's a buggy, unused and un-maintained version. So do we really want to do that ? :p

How about that ?


On Tue, Feb 21, 2012 at 6:52 PM, Jeremy Selan <jeremy...@...> wrote:
Do you think it would be appropriate to merge your OFX wrapper for OCIO into the main OCIO tree once they're stable?


-- Jeremy

2012/2/20 Marie Fétiveau <m...@...>
ocio.lut is an OFX plugin that link with OpenColorIO lib which means you can use it in Tuttle's command line (sam) or in Nuke (and any other tools that support OFX). 

For the moment Tuttle is built with a known version of OpenColorIO (1.0.4) which simplifies the Cmake To Bjam conversion.
A python script is used to download and extract the corresponding archive. 

On Mon, Feb 20, 2012 at 7:21 PM, Jeremy Selan <jeremy...@...> wrote:
Cool!

Can you tell use a bit about the integration? Have you added generic OFX support to OCIO?  Or have you directly integrated it natively into TuttleOFX?

-- Jeremy


2012/2/20 Marie Fétiveau <m...@...>
Hello !

TuttleOFX is now using OpenColorIO to read and apply LUT files on images.
This give me the chance to thank you for your great work : it rocks !

Of course that's a tiny first step in the OCIO+TuttleOFX relationship.
Next one : add an OCIOColorspace node.

But for the moment, Tuttle's developpements are focusing on making a beta version (some missing features and debug to do :) ).

++

Marie











Re: OCIO + TuttleOFX

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

Hmm...

I say if your plugins are not validated against the mainline OFX (or you wouldnt trust them to work in that context) to leave it out for now.  There really no rush, so we can let the plugins mature as part of TuttleOFX, and then if someone else is interested in OFX support we can look at merging it then.

As nuke has native nodes, the only thing OFX would buy us is integration in other OFX compositors. (The only one that comes to mind is Fusion, but maybe there are others?)

Thoughts?

-- Jeremy

2012/2/22 Marie Fétiveau <m...@...>

Good question, no quick answer :)

TuttleOFX plugins are not classical OFX plugs, they are TuttlePlugins (ta-dah !).

TuttlePlugins is based on a patched version of OpenFX C++ wrapper (called by us : openfxHack). This version introduces some bug corrections and minor features.
TuttlePlugins has also some utils functions, mainly to manipulate GIL views.

It may be overkill for you to link with TuttlePlugins for such a little plugin...

Nonetheless TuttleOCIOLUT node is very simple and most of the process is done in OCIO lib. 
It uses some GIL features but it could (should) totally not use them.

This means that the node could only depend on openfxHack (we'll need to extract the openfxHack part from TuttlePlugins to create a lib).

We can almost say that it could compile with the original OpenFX wrapper but it's a buggy, unused and un-maintained version. So do we really want to do that ? :p

How about that ?


On Tue, Feb 21, 2012 at 6:52 PM, Jeremy Selan <jeremy...@...> wrote:
Do you think it would be appropriate to merge your OFX wrapper for OCIO into the main OCIO tree once they're stable?


-- Jeremy

2012/2/20 Marie Fétiveau <m...@...>
ocio.lut is an OFX plugin that link with OpenColorIO lib which means you can use it in Tuttle's command line (sam) or in Nuke (and any other tools that support OFX). 

For the moment Tuttle is built with a known version of OpenColorIO (1.0.4) which simplifies the Cmake To Bjam conversion.
A python script is used to download and extract the corresponding archive. 

On Mon, Feb 20, 2012 at 7:21 PM, Jeremy Selan <jeremy...@...> wrote:
Cool!

Can you tell use a bit about the integration? Have you added generic OFX support to OCIO?  Or have you directly integrated it natively into TuttleOFX?

-- Jeremy


2012/2/20 Marie Fétiveau <m...@...>
Hello !

TuttleOFX is now using OpenColorIO to read and apply LUT files on images.
This give me the chance to thank you for your great work : it rocks !

Of course that's a tiny first step in the OCIO+TuttleOFX relationship.
Next one : add an OCIOColorspace node.

But for the moment, Tuttle's developpements are focusing on making a beta version (some missing features and debug to do :) ).

++

Marie











Re: OCIO + TuttleOFX

Marie Fétiveau <m...@...>
 

Good question, no quick answer :)

TuttleOFX plugins are not classical OFX plugs, they are TuttlePlugins (ta-dah !).

TuttlePlugins is based on a patched version of OpenFX C++ wrapper (called by us : openfxHack). This version introduces some bug corrections and minor features.
TuttlePlugins has also some utils functions, mainly to manipulate GIL views.

It may be overkill for you to link with TuttlePlugins for such a little plugin...

Nonetheless TuttleOCIOLUT node is very simple and most of the process is done in OCIO lib. 
It uses some GIL features but it could (should) totally not use them.

This means that the node could only depend on openfxHack (we'll need to extract the openfxHack part from TuttlePlugins to create a lib).

We can almost say that it could compile with the original OpenFX wrapper but it's a buggy, unused and un-maintained version. So do we really want to do that ? :p

How about that ?


On Tue, Feb 21, 2012 at 6:52 PM, Jeremy Selan <jeremy...@...> wrote:
Do you think it would be appropriate to merge your OFX wrapper for OCIO into the main OCIO tree once they're stable?


-- Jeremy

2012/2/20 Marie Fétiveau <m...@...>
ocio.lut is an OFX plugin that link with OpenColorIO lib which means you can use it in Tuttle's command line (sam) or in Nuke (and any other tools that support OFX). 

For the moment Tuttle is built with a known version of OpenColorIO (1.0.4) which simplifies the Cmake To Bjam conversion.
A python script is used to download and extract the corresponding archive. 

On Mon, Feb 20, 2012 at 7:21 PM, Jeremy Selan <jeremy...@...> wrote:
Cool!

Can you tell use a bit about the integration? Have you added generic OFX support to OCIO?  Or have you directly integrated it natively into TuttleOFX?

-- Jeremy


2012/2/20 Marie Fétiveau <m...@...>
Hello !

TuttleOFX is now using OpenColorIO to read and apply LUT files on images.
This give me the chance to thank you for your great work : it rocks !

Of course that's a tiny first step in the OCIO+TuttleOFX relationship.
Next one : add an OCIOColorspace node.

But for the moment, Tuttle's developpements are focusing on making a beta version (some missing features and debug to do :) ).

++

Marie










Review: OCIO::SetLoggingLevel(...) fix

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

https://github.com/imageworks/OpenColorIO/pull/223

SetLoggingLevel wasnt being obeyed, if set before initialization. Now it works.

- Jeremy


Re: OCIO + TuttleOFX

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

Do you think it would be appropriate to merge your OFX wrapper for OCIO into the main OCIO tree once they're stable?

-- Jeremy

2012/2/20 Marie Fétiveau <m...@...>

ocio.lut is an OFX plugin that link with OpenColorIO lib which means you can use it in Tuttle's command line (sam) or in Nuke (and any other tools that support OFX). 

For the moment Tuttle is built with a known version of OpenColorIO (1.0.4) which simplifies the Cmake To Bjam conversion.
A python script is used to download and extract the corresponding archive. 

On Mon, Feb 20, 2012 at 7:21 PM, Jeremy Selan <jeremy...@...> wrote:
Cool!

Can you tell use a bit about the integration? Have you added generic OFX support to OCIO?  Or have you directly integrated it natively into TuttleOFX?

-- Jeremy


2012/2/20 Marie Fétiveau <m...@...>
Hello !

TuttleOFX is now using OpenColorIO to read and apply LUT files on images.
This give me the chance to thank you for your great work : it rocks !

Of course that's a tiny first step in the OCIO+TuttleOFX relationship.
Next one : add an OCIOColorspace node.

But for the moment, Tuttle's developpements are focusing on making a beta version (some missing features and debug to do :) ).

++

Marie









Re: OCIO + TuttleOFX

Marie Fétiveau <m...@...>
 

ocio.lut is an OFX plugin that link with OpenColorIO lib which means you can use it in Tuttle's command line (sam) or in Nuke (and any other tools that support OFX). 

For the moment Tuttle is built with a known version of OpenColorIO (1.0.4) which simplifies the Cmake To Bjam conversion.
A python script is used to download and extract the corresponding archive. 

On Mon, Feb 20, 2012 at 7:21 PM, Jeremy Selan <jeremy...@...> wrote:

Cool!

Can you tell use a bit about the integration? Have you added generic OFX support to OCIO?  Or have you directly integrated it natively into TuttleOFX?

-- Jeremy


2012/2/20 Marie Fétiveau <m...@...>
Hello !

TuttleOFX is now using OpenColorIO to read and apply LUT files on images.
This give me the chance to thank you for your great work : it rocks !

Of course that's a tiny first step in the OCIO+TuttleOFX relationship.
Next one : add an OCIOColorspace node.

But for the moment, Tuttle's developpements are focusing on making a beta version (some missing features and debug to do :) ).

++

Marie








Re: OCIO + TuttleOFX

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

Cool!

Can you tell use a bit about the integration? Have you added generic OFX support to OCIO?  Or have you directly integrated it natively into TuttleOFX?

-- Jeremy

2012/2/20 Marie Fétiveau <m...@...>

Hello !

TuttleOFX is now using OpenColorIO to read and apply LUT files on images.
This give me the chance to thank you for your great work : it rocks !

Of course that's a tiny first step in the OCIO+TuttleOFX relationship.
Next one : add an OCIOColorspace node.

But for the moment, Tuttle's developpements are focusing on making a beta version (some missing features and debug to do :) ).

++

Marie






1381 - 1400 of 2243