|
OCIO 1.0.8 released
Jeremy Selan <jeremy...@...>
It's been a long time since our last release!
There have been a bunch of updates that have not made it into any tagged release, and seeing as how we have a bunch of development work in progress it seemed appropriate to release a tagged minor version prior to adding the new code. Version 1.0.8 (Dec 11 2012): * After Effects plugin * Core increased precision for matrix inversion * Core md5 symbols no longer leaked * CMake compatibility with OIIO 1.0 namespacing * Cmake option to control python soname * Nuke register_viewers defaults OCIODisplay to "all" * Nuke ColorLookup <-> spi1d lut examples * Windows uses boost shared_ptr by default * Windows fixed csp writing * Windows build fixes * ociobakelut supports looks -- Jeremy
|
|
|
|
Re: Foundry bugfixes to Nuke nodes?
Jeremy Selan <jeremy...@...>
Thanks for bringing this to our attention. I'll contact the foundry
toggle quoted messageShow quoted text
and see if we can find out what they've done. -- Jeremy
On Tue, Dec 11, 2012 at 4:30 AM, dbr/Ben <dbr....@...> wrote:
I was reading the release notes for Nuke,
|
|
|
|
Re: icc profile for photoshop
Andrew Britton <andrew.d...@...>
There are one, or two, more steps that need to be performed in Photoshop so that you can see the .icc in action. Unfortunately these aren't documented on the link. I can write it up and email it if you're interested. Andrew
On Dec 11, 2012, at 4:06 AM, dbr/Ben <dbr....@...> wrote:
|
|
|
|
Upstreamable patches?
Richard Shaw <hobbe...@...>
Hey guys, been a while but things seem to be going well with my Fedora
package of ocio so I haven't needed to ask any questions lately. I was going through my packages and noticed I have two patches against the current 1.0.7 source which I think are upstreamable. I may have already mentioned them but I've slept too many times since then to be sure. This one makes sure that no hidden files are packaged in the documentation (found my rpmlint): https://dl.dropbox.com/u/34775202/ocio/OpenColorIO-1.0.7-docfix.patch This one gives me the option to no put a soname on the pyglue library: https://dl.dropbox.com/u/34775202/ocio/OpenColorIO-1.0.7-pylib_no_soname.patch Thanks, Richard
|
|
|
|
Foundry bugfixes to Nuke nodes?
dbr/Ben <dbr....@...>
I was reading the release notes for Nuke,
..and noticed a few items mentioning bug-fixes to OCIO nodes, like: > BUG ID 27628 - OCIO: OCIODisplay didn't update the Viewer correctly when switching the layer control between all and custom layers. Any one know if these changes are going to be commited back to the main repo? Or if we should reproduce the bug and re-do the fixes, or something like that Since of course they have no obligation to share their modifications, I only ask because at least one Foundry-dev contributed fixes already \o/ - Ben
|
|
|
|
Re: icc profile for photoshop
dbr/Ben <dbr....@...>
That's correct! This guide should hopefully explain everything: If you have access to a Linux machine, you could run ociobakelut on that, then copy the ICC profile to the Windows machine. It's definitely possible to build on Windows, but building on Linux (or OS X) can be easier - it's been documented, and more widely tested
On 11/12/2012, at 10:20 PM, singha...@... wrote: I am to compile ocio for windows. Before i do that certain questions crop in my mind.
|
|
|
|
Re: Bugs in Windows build process
Andrew Britton <andrew.d...@...>
I'd be happy to assist. I don't a wealth of experience with compilers or porting from Mac but I'll be happy to assist and test. I can also help build an installer for Windows.
toggle quoted messageShow quoted text
On Dec 10, 2012, at 8:27 AM, Jeremy Selan <jeremy...@...> wrote:
We dont yet have a how to on the windows build process, though we
|
|
|
|
Re: Shameless Plug: VES Cinematic Color White Paper
Colin Doncaster <colin.d...@...>
A very useful reference, great work Jeremy et al.
toggle quoted messageShow quoted text
On 2012-12-10, at 11:33 AM, Jeremy Selan <jeremy...@...> wrote:
A shameless plug: For those who may be interested, the VES just
|
|
|
|
Shameless Plug: VES Cinematic Color White Paper
Jeremy Selan <jeremy...@...>
A shameless plug: For those who may be interested, the VES just
released a white paper on motion-picture color management: Press Release: http://www.awn.com/news/technology/ves-releases-cinematic-color-white-paper Download: http://cinematiccolor.com/ For those familiar with the Siggraph course notes that used to be posted there, you'll notice a bit of overlap. :) And by all means, pick it to pieces. We welcome your corrections, comments, etc at ves-tec...@.... Cheers, Jeremy
|
|
|
|
Re: Bugs in Windows build process
Jeremy Selan <jeremy...@...>
We dont yet have a how to on the windows build process, though we
toggle quoted messageShow quoted text
certainly would like to get one going! (Are there any volunteers on the list to assist with this?) In the long term, I think it would be preferable to include a windows installer so that users dont have to build OCIO at all! You should also know that Nuke 6.3v7 and above ship with OCIO (on all platforms), so if you're only looking to experiment with OCIO, as a Nuke user, you can just experiment with later versions. -- Jeremy
On Sat, Dec 8, 2012 at 4:07 AM, <singha...@...> wrote:
It may occur silly to ask. do you have startup on how to build ocio for
|
|
|
|
ocio for windows
Nishith Singhai <nishith...@...>
Hello,
Is there a step by step guide to compile ocio for windows. I have been reading thru the articles. Not clear on how exactly to go about. -- Thanking You, Nishith P Singhai | Senior Programmer FutureWorks Media ltd t: +91 22 401 45000 | c: +91 92 218 03205 | f: +91 22 267 40332      
|
|
|
|
Re: .ICC not requiring --copyright info
Jeremy Selan <jeremy...@...>
yup, please clean up that error code too, thanks!
We should also try to take advantage of github for code-checkin specific comments and discussions. I dont want to overwhelm people with minutia of code on the email list... :) -- Jeremy On Thu, Dec 6, 2012 at 8:49 AM, Andrew Britton <andrew.d...@...> wrote: Should I pull out the code path in main.cpp that returns an error if --copyright is not set?
|
|
|
|
Re: .ICC not requiring --copyright info
Andrew Britton <andrew.d...@...>
Should I pull out the code path in main.cpp that returns an error if --copyright is not set?
toggle quoted messageShow quoted text
It seems vestigial at this point.
On Dec 5, 2012, at 9:45 PM, dbr/Ben <dbr....@...> wrote:
Your last sentence is right, it does not error because there is a default value for 'copyright':
|
|
|
|
Re: .ICC not requiring --copyright info
dbr/Ben <dbr....@...>
Your last sentence is right, it does not error because there is a default value for 'copyright':
toggle quoted messageShow quoted text
std::string copyright = "OpenColorIO (Sony Imageworks)"; Whereas others like description are just: std::string description; I think it would only error if you did: ociobakelut --description "" (i.e an empty string)
On 06/12/2012, at 7:55 AM, Andrew Britton wrote:
I've been building various .ICC files and not once have I set the --copyright flag and not once has an error been thrown. After looking in the main.cpp for ociobakelut I see that it should be throwing an error, but for some reason it isn't. Is it being set by default in the Argparse class?
|
|
|
|
Re: Rendering per-shot grades with ocioconvert
Jeremy Selan <jeremy...@...>
i'd recommend also looking at oiio-tool (part of openimageio) as a
toggle quoted messageShow quoted text
command-line image utility. ocioconvert is super bare bones, and i'm actually consider moving into the oiio project itself. (I dont like how oiio depends on ocio, but the ocio utils depend on ocio. we can break this circular dependency by moving ocio utilities that need oiio into oiio itself). -- Jeremy
On Wed, Dec 5, 2012 at 2:55 PM, bsloan <bsl...@...> wrote:
*Adding*
|
|
|
|
Re: Rendering per-shot grades with ocioconvert
bsloan <bsl...@...>
*Adding*
toggle quoted messageShow quoted text
On Tuesday, December 4, 2012 2:59:08 PM UTC-8, bsloan wrote: Apologies if this is a repeat question:
|
|
|
|
Re: Rendering per-shot grades with ocioconvert
bsloan <bsl...@...>
Thanks all. Yes, I was able to get the desired result by add a colorspace to the config that applies the grade and the display LUT.
toggle quoted messageShow quoted text
We're trying ocioconvert as a way to make LUT-baked jpeg proxies of EDR renders. Nuke, burdened with our facility customizations is too slow to launch per-frame and rvio is too expensive. For a shop that has an OCIO config dir and per-shot grades for every show, ocioconvert looks more like a free, off-the-shelf tool than an API tutorial. :)
On Tuesday, December 4, 2012 2:59:08 PM UTC-8, bsloan wrote:
Apologies if this is a repeat question:
|
|
|
|
.ICC not requiring --copyright info
Andrew Britton <andrew.d...@...>
I've been building various .ICC files and not once have I set the --copyright flag and not once has an error been thrown. After looking in the main.cpp for ociobakelut I see that it should be throwing an error, but for some reason it isn't. Is it being set by default in the Argparse class?
Andrew
|
|
|
|
Re: Rendering per-shot grades with ocioconvert
Brendan Bolles <bre...@...>
On Dec 4, 2012, at 2:59 PM, Blake Sloan wrote:
Is it possible to apply a look as well? Would that require adding a colorspace to ocio.config? Or is it even possible? If you look at the spi-vfx configuration, the srgb8 and p3dci8 color spaces incorporate a film look using a 3D LUT. That's why you can use them as an output space but not an input space (the 3D LUT can't be inverted). To do different 3D LUTs for different shots with the software as it currently is, you could create a whole bunch of output color spaces (srgb8-shot1, srgb8-shot2, etc.) as Ben is suggesting. OCIO has the ability to add a separate "looks" parameter via DisplayTransform.setLooksOverride() and other mechanisms, but none of the current software is using it and none of the sample configs have looks. I'm kind of surprised by that actually - does Sony not use per-shot color corrections and looks? Brendan
|
|
|
|
Re: Rendering per-shot grades with ocioconvert
dbr/Ben <dbr....@...>
It would be easy to add an "ocioconvert --look blah" argument. Made a ticket for that: I think ocioconvert is mainly intended as an example of how to use the OCIO API (as is ociodisplay), and facilities would tend to have their own comperable tool.. so it's not necessarily updated with new features (unless they are requested, as you have done!) That is also one of the reasons there's quite so little documentation on it (along with the usual reasons for lack of documentation!). Ticket for that: As for a workaround, you could define a colorspace which applies your look, something like: colorspaces: - !<ColorSpace> name: lookworkaround to_reference: !<GroupTransform> children: - !<LookTransform> {src: lnf, dst: lnf, looks: "maingradelook,secondlook"} - !<FileTransform> {src: blah.spi3d, interpolation: linear} - !<ColorSpaceTransform> {src: lnf, dst: lg10} Then do: $ ocioconvert in.exr lnf out.exr lookworkaround (haven't tested the above ColorSpace, and it's been months since I've written a config, but that should give you the general idea..)
On 05/12/2012, at 9:29 AM, Blake Sloan wrote: Apologies if this is a repeat question:
|
|
|