Date   

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.


Re: ICC color profile support?

Paul Miller <ste...@...>
 

On 11/12/2013 9:37 AM, Mark Boorer wrote:
Hi Paul,
I have had similar ideas floating around for a little while. What sort
of work / progress have you had with this?
I haven't done anything yet - just identifying my to-do list for migrating an existing lcms-based system to OCIO.

My existing system just builds a 3D LUT which goes from the ICC profile to SRGB but it would be cleaner to just have it all integrated in one process in OCIO.

It would be nice if there was an OCIO process stage that takes a raw in-memory icc profile data blob.


-Mark

On Tue, Nov 12, 2013 at 3:23 PM, 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.


Re: ICC color profile support?

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

Hi Paul,
I have had similar ideas floating around for a little while. What sort
of work / progress have you had with this?

-Mark

On Tue, Nov 12, 2013 at 3:23 PM, 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.


Re: ICC color profile support?

Andrew Britton <andrew.d...@...>
 

Not sure if this is the answer you're looking for but OCIO has been able to generate ICC profiles for a while. I use it to generate specific show LUTs for te matte painter in my dept (generated an ARRI LogC to Rec709 ICC profile). It works like a charm in Photoshop. there is one small setting in Phtoshop that needs to be set in order for it to work and it deals with keeping the code values; if you're interested, let me know, and i can look that setting up for you when I get to the office.

On Nov 12, 2013, at 7:23 AM, 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.


ICC color profile support?

Paul Miller <ste...@...>
 

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.


Re: Building config.ocio from provided LUTs

Robin Dutta <robin...@...>
 

I feared as much, but I'm surprised that with all the flexibility and uniformity that OCIO provides, there's no method to share LUTs. 

We've asked the vendors to provide their config.ocios along with their LUTs, but they've been unwilling to do so.  All I can figure out so far is the Allocationvars from an spi1d.  I was also hoping that I might be able to figure out the bit depth based off the max number of decimal places their LUT values have, but am not sure if this is a sound approach.  My only other recourse is to have someone make a best guess on the fields which I'm unsure of.


On Friday, November 8, 2013 5:12:02 AM UTC-8, dbr/Ben wrote:
Neither of those can really be determined automatically from the LUT file alone

Determining the interpolation requires visually inspecting the results of the LUT on various images.. but using linear as a default is probably a good approach if you have to

You could potentially determine the bitdepth of the LUT by checking the range of the values (for integer-based LUT formats like 3dl), but not in a general sense - e.g a LUT which stores values as floating point (e.g spi1d I think, or definitely the Cinespace CSP format)

On 07/11/2013, at 12:25 PM, robi...@... wrote:

Hi,

I'm new to OCIO and this forum, and I have what I think is probably a pretty common issue, although after searching for a solution for a couple days, I haven't come up with anything.

My problem is that I am receiving pre-generated LUTs from vendors, mostly in the form of .cube and .spi1d files, and I would like to integrate them into our custom config.ocio.

Is there an established way to extract the required information from these files so I can populate the colorspace definitions in my config?

Most of the fields can be determined, but bitdepth and interpolation are often not defined.  Is there a way to figure this out from the information in the LUT?

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


Re: Building config.ocio from provided LUTs

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

Neither of those can really be determined automatically from the LUT file alone

Determining the interpolation requires visually inspecting the results of the LUT on various images.. but using linear as a default is probably a good approach if you have to

You could potentially determine the bitdepth of the LUT by checking the range of the values (for integer-based LUT formats like 3dl), but not in a general sense - e.g a LUT which stores values as floating point (e.g spi1d I think, or definitely the Cinespace CSP format)


On 07/11/2013, at 12:25 PM, robin...@... wrote:

Hi,

I'm new to OCIO and this forum, and I have what I think is probably a pretty common issue, although after searching for a solution for a couple days, I haven't come up with anything.

My problem is that I am receiving pre-generated LUTs from vendors, mostly in the form of .cube and .spi1d files, and I would like to integrate them into our custom config.ocio.

Is there an established way to extract the required information from these files so I can populate the colorspace definitions in my config?

Most of the fields can be determined, but bitdepth and interpolation are often not defined.  Is there a way to figure this out from the information in the LUT?

--
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: Building config.ocio from provided LUTs

Michel Lerenard <micheli...@...>
 

Hi

as far as I know, no.
'allocation' too cannot be deduced.

The only solution i can think of is having a file attached to the LUT specifying these parameters.

On 11/07/2013 02:55 AM, robin...@... wrote:
Hi,

I'm new to OCIO and this forum, and I have what I think is probably a pretty common issue, although after searching for a solution for a couple days, I haven't come up with anything.

My problem is that I am receiving pre-generated LUTs from vendors, mostly in the form of .cube and .spi1d files, and I would like to integrate them into our custom config.ocio.

Is there an established way to extract the required information from these files so I can populate the colorspace definitions in my config?

Most of the fields can be determined, but bitdepth and interpolation are often not defined. Is there a way to figure this out from the information in the LUT?
--
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 2210