|
OCIO Governance Change
Jeremy Selan <jeremy...@...>
Up until now we've been running OpenColorIO with myself as the "Benevolent Dictator". This has seemed appropriate for the early stages of OCIO's life where development was fairly dynamic and we had a smaller community of users. As OCIO now has wider adoption and is relied on in a large number of applications, we're opening up the management of the project to include the following developers who are now tasked as official OpenColorIO project leaders and administrators: Malcolm Humphreys Robert Molholm Brian Hall Matthias Scharfenberg
Mark Boorer I'll be staying on as well to continue to guide the project but since my new day job doesn't involve using OCIO every day, we wanted to ensure we have an empowered group of project leads. In the absence of an alternative formal governance model*, I'll continue to act as the tie-breaker if there is disagreement on any critical steps. That said, I expect we'll continue to have strong consensus going forward. As many of you have noticed we have quite the backlog of open pull requests and issues: https://github.com/imageworks/OpenColorIO/pulls https://github.com/imageworks/OpenColorIO/issues Our hope is that by empowering a wider group of leaders that we'll be able to make robust progress on both of these fronts. The next big challenge in my mind is continuing to balance the dual goals of continued feature development, while also preserving a stable API / robust library that by pipeline necessity must be bullet-proof version to version. Perhaps now would be a good time to fork a stable 1.X branch vs a developer branch? Regards, Jeremy * See http://oss-watch.ac.uk/resources/governancemodels for some interesting discussions on more formalized open source governance models.
|
|
|
|
4th Annual Open Source VFX "Beer of a Feather"
Larry Gritz <l...@...>
For those of you attending SIGGRAPH 2014 in Vancouver, 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 on the other end of the mail lists. When: Wed. August 13, 2014, 6-8pm Where: Rogue Kitchen & Wetbar in Gastown 601 W. Cordova Street http://www.roguewetbar.com/gastown How it works: Our kind sponsors will charge up a tab, and we'll be able to get drinks until the funding pool runs out (after which you're welcome to stay and buy your own drinks). We'll also have lots of great food being served. With proper food and drink in hand, relax and enjoy the company of your fellow open source developers. Your generous sponsors: Ahead.IO Digital Domain Double Negative DreamWorks Animation Darin Grant Industrial Light + Magic Luma Pictures Method Studios Peregrine Labs Pixar Animation Studios Sebastian Sylwan SolidAngle SL Sony Pictures Imageworks Walt Disney Animation Studios Weta Digital Please direct questions to: l...@... -- Larry Gritz l...@...
|
|
|
|
Re: Building "universal" binaries for MacOS
Andrea Mantler <man...@...>
Hi Robert, I'm curious... will your changes be rolled into the main OCIO repository? (If not, I should probably make a patch to apply to the main one for the next time we need to update our OCIO libraries.) Thanks again for all your help! Cheers, Andrea
On Friday, May 30, 2014 1:51:06 PM UTC-5, Robert Minsk wrote:
|
|
|
|
icc profiles not working
Alex Fry <al...@...>
Hey guys Has anyone tried baking out icc profiles recently? I've been trying to bake one out with variations on the following command:
ociobakelut --format icc --inputspace acesproxy --outputspace rrt_rec709_full_100nits --description "AcesProxy to Rec709" ~/Library/ColorSync/Profiles/acesproxy_to_rec709.icc ociobakelut doesn't throw any errors, and a profile is created.
But neither Preview or Photoshop are picking it up. ColorSync Utility.app throws the following error when verifying . ~/Library/ColorSync/Profiles/acesproxy_to_rec709.icc
Header message digest (MD5) is missing.
It's also not showing any graphical representation of the profile in the "Lab plot" pane.
This is a fresh install of OCIO via brew. -Alex
|
|
|
|
Re: Brew install OCIO breaking under 10.9.3
Alex Fry <al...@...>
Ignore this... It was something broken in my brew..
On Sun, Jun 29, 2014 at 4:41 PM, Alex Fry <al...@...> wrote:
|
|
|
|
Brew install OCIO breaking under 10.9.3
Alex Fry <al...@...>
Hey guys Was this working a few weeks back? -Alex 192-168-1-7:~ alex$ brew install opencolorio ==> Downloading https://github.com/imageworks/OpenColorIO/archive/v1.0.9.tar.gz Already downloaded: /Library/Caches/Homebrew/opencolorio-1.0.9.tar.gz ==> Downloading https://github.com/imageworks/OpenColorIO/commit/ebd6efc036b6d0b17c869e3342f17f9c5ef8bbfc.diff Already downloaded: /Library/Caches/Homebrew/opencolorio--patch-f4acc4028090ea8d438c6e0093e931afd836314c.diff ==> Patching patching file export/OpenColorIO/OpenColorABI.h.in patching file export/OpenColorIO/OpenColorIO.h ==> cmake -DCMAKE_INSTALL_PREFIX=/usr/local/Cellar/opencolorio/1.0.9 -DCMAKE_BUILD_TYPE=None -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_VERBOSE_MAKEFILE=ON -Wno-dev -DCM ==> make Linking CXX static library libOpenColorIO.a [100%] Built target OpenColorIO_STATIC Linking CXX executable ociobakelut [100%] Built target ociobakelut make: *** [all] Error 2 READ THIS: https://github.com/Homebrew/homebrew/wiki/troubleshooting
|
|
|
|
OpenColorIO COP2 nodes for Houdini as Nuke counterparts
wagen...@...
------------------------------------------------------------------------------------ OpenColorIO COP2 nodes for Houdini as Nuke counterparts ------------------------------------------------------------------------------------ Hi guys, this is my first post on the mailing list. I'm a Technical Direction Student from Filmakademie in Germanyand i created an OCIO plugin for Houdinis compositing network that aims to bring Nukes OCIO nodes to Houdini. Please feel free to have a look ;) ------------------------------------------------------------------------------------ OpenColorIO COP2 nodes? A possible use case for example could be, to grade backdrops when rendering. Here is a little introduction video And some images:
------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------ Plugin Status ------------------------------------------------------------------------------------ Please note that the plugin is currently in alpha status. There are still bugs here and there but i guess it's best to release it now, so maybe it will get some true battle testing. Should you find bugs, please feel free to submit them on the github issue tracker. Also please feel free to fork or clone the repo and build the plugin for your platform. I currently only supply precompiled binaries for H13 for windows, built with msvc11. (I want to supply Linux binaries as well, since i know about its importance in the Houdini community, as soon as i have a Linux build setup up and running). Git Repository ------------------------------------------------------------------------------------ Download and additional information Additional information can be found on my website. Download the precompiled binaries here (H13, Win, MSVC11) The download contains example images and scenes. I hope the plugin is of use to somebody  ------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------ In case you are interested in following some forum discussions on some Houdini forums: Official SideFX forum (contains a probably interesting poll)
|
|
|
|
AllocationVars and Allocation tags problem
Dmitry Kazakov <dimu...@...>
Good morning! Here is how the image looks when calculating on CPU: http://dimula73.narod.ru/krita_allocation_var_CPU.png The cause of this problem is too wide range for the 'allocatiovars' used in config, which is actually standard spi-vfx value. If I change the value to, say, [-10.0, 5.0] then the quality of the transformation becomes ok and the shaders generate the image looking exactly like on CPU. Can we (OCIO and/or Krita) do something with it? What I'm thinking about is: it is quite rare usecase when the application (e.g. Krita) needs to display the whole range of the image colors. That is, most of the time we display only a small subset of the image colors, say, [0.0, 1.0] or [0.0, exposition]. Can we adjust the allocationvars dynamically according to the currently displayed gamut? Some crazy idea: The application might notice the DisplayTransform about what output colors are actually needed. For shader-based rendering it'll be [0.0, 1.0] obviously. Then OCIO might walk through the chain of transformations and adjust their allocation values according to the values really needed. Obviously enough one would need to obtain reverse transformations for that, which is impossible... But given that 3D-lut in the shader is an approximation anyway, the range can be acquired using random sampling of the space defined in allocationvars and used for generation of the 3D-lut. I understand that this is optimization, but it can not only fix problems with such corner-cases like [2], but also give much better quality of the GPU-based rendering of the image. the 3D-luts generated by OCIO would be more dense, and would nor waste the range on values which will never be displayed anyway. What do you think about this idea?
|
|
|
|
Re: Using environment variables/context to point to a colorspace
donat...@...
Hi, Thanks for the ticket. I could indeed implement a callback for the OCIO colorspace nodes. I already have some code that sets the context variables of the OCIO ColorSpace node. The problem is then for the viewer dropdown menu. It would not be very convenient in Nuke's UI to have to add somewhere a button to control the viewer dropdown menu. In my previous implementation of OCIO I created different colorspaces such as "ShotViewAlexa", "ShotViewRedGamma3". These colorspaces were meant for Nuke's viewer. They convert from linear to the cam colorspace, then add a 3d lut specific to the shot. This was kind of problematic because users sometimes were using the wrong colorspace. I'd rather have a single colorspace for showing the shot specific grade. In the meantime I did find a workaround. I'm defining my 'shotView' colorspace as being a transfrom from Linear to the Camera Colorspace, then I apply a shot specific 3dl lut. In my config file it's like this : - !<ColorSpaceTransform> {src: Flat, dst: linear} # Flat is a balanced linear colorspace - !<FileTransform> {src: Camera/$CAMERA/$CAMERA_main.spi1d, interpolation: linear, direction: inverse} - !<FileTransform> {src: Camera/$CAMERA/$CAMERA_post.spi1d, interpolation: linear} - !<FileTransform> {src: $EVENT_Grade.3dl, interpolation: linear} So I think pointing to colorspaces using context variables would make OCIO much more flexible. I hope this makes sense... Regards. Donat Van Bellinghen
On Thursday, June 12, 2014 3:10:34 PM UTC+2, dbr/Ben wrote:
|
|
|
|
Re: Problem in CDL implementation
dbr/Ben <dbr....@...>
Could some sort of generic string->string dictionary parameter be added to FileTransform that would be passed to each of the readers? This was discussed a while ago in "[ocio-dev] FileTransform interface changes", ..and would become a nonissue with (fairly large) change implemented: On 29/05/2014, at 2:54 AM, rmi...@... wrote:
|
|
|
|
Re: Yaml related warning message when compiling OCIO
dbr/Ben <dbr....@...>
Belated reply, but, those warnings can (hopefully) be ignored if you are just building OCIO
toggle quoted messageShow quoted text
The problem is because "Config::getNumEnvironmentVars" returns an "int", when it should probably return an "unsigned int" (because there can't possibly be negative number of env-vars). The warning occurs because comparing int with unsigned int can act in strange ways (like claiming -5 is greater than 2)
On 01/05/2014, at 4:41 AM, etienne....@... wrote:
|
|
|
|
Re: Using environment variables/context to point to a colorspace
dbr/Ben <dbr....@...>
Made a ticket about this,
toggle quoted messageShow quoted text
As an alternative, could you do something with Python in Nuke? Maybe a menu item or addOnUserCreate callback which automatically creates the appropriately configured OCIOColorspace node - Ben
On 12/06/2014, at 2:38 PM, Robert Minsk wrote:
|
|
|
|
Re: Using environment variables/context to point to a colorspace
Robert Minsk <rmi...@...>
Unfortunately the current version of OCIO only uses context variables when resolving file paths. Context variables are only used in search paths and the src parameter for a FileTransform.
On Wednesday, June 11, 2014 4:14:36 PM UTC-7, do...@... wrote:
|
|
|
|
Re: Good Morning!
Robert Minsk <rmi...@...>
Looking at the code OCIO implements Matrix*RGBA (column vector). In matrix operations RGBA*transpose(matrix) = matrix*RGBA. If you feel you are getting the wrong multiplication order then try using the transpose of the matrix.
On Wednesday, June 11, 2014 6:40:33 AM UTC-7, Joshua Jackson wrote:
|
|
|
|
Using environment variables/context to point to a colorspace
do...@...
Hi, I did post this question to OCIO-users and did not get any reaction, so I'm trying here as it might be a question related to development. Anyway I'm sorry if this is against posting rules. I've been implementing OCIO at our company. Thanks a lot for your efforts with this project, it is making things a lot easier for me, and more future proof. I'm using per-shot viewer luts using context variables inside the OCIO nodes in Nuke. That works like it is supposed to. I'm facing some difficulties from the fact that on our projects (mostly television commercials) we frequently get footage shot with different cameras. I'd like to find a system to avoid having to tell the artist which camera has been used for which shot. I'd like to define a 'CameraRaw' colorspace that would point to other colorspaces in function of a context. So for example I would define it like this : - !<ColorSpace> name: CameraRaw family: "" equalitygroup: "" bitdepth: 32f description: | Camera Raw depends on context isdata: false allocation: uniform allocationvars: [-0.125, 1.125] from_reference: !<ColorSpaceTransform> {src: linear, dst: $CAMERARAW} I tried this and in Nuke I used an OCIO colorspace node, setting the out colorspace to CameraRaw, and setting the context of the node of key1 =CAMERARAW and value1 = Alexa_Rec709 Of course the Alexa_Rec709 colorspace is also defined in the config file. When I do this get an error from Nuke's viewer. OCIOColorSpace1: BuildColorSpaceOps failded, null dstColorSpace. I'm not sure this is a bug report or a feature request. Anyway I think it would be quite valuable to be able to use context variables/environement variables to not only point to files on the disk but to other colorspaces as well. Regards Donat Van Bellinghen
|
|
|
|
Good Morning!
Joshua Jackson <joshua.a...@...>
My name is Joshua Jackson. I'm writing a custom configuration with ocio and have a quick question: Can I apply Matrix Transforms in a different order than RGB x MTX x etc... ? For Chromatic Adaptation Transforms, it is neccessary to apply a matrix in a different order to the given RGB/XYZ/etc. ( MTX x RGB x etc.) Thank you so much for your time! Joshua Jackson Executive Producer________________________________________
|
|
|
|
No way to retreive "non-active" displays
Robert Minsk <rmi...@...>
If I have a config with displays "a", "b", "c" and an active_display list of "a" there is no way to get to displays "b" and "c". In fact reading in a config file and writing it back out will only write out display "a". Should we add a methods to get the total number of displays not filtered by the active list and a method to retrieve the "non-active" displays?
|
|
|
|
Re: Building "universal" binaries for MacOS
Andrea Mantler <man...@...>
Success! Now to make sure I have the same version on linux (in case anything else changed from 1.0.9), then build for Windows (fingers crossed that there's no glitches there!), and I'm ready to start integrating it into our software!
On Friday, May 30, 2014 1:51:06 PM UTC-5, rmi...@... wrote:
|
|
|
|
Re: Building "universal" binaries for MacOS
Andrea Mantler <man...@...>
Thanks!
toggle quoted messageShow quoted text
On Friday, May 30, 2014 1:51:06 PM UTC-5, rmi...@... wrote:
|
|
|
|
Re: Building "universal" binaries for MacOS
rmi...@...
If you do another pull the cmake file should use the internal lcms by default.
On Friday, May 30, 2014 10:19:00 AM UTC-7, Andrea Mantler wrote:
|
|
|
