Date   

Re: Force a refresh of context variables?

Ashley Retallack <ashl...@...>
 

Or you can save the context data in metadata (if the import format supports it, like exr).

and use:

key1:SHOT
value1:[metadata "look"]


this will make it possible to do different looks based on the actual footage, rather than just an environment set during or before launching Nuke.


On 13 January 2014 23:35, dbr/Ben <dbr....@...> wrote:
If you only need a limited set of the env variables, you can set the Nuke node context tab up like so:

key1: SHOT
value1: [getenv SHOT]

..etc, then it will dynamically pick up changes to the SHOT env-var (without embedding the actual SHOT value in the Nuke nodes)

- Ben

On 14 Jan 2014, at 9:22, Mark Visser <mvi...@...> wrote:

Hi folks,

A feature that our artists fought long and hard to have is the ability to change shots from within their software, without going back to the shell and doing a "setshot" (which sets up various environment variables) and re-starting Nuke. To make that work, we alter the current environment via Python's os.environ.

I can't for the life of me see a way via the Python API to force OCIO to refresh its context variables from the environment -- or even a way to set context variables explicitly. I've tried creating a new config with OCIO.Config.CreateFromEnv / CreateFromFile and making it current with OCIO.SetCurrentConfig, but Nuke doesn't update to reflect the new config at all, let alone refresh the context variables. I see that the github master of OCIO has additional API methods for manipulating context variables via Config.getCurrentContext, but unfortunately Nuke is using 1.0.7, which doesn't seem to have these methods available.

I'm aware of the "Context" tab in the OCIO nodes, but the goal is to make the OCIO config part of the enclosing environment, not embed parts of it in .nk files.

Short of launching a new Nuke instance, is there any way to force a refresh of context variables?

thanks
-Mark

--
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/groups/opt_out.

--
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/groups/opt_out.



--
Ashley Retallack | Pipeline Engineer 

BlueBolt Ltd | 15-16 Margaret Street | London W1W 8RW | T: +44 (0)20 7637 5575 | F: +44 (0)20 7637 3296 | www.blue-bolt.com |


Re: Force a refresh of context variables?

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

If you only need a limited set of the env variables, you can set the Nuke node context tab up like so:

key1: SHOT
value1: [getenv SHOT]

..etc, then it will dynamically pick up changes to the SHOT env-var (without embedding the actual SHOT value in the Nuke nodes)

- Ben

On 14 Jan 2014, at 9:22, Mark Visser <mvi...@...> wrote:

Hi folks,

A feature that our artists fought long and hard to have is the ability to change shots from within their software, without going back to the shell and doing a "setshot" (which sets up various environment variables) and re-starting Nuke. To make that work, we alter the current environment via Python's os.environ.

I can't for the life of me see a way via the Python API to force OCIO to refresh its context variables from the environment -- or even a way to set context variables explicitly. I've tried creating a new config with OCIO.Config.CreateFromEnv / CreateFromFile and making it current with OCIO.SetCurrentConfig, but Nuke doesn't update to reflect the new config at all, let alone refresh the context variables. I see that the github master of OCIO has additional API methods for manipulating context variables via Config.getCurrentContext, but unfortunately Nuke is using 1.0.7, which doesn't seem to have these methods available.

I'm aware of the "Context" tab in the OCIO nodes, but the goal is to make the OCIO config part of the enclosing environment, not embed parts of it in .nk files.

Short of launching a new Nuke instance, is there any way to force a refresh of context variables?

thanks
-Mark

--
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/groups/opt_out.


Force a refresh of context variables?

Mark Visser <mvi...@...>
 

Hi folks,

A feature that our artists fought long and hard to have is the ability to change shots from within their software, without going back to the shell and doing a "setshot" (which sets up various environment variables) and re-starting Nuke. To make that work, we alter the current environment via Python's os.environ.

I can't for the life of me see a way via the Python API to force OCIO to refresh its context variables from the environment -- or even a way to set context variables explicitly. I've tried creating a new config with OCIO.Config.CreateFromEnv / CreateFromFile and making it current with OCIO.SetCurrentConfig, but Nuke doesn't update to reflect the new config at all, let alone refresh the context variables. I see that the github master of OCIO has additional API methods for manipulating context variables via Config.getCurrentContext, but unfortunately Nuke is using 1.0.7, which doesn't seem to have these methods available.

I'm aware of the "Context" tab in the OCIO nodes, but the goal is to make the OCIO config part of the enclosing environment, not embed parts of it in .nk files.

Short of launching a new Nuke instance, is there any way to force a refresh of context variables?

thanks
-Mark


Re: An Academy Award for OpenColorIO!

Andrew Hunter <and...@...>
 

Congratulations Jeremy! 


On Thu, Jan 9, 2014 at 9:10 PM, Dithermaster <dither...@...> wrote:
Congratulations Jeremy and everyone who was contributed to, supports, and uses OpenColorIO! Very well deserved.



On Thu, Jan 9, 2014 at 2:17 PM, Adam Martinez <amarti...@...> wrote:
Congratulations Jeremy and team!


On Thu, Jan 9, 2014 at 12:06 PM, Boudewijn Rempt <bo...@...> wrote:
Awesome!


On Thu, 9 Jan 2014, Rob Bredow wrote:

Jeremy Selan will be awarded an Academy Award for his work on OpenColorIO at the Academy's annual Scientific and Technical Awards Presentation on Saturday, February 15. This is a huge honor for OpenColorIO and a recognition of the
strength of this open source community which has been essential to OpenColorIO's success.

From the press release:

      To Jeremy Selan for the development of the OpenColorIO color management framework. 
OpenColorIO is an open source framework that enables consistent color visualization of motion picture imagery across multiple facilities and numerous software applications.


You can read the complete press release online and see the rest of the awardees as well.

Congratulations to Jeremy who will be receiving his second Sci-Tech Award, and to everyone here who has helped contribute to the success of OpenColorIO!


Sincerely,

Rob Bredow

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
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/groups/opt_out.

--
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/groups/opt_out.


Any new release planned?

Richard Shaw <hobbe...@...>
 

I was asked by a user to rebuild OpenColorIO with OpenImageIO as a dependency so the additional cli tools are built. I didn't do this originally because I didn't want them mutually dependent on each other but it's not too much of a hassle so I'm working on it.

It's not a big deal to just rebuild OCIO with the new build requirement but I figured it might be worth checking to see if any new release is in the works before going to the trouble.

Thanks,
Richard


Re: An Academy Award for OpenColorIO!

Dithermaster <dither...@...>
 

Congratulations Jeremy and everyone who was contributed to, supports, and uses OpenColorIO! Very well deserved.



On Thu, Jan 9, 2014 at 2:17 PM, Adam Martinez <amarti...@...> wrote:
Congratulations Jeremy and team!


On Thu, Jan 9, 2014 at 12:06 PM, Boudewijn Rempt <bo...@...> wrote:
Awesome!


On Thu, 9 Jan 2014, Rob Bredow wrote:

Jeremy Selan will be awarded an Academy Award for his work on OpenColorIO at the Academy's annual Scientific and Technical Awards Presentation on Saturday, February 15. This is a huge honor for OpenColorIO and a recognition of the
strength of this open source community which has been essential to OpenColorIO's success.

From the press release:

      To Jeremy Selan for the development of the OpenColorIO color management framework. 
OpenColorIO is an open source framework that enables consistent color visualization of motion picture imagery across multiple facilities and numerous software applications.


You can read the complete press release online and see the rest of the awardees as well.

Congratulations to Jeremy who will be receiving his second Sci-Tech Award, and to everyone here who has helped contribute to the success of OpenColorIO!


Sincerely,

Rob Bredow

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
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/groups/opt_out.


Re: An Academy Award for OpenColorIO!

Adam Martinez <amarti...@...>
 

Congratulations Jeremy and team!


On Thu, Jan 9, 2014 at 12:06 PM, Boudewijn Rempt <bo...@...> wrote:
Awesome!


On Thu, 9 Jan 2014, Rob Bredow wrote:

Jeremy Selan will be awarded an Academy Award for his work on OpenColorIO at the Academy's annual Scientific and Technical Awards Presentation on Saturday, February 15. This is a huge honor for OpenColorIO and a recognition of the
strength of this open source community which has been essential to OpenColorIO's success.

From the press release:

      To Jeremy Selan for the development of the OpenColorIO color management framework. 
OpenColorIO is an open source framework that enables consistent color visualization of motion picture imagery across multiple facilities and numerous software applications.


You can read the complete press release online and see the rest of the awardees as well.

Congratulations to Jeremy who will be receiving his second Sci-Tech Award, and to everyone here who has helped contribute to the success of OpenColorIO!


Sincerely,

Rob Bredow

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: An Academy Award for OpenColorIO!

Boudewijn Rempt <bo...@...>
 

Awesome!

On Thu, 9 Jan 2014, Rob Bredow wrote:

Jeremy Selan will be awarded an Academy Award for his work on�OpenColorIO�at the Academy's annual Scientific and Technical Awards Presentation on Saturday, February 15. This is a huge honor for OpenColorIO and a recognition of the
strength of this open source community which has been essential to OpenColorIO's success.
From the press release:

To�Jeremy Selan�for the development of the�OpenColorIO�color�management framework.�
OpenColorIO�is an�open�source framework that enables consistent�color�visualization of motion picture imagery across multiple facilities and numerous software applications.
You can read the complete�press release online�and see the rest of the awardees as well.
Congratulations to Jeremy who will be receiving his second Sci-Tech Award, and to everyone here who has helped contribute to the success of�OpenColorIO!
Sincerely,
Rob Bredow
--
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/groups/opt_out.


Re: An Academy Award for OpenColorIO!

Ashley Retallack <ashl...@...>
 

Congratulations!! Very well deserved! 


On 9 January 2014 17:35, Rob Bredow <r...@...> wrote:
Jeremy Selan will be awarded an Academy Award for his work on OpenColorIO at the Academy's annual Scientific and Technical Awards Presentation on Saturday, February 15. This is a huge honor for OpenColorIO and a recognition of the strength of this open source community which has been essential to OpenColorIO's success.

From the press release:

To Jeremy Selan for the development of the OpenColorIO color management framework. 
OpenColorIO is an open source framework that enables consistent color visualization of motion picture imagery across multiple facilities and numerous software applications.

You can read the complete press release online and see the rest of the awardees as well.

Congratulations to Jeremy who will be receiving his second Sci-Tech Award, and to everyone here who has helped contribute to the success of OpenColorIO!


Sincerely,

Rob Bredow

--
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/groups/opt_out.



--
Ashley Retallack | Pipeline Engineer 

BlueBolt Ltd | 15-16 Margaret Street | London W1W 8RW | T: +44 (0)20 7637 5575 | F: +44 (0)20 7637 3296 | www.blue-bolt.com |


An Academy Award for OpenColorIO!

Rob Bredow <r...@...>
 

Jeremy Selan will be awarded an Academy Award for his work on OpenColorIO at the Academy's annual Scientific and Technical Awards Presentation on Saturday, February 15. This is a huge honor for OpenColorIO and a recognition of the strength of this open source community which has been essential to OpenColorIO's success.

From the press release:

To Jeremy Selan for the development of the OpenColorIO color management framework. 
OpenColorIO is an open source framework that enables consistent color visualization of motion picture imagery across multiple facilities and numerous software applications.

You can read the complete press release online and see the rest of the awardees as well.

Congratulations to Jeremy who will be receiving his second Sci-Tech Award, and to everyone here who has helped contribute to the success of OpenColorIO!


Sincerely,

Rob Bredow


OpenColorIGo - Bindings for the Go language

Justin Israel <justin...@...>
 

Hey All,

I had a need to use OpenColorIO for my image processing server, written in Go, so I started working on bindings. Thought I would share, just in case anyone is interested/involved in developing in Go:
    https://github.com/justinfx/opencolorigo

I've got a majority of the read-only "consumption" aspects of the API implemented. My main interest was being able to get to the point of calling Processor:Apply() for a given environments config, so anything surrounding that code path is there.
Suggestions/Contributions welcome. I'm not extremely experienced with OpenColorIO yet in practice. This was just a step I took, to be able to work our OpenColorIO pipeline into my image server.

-- justin




Re: OpenColorIO FTBFS on GNU/kFreeBSD boxes

"Matteo F. Vescovi" <mfve...@...>
 

Hi!

On Tue, Sep 24, 2013 at 03:42:15PM +0200, Matteo F. Vescovi wrote:
Hi!

On Mon, Sep 23, 2013 at 10:03:32PM +0200, Matteo F. Vescovi wrote:
Gonna check it tomorrow afternoon CET ;-)
Just tested and added a link to buildlog in #318 issue.
Any news on this front? OCIO is stuck to v1.0.8 in Debian because we
already have yaml-cpp 0.5.x in sid/unstable suite and now OCIO is ftbfs
against this new version.
Could you possibly let me know what's the plan here?

Thanks in advance.

Cheers.

--
Matteo F. Vescovi
Debian Maintainer
GnuPG KeyID: 0x83B2CF7A


Re: vd16 and alpha channels PS -> Nuke

Ashley Retallack <ashl...@...>
 

> If you attempt to do a similar thing from within a Nuke node chain, the error would already be baked into the data buffer.


Does this include if you have raw switched on in the read node and than do the unpremult -> OCIOColorspace -> Premult method?




On 28 November 2013 19:43, Troy Sobotka <troy.s...@...> wrote:


On Nov 28, 2013 4:49 AM, "Ashley Retallack" <ashl...@...> wrote:
> Thanks for the reply. If I was to do this in a nuke context what would the process be, it this no different to doing an unpremult before color transform and a premult afterwards?

The predivide has to happen prior to TRC inversion.

If the issue is alpha / luminance based, the read node has a “Premultiplied” radio box.

This should take the associated alpha image, predivide it, apply the inverted TRC / transfer curve, then apply the alpha again.

If you attempt to do a similar thing from within a Nuke node chain, the error would already be baked into the data buffer.

With respect,
TJS

--
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/groups/opt_out.



--
Ashley Retallack | Pipeline Engineer 

BlueBolt Ltd | 15-16 Margaret Street | London W1W 8RW | T: +44 (0)20 7637 5575 | F: +44 (0)20 7637 3296 | www.blue-bolt.com |


Re: vd16 and alpha channels PS -> Nuke

Troy Sobotka <troy.s...@...>
 


On Nov 28, 2013 4:49 AM, "Ashley Retallack" <ashl...@...> wrote:
> Thanks for the reply. If I was to do this in a nuke context what would the process be, it this no different to doing an unpremult before color transform and a premult afterwards?

The predivide has to happen prior to TRC inversion.

If the issue is alpha / luminance based, the read node has a “Premultiplied” radio box.

This should take the associated alpha image, predivide it, apply the inverted TRC / transfer curve, then apply the alpha again.

If you attempt to do a similar thing from within a Nuke node chain, the error would already be baked into the data buffer.

With respect,
TJS


Re: vd16 and alpha channels PS -> Nuke

Ashley Retallack <ashl...@...>
 

Hi Troy,

Thanks for the reply. If I was to do this in a nuke context what would the process be, it this no different to doing an unpremult before color transform and a premult afterwards? In which case it does not work as the colors are so different now the alpha associated with it multiple against the wrong value. 

Or do you mean that the alpha it'self needs to be treated first, in which case how do I go about doing this to compensate for the values?

Many thanks

Ash



On 22 November 2013 02:24, Troy Sobotka <troy.s...@...> wrote:

Assuming I understand the issue...

On Nov 21, 2013 10:02 AM, "Ashley Retallack" <ashl...@...> wrote:
> Thanks for the reply. Yes that's what I thought. so it's more that comp and reprojections need to over in the space space as the matte painting was done in rather than trying to correct the alpha to work with the converted color.

If the alpha is associated, it must be predivided prior to linearization.

The reason is due to a luminance collision. A standard sRGB or 709 inverted TRC looks at a value of 0.5 identically when alpha is associated.

For example, a value of red 0.2 looks exactly the same as an associated alpha version of 1.0 red at 0.2 alpha. The resultant luminance will be off when linearized via an inversion of the TRC.

Predivide if associated and you shouldn't have any issues.

With respect,
TJS

--
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/groups/opt_out.



--
Ashley Retallack | Pipeline Engineer 

BlueBolt Ltd | 15-16 Margaret Street | London W1W 8RW | T: +44 (0)20 7637 5575 | F: +44 (0)20 7637 3296 | www.blue-bolt.com |


Re: vd16 and alpha channels PS -> Nuke

Troy Sobotka <troy.s...@...>
 

Assuming I understand the issue...

On Nov 21, 2013 10:02 AM, "Ashley Retallack" <ashl...@...> wrote:
> Thanks for the reply. Yes that's what I thought. so it's more that comp and reprojections need to over in the space space as the matte painting was done in rather than trying to correct the alpha to work with the converted color.

If the alpha is associated, it must be predivided prior to linearization.

The reason is due to a luminance collision. A standard sRGB or 709 inverted TRC looks at a value of 0.5 identically when alpha is associated.

For example, a value of red 0.2 looks exactly the same as an associated alpha version of 1.0 red at 0.2 alpha. The resultant luminance will be off when linearized via an inversion of the TRC.

Predivide if associated and you shouldn't have any issues.

With respect,
TJS


Re: vd16 and alpha channels PS -> Nuke

Ashley Retallack <ashl...@...>
 

Cool,

Thanks for the reply. Yes that's what I thought. so it's more that comp and reprojections need to over in the space space as the matte painting was done in rather than trying to correct the alpha to work with the converted color.

Cheers

Ash



On 21 November 2013 17:27, Brendan Bolles <bre...@...> wrote:
On Nov 21, 2013, at 8:54 AM, Ashley Retallack wrote:

> I was wondering what the best practice is to get an acurat result from nuke as far as compositing a vd16 image with an alpha from photoshop with a linear space. As the result always come out very different to what I have in photoshop. The only way to get a result that is the same is by merging in vd16 space and the converting back to linear afterwards.
>
> Is there a safe way to convert a vd16 image with alpha to linear and have it combine with a similar result as combing two vd16 images.


You will get different results when comping in linear vs. video spaces.  It's an order of operations thing and really can't be helped.  Easiest thing is to comp the layers in video space and then convert the result to linear.  If you're inserting an element in between, you might want to convert it to video space.

The standard Over operation with fully opaque pixels should work the same in either case, but when you have transparency or other modes like Add, you will see changes.  If you must comp those layers in linear, you can make color corrections and other adjustments to try to compensate for the differences you're seeing, but you won't be able to get it to match exactly.


Brendan

--
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/groups/opt_out.



--
Ashley Retallack | Pipeline Engineer 

BlueBolt Ltd | 15-16 Margaret Street | London W1W 8RW | T: +44 (0)20 7637 5575 | F: +44 (0)20 7637 3296 | www.blue-bolt.com |


Re: vd16 and alpha channels PS -> Nuke

Brendan Bolles <bre...@...>
 

On Nov 21, 2013, at 8:54 AM, Ashley Retallack wrote:

I was wondering what the best practice is to get an acurat result from nuke as far as compositing a vd16 image with an alpha from photoshop with a linear space. As the result always come out very different to what I have in photoshop. The only way to get a result that is the same is by merging in vd16 space and the converting back to linear afterwards.

Is there a safe way to convert a vd16 image with alpha to linear and have it combine with a similar result as combing two vd16 images.

You will get different results when comping in linear vs. video spaces. It's an order of operations thing and really can't be helped. Easiest thing is to comp the layers in video space and then convert the result to linear. If you're inserting an element in between, you might want to convert it to video space.

The standard Over operation with fully opaque pixels should work the same in either case, but when you have transparency or other modes like Add, you will see changes. If you must comp those layers in linear, you can make color corrections and other adjustments to try to compensate for the differences you're seeing, but you won't be able to get it to match exactly.


Brendan


vd16 and alpha channels PS -> Nuke

Ashley Retallack <ashl...@...>
 

Hi all,

This may seem like a dumb question, but I've been scratching my brain for quite a while now.

I was wondering what the best practice is to get an acurat result from nuke as far as compositing a vd16 image with an alpha from photoshop with a linear space. As the result always come out very different to what I have in photoshop. The only way to get a result that is the same is by merging in vd16 space and the converting back to linear afterwards.

Is there a safe way to convert a vd16 image with alpha to linear and have it combine with a similar result as combing two vd16 images.

Hope that made sense.

Cheers 

Ash

--
Ashley Retallack | Pipeline Engineer 

BlueBolt Ltd | 15-16 Margaret Street | London W1W 8RW | T: +44 (0)20 7637 5575 | F: +44 (0)20 7637 3296 | www.blue-bolt.com |


Re: ICC color profile support?

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

Malcolm has done some work on being able to load ICC profiles in OCIO configs etc

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

However Jeremy is hesitant to include lcms into OCIO's core (currently it's only used by the optional ociobakelut), so that pull-request is unlikely to be merged before OCIO gains a plugin interface

- Ben

Sent from my phone

On 13 Nov 2013, at 1:53, Paul Miller <ste...@...> wrote:

I'm looking at using OCIO as the basis for a photo editing applications CMS, but I need support for ICC profiles found embedded in image files and used as monitor profiles.

Currently I use lcms for this, and I could run images through it to get srgb at load time, but ideally I'd just pass the raw data through OCIO.

Has anyone done any work on integrating ICC profiles? If not, I'd like to contribute my work if there is interest.

--
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/groups/opt_out.

941 - 960 of 2217