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?
toggle quoted message
Show quoted text
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
|
|
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).
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:
toggle quoted message
Show quoted text
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
|
|
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
toggle quoted message
Show quoted text
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).
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
|
|
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 ?
toggle quoted message
Show quoted text
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).
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
|
|
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
toggle quoted message
Show quoted text
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).
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
|
|
Bruno Nicoletti <bruno.j....@...>
Base light, Sony Vegas and Toxik do as well.
Bruno Nicoletti
toggle quoted message
Show quoted text
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).
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
|
|
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
toggle quoted message
Show quoted text
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 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).
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
|
|
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
toggle quoted message
Show quoted text
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 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).
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
|
|
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.
|
|