|
Re: An Academy Award for OpenColorIO!
Boudewijn Rempt <bo...@...>
Awesome!
toggle quoted messageShow quoted text
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
|
|
|
|
Re: An Academy Award for OpenColorIO!
Ashley Retallack <ashl...@...>
Congratulations!! Very well deserved!
On 9 January 2014 17:35, Rob Bredow <r...@...> wrote:
--
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:
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!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:
--
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...@...>
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,
|
|
|
|
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:
--
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,
|
|
|
|
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:
--
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. 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
toggle quoted messageShow quoted text
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:
|
|
|
|
Re: ICC color profile support?
Paul Miller <ste...@...>
On 11/12/2013 9:37 AM, Mark Boorer wrote:
Hi Paul,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.
|
|
|
|
Re: ICC color profile support?
Mark Boorer <mark...@...>
Hi Paul,
toggle quoted messageShow quoted text
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,
|
|
|
|
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.
toggle quoted messageShow quoted text
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.
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
Re: Building config.ocio from provided LUTs
Michel Lerenard <micheli...@...>
Hi
toggle quoted messageShow quoted text
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,
|
|
|