Date   

color picking role, used in Nuke?

lucien...@...
 

Hi everyone,

Let me start by introducing myself, I currently work at Image Engine, Vancouver and previously I was at Framestore, London.

I'm looking at doing comp work with wider gamut sources and I'm wondering about the color picker color management in Nuke.

Does anyone have found if the color picking role is ever being used by Nuke?
Should I do transformation myself if not?Anyone has tips to do that elegantly?

Cheers

Lucien


Compatible software list

Alexandre Gauthier <immar...@...>
 

Hi,

Could you add Natron (www.natron.fr) as compatible software on the corresponding page on http://opencolorio.org/CompatibleSoftware.html ?
It is made compatible in a very similar way to how Nuke nodes do it. 
The following nodes are available: OCIOCDLTransform, OCIOColorSpace, OCIODisplay, OCIOFileTransform, OCIOLookTransform, OCIOLogConvert

All OCIO configs are bundled in Natron (Aces 1.0, Blender, Nuke-default,Spi-Anim, Spi-Vfx). They can be selected in the Preferences of the application, and the Blender profile is set as default.

cheers,

Alex


Re: SIGGRAPH 2015 - OpenColorIO Birds of a Feather

dennis...@...
 

Thanks for the meetup! Great discussion and I will be putting a lot of advice to good use.

Den


On Wednesday, August 5, 2015 at 4:49:43 PM UTC-7, Mark Boorer wrote:
Hi All,

For those of you attending SIGGRAPH 2015 in Los Angeles, we will be hosting a "Birds of a Feather" event for users and developers of OpenColorIO to get together and discuss anything and everything related to working with OpenColorIO.

I realise that this year has been a little quiet on the development front, but rest assured we have some exciting new features being worked on at present by a number of teams.

It'd be great to be able to put names to faces and to hear about any ideas, problems or solutions people have come up with.

The event takes place on Wednesday, August 12, 2015 from 3:00 pm till 4:30pm in the Los Angeles Convention Center, Room 512.

For those of you who are either not registered to attend the conference, or have other talks to attend, I encourage you to also participate in the Open Source VFX "Beers of a Feather" later that same day from 6pm till 8pm at Salvage (West 7th Street  http://salvagela.com/)

I hope to meet as many of you as possible!

-Mark


SIGGRAPH 2015 - OpenColorIO Birds of a Feather

Mark Boorer <mark...@...>
 

Hi All,

For those of you attending SIGGRAPH 2015 in Los Angeles, we will be hosting a "Birds of a Feather" event for users and developers of OpenColorIO to get together and discuss anything and everything related to working with OpenColorIO.

I realise that this year has been a little quiet on the development front, but rest assured we have some exciting new features being worked on at present by a number of teams.

It'd be great to be able to put names to faces and to hear about any ideas, problems or solutions people have come up with.

The event takes place on Wednesday, August 12, 2015 from 3:00 pm till 4:30pm in the Los Angeles Convention Center, Room 512.

For those of you who are either not registered to attend the conference, or have other talks to attend, I encourage you to also participate in the Open Source VFX "Beers of a Feather" later that same day from 6pm till 8pm at Salvage (West 7th Street  http://salvagela.com/)

I hope to meet as many of you as possible!

-Mark


5th annual Open Source VFX Beer of a Feather

Larry Gritz <l...@...>
 

5th annual Open Source VFX Beer of a Feather

For those of you attending SIGGRAPH 2015 in Los Angeles, we will be once again holding an event for developers and users of VFX-specific open source projects. It's a great chance to meet in person with people you've been working with on the other end of the mail lists.

When: Wed. August 12, 2015, 6-8pm

Where: Salvage, 717 West 7th Street http://salvagela.com/

How: Sponsors will charge up a tab, and we'll be able to get drinks and hors d'oeuvre until the funding pool runs out (after which you're welcome to stay and buy your own drinks). With proper food and drink in hand, relax and enjoy the company of your fellow open source developers.

Your generous sponsors:

Digital Domain
Double Negative
DreamWorks Animation
Industrial Light + Magic
Luma Pictures
Method Studios
Peregrine Labs
Pixar Animation Studios
SolidAngle SL
Sony Pictures Imageworks
Walt Disney Animation Studios
Weta Digital

Please direct questions to: lg AT imageworks DOT com

Please feel free to forward to your developers and the appropriate mail lists for other open source VFX projects you participate in.

Also, if your organization is not one of the sponsors but you'd like to be, contact LG and there's certainly time to help charge up a bigger tab (no contribution is too small).



--
Larry Gritz
l...@...


Re: Add ExpressionTransform op

Marie Fetiveau <ma...@...>
 

Ok, thanks.

In the last commit of this PR (february 2015), an OCIO_USE_LLVM opt was added so I actually built this code without LLVM.

On Sat, May 23, 2015 at 5:10 AM, Malcolm Humphreys <malcolmh...@...> wrote:
We have been waiting for Mark to post headers for the new plugin API.

The idea is to keep the OCIO core free of heavy dependencies and for things like Expression, CTL and Truelight to be supplied by plugins (which are optional and can have heavy link dependencies).

Merging this pull request would force all the third party apps to start compiling and linking to LLVM.

.malcolm

On 22/05/2015, at 10:49 PM, Marie Fetiveau wrote:

Helloo,

Someone knows why it's on hold ?

Thanks,

Marie

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.



--
Marie Fétiveau
Color / IO / Comp Pipeline TD
_____________________

      


Re: Add ExpressionTransform op

Malcolm Humphreys <malcolmh...@...>
 

We have been waiting for Mark to post headers for the new plugin API.

The idea is to keep the OCIO core free of heavy dependencies and for things like Expression, CTL and Truelight to be supplied by plugins (which are optional and can have heavy link dependencies).

Merging this pull request would force all the third party apps to start compiling and linking to LLVM.

.malcolm


On 22/05/2015, at 10:49 PM, Marie Fetiveau wrote:

Helloo,

Someone knows why it's on hold ?

Thanks,

Marie

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


Add ExpressionTransform op

Marie Fetiveau <ma...@...>
 

Helloo,

Someone knows why it's on hold ?

Thanks,

Marie


Re: Support for OpenGL/GLSL > 2.0?

mark.alex...@...
 

texture3D() is also deprecated in GLSL 1.30, so it should be returning the texture() version for 1.30. An additional enum shouldn't be needed since GLSL is forward-compatible from 1.30 onwards. It's between 1.20 (GL2.x) and 1.30 (GL3.0) that there's a big break in the language.


On Thursday, May 21, 2015 at 6:41:04 AM UTC-4, Boon Hean Low wrote:
Hi everyone,

I saw that the GpuLanguage enum goes only up to GLSL 1.3, are there any plans to support anything higher? I'm using getGpuShaderText() to get the fragment shader snippets but its still using texture3D() which is deprecated in OpenGL 4.0 which I'm using now.

thanks
Boon


Support for OpenGL/GLSL > 2.0?

Boon Hean Low <boonhe...@...>
 

Hi everyone,

I saw that the GpuLanguage enum goes only up to GLSL 1.3, are there any plans to support anything higher? I'm using getGpuShaderText() to get the fragment shader snippets but its still using texture3D() which is deprecated in OpenGL 4.0 which I'm using now.

thanks
Boon


Re: multiple config file

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

Merging/hierarchical configs have been discussed in the past, but I suspect will not happen any time soon (it is a difficult problem to solve)

The best solution/alternative I am aware of is to generate your configs via a Python script. For example have a function which produces your base OCIO.Config object, then a function which does show-specific modifications and writes out a show-specific config

That way you have a single source for all your common colorspaces etc, while still preserving a self-contained config.ocio for each show

There is examples of creating configs from Python in the OpenColorIO-configs repository
- Ben

Sent from my phone

On 29 Apr 2015, at 12:30, lucien...@... wrote:

Hi guys,

How can I set up my pipeline so I have multiple config file building my color management profile.

The idea is to have config at facility level and then have show specific but that would add to the facility level config.

I hope that makes sense.

The bottleneck for me is the OCIO env is not a ':' seperated list of path but pointing to a file only.

Anyone has a workaround?

cheers

Lucien

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


multiple config file

lucien...@...
 

Hi guys,

How can I set up my pipeline so I have multiple config file building my color management profile.

The idea is to have config at facility level and then have show specific but that would add to the facility level config.

I hope that makes sense.

The bottleneck for me is the OCIO env is not a ':' seperated list of path but pointing to a file only.

Anyone has a workaround?

cheers

Lucien


Re: Review: added ociobuildicc app

Gerardo <gerard...@...>
 

Hello,

Just to say thanks and let you know that last versions of LittleCMS are able to perform color conversions in unbounded full floating point mode and generates ICC v4.3 profiles. latest LCMS version is 2.6/2.7
v4.3 profiles (including cLUT profiles) are able to work in unbounded FP domain, so results won't be clipped to 16-bpc.

Greetings,



Gerardo


 


Re: Python apply .cube ?

tre...@...
 

to answer my own question:
It seems I had the wrong idea about how the FileTransform worked.
From Configs/nuke-default/make.py :
create the colorspace, then appy using oiio.ImageBufAlgo.colorconvert

cs = OCIO.ColorSpace(name='sRGB')
cs.setDescription("Standard RGB Display Space")
cs.setBitDepth(OCIO.Constants.BIT_DEPTH_F32)
cs.setAllocation(OCIO.Constants.ALLOCATION_UNIFORM)
cs.setAllocationVars([RANGE[0], RANGE[1]])

t = OCIO.FileTransform('srgb.spi1d', interpolation=OCIO.Constants.INTERP_LINEAR)
cs.setTransform(t, OCIO.Constants.COLORSPACE_DIR_TO_REFERENCE)
config.addColorSpace(cs)


Python apply .cube ?

tre...@...
 

Please help!
I am trying to load in a file, resize it, apply a .cube LUT then write it out.
I have the following so far, but I'm falling over between the oiio > ocio parts (one using an oiio.ImgBuf and the other using a pixel array)
Have I missed something ? Is there an easier way to apply a .cube LUT to an image.
Thanks for any pointers !
Trevor

    #load in file & resize
        origBuffer = oiio.ImageBuf(aFile)
        resizeBuffer = oiio.ImageBuf(oiio.ImageSpec (1920, 972, 3, oiio.FLOAT))
        oiio.ImageBufAlgo.resize(resizeBuffer, origBuffer)

        config = OCIO.Config()

        transform = OCIO.FileTransform(src = self.LUT, interpolation = self.interpolation, direction = OCIO.Constants.TRANSFORM_DIR_FORWARD)
        processor = config.getProcessor(transform)

        pixels=self.inputNode.get_pixels()
        img = processor.applyRGBA(pixels)
    img.write(outputPath)


Pull request for custom transforms

Lukas Stockner <lukas.s...@...>
 

Hello,

I decided to implement the custom transform idea I posted earlier and send a pull request: https://github.com/imageworks/OpenColorIO/pull/390

The implementation is quite short and simple, it just exposes a class that new Transforms can inherit. By implementing all the functions, it can then be used just like regular transforms.
This is particularly useful for customizing a OCIO-based color pipeline, since own additions might be needed.
In my case, this functionality is required for implementing a tonemapping operator in Blender, which uses OCIO for its color management. Currently, the only two options are to either maintain a modified version of OCIO, or to implement it alongside OCIO before or after the Processor is called. With this change, it would be possible to implement the tonemapper as a Transform and directly use it in the DisplayTransform.

An example that shows how a custom transform looks like are these two files (header and source):
http://www.pasteall.org/56658
http://www.pasteall.org/56657

So, I hope that this feature will be accepted, and will of course fix any issues that might be present.

Best regards,
Lukas Stockner


Re: Precision of float values in config generated from Python

Dithermaster <dither...@...>
 

You need to print and later parse 8 digits to uniquely capture a float.

For those craving more information: https://randomascii.wordpress.com/2012/03/08/float-precisionfrom-zero-to-100-digits-2/

///d@


On Fri, Jan 30, 2015 at 6:32 PM, Haarm-Pieter Duiker <li...@...> wrote:
Thanks for digging into this, and my apologies for missing the obvious limit of float precision. I was running into an issues where the limited precision is combined with high-intensity values to produce different results than the reference implementation. I've found a workaround though. More precision preserved throughout the process would still be appreciated.

HP




On Fri, Jan 30, 2015 at 3:53 AM, Kevin Wheatley <kevin.j....@...> wrote:
There are cases in the code where the precision of the formatting is
used to generate Cache Ids, changing the precision here would change
the behavior  there are also cases with luts where certain precision
limits are assumed, my conclusion would thus be getting to full float
precision should be doable, but with careful adjustments, in
particular there might not be enough test coverage to ensure
maintaining the behaviour exactly.

Going to double precision to go beyond a maximum of 9 digits is a
different matter, does it make a visible difference tot he images?

Kevin

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


Re: Precision of float values in config generated from Python

Haarm-Pieter Duiker <li...@...>
 

Thanks for digging into this, and my apologies for missing the obvious limit of float precision. I was running into an issues where the limited precision is combined with high-intensity values to produce different results than the reference implementation. I've found a workaround though. More precision preserved throughout the process would still be appreciated.

HP




On Fri, Jan 30, 2015 at 3:53 AM, Kevin Wheatley <kevin.j....@...> wrote:
There are cases in the code where the precision of the formatting is
used to generate Cache Ids, changing the precision here would change
the behavior  there are also cases with luts where certain precision
limits are assumed, my conclusion would thus be getting to full float
precision should be doable, but with careful adjustments, in
particular there might not be enough test coverage to ensure
maintaining the behaviour exactly.

Going to double precision to go beyond a maximum of 9 digits is a
different matter, does it make a visible difference tot he images?

Kevin

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


Re: Precision of float values in config generated from Python

Kevin Wheatley <kevin.j....@...>
 

There is also a bug in yaml-cpp which prevents this in
src/emitterstate.cpp it needs fixing to read:

bool EmitterState::SetFloatPrecision(int value, FMT_SCOPE scope)
{
if(value < 0 || value > (2 +
std::numeric_limits<float>::digits * 3010/10000))
return false;
_Set(m_floatPrecision, value, scope);
return true;
}

bool EmitterState::SetDoublePrecision(int value, FMT_SCOPE scope)
{
if(value < 0 || value > (2 +
std::numeric_limits<double>::digits * 3010/10000))
return false;
_Set(m_doublePrecision, value, scope);
return true;
}

Then in OCIO's code you need to add something like:

out.SetFloatPrecision(2 +
std::numeric_limits<float>::digits * 3010/10000);
out.SetDoublePrecision(2 +
std::numeric_limits<double>::digits * 3010/10000);

To the save function in OCIOYaml.cpp (near line 1664)

At least by that point ociocheck will read and write a config file
with more precision :-)

Kevin


Re: Precision of float values in config generated from Python

Kevin Wheatley <kevin.j....@...>
 

There are cases in the code where the precision of the formatting is
used to generate Cache Ids, changing the precision here would change
the behavior there are also cases with luts where certain precision
limits are assumed, my conclusion would thus be getting to full float
precision should be doable, but with careful adjustments, in
particular there might not be enough test coverage to ensure
maintaining the behaviour exactly.

Going to double precision to go beyond a maximum of 9 digits is a
different matter, does it make a visible difference tot he images?

Kevin

801 - 820 of 2227