|
Re: OCIO - Path Forward
Sean Cooper <se...@...>
Here is a form to get an invite for the OpenColorIO Slack channel, I'll add them manually from there. We're looking to keep it to the smaller group of core owners/contributors, though feel free to invite whomever you think would help the cause! https://goo.gl/forms/Lq9buvEJg2qzJzq03 |
||
|
|
||
|
Re: OCIO - Path Forward
Sean Cooper <se...@...>
Thanks, yeah I should have linked the PR in the post. I'll try and get more eyes on that to test, though I'm sure it's fine, then we can pull that through to get things kicked off. As for Labels, I'd just like to get a better organizational structure that guides users attention a little better. My gut feeling is pushing towards a slimmed down version of this: https://medium.com/@dave_lunny/sane-github-labels-c5d2e6004b63#.3kx74xshg |
||
|
|
||
|
Re: OCIO - Path Forward
dbr/Ben <dbr....@...>
This all sounds good to me! I would be happy to help out auditing/tagging the issues in GitHub. The current labels seem fairly reasonable to me - "feature" for new things, "bug" for bugs, internal for non-user-impacting things, a label to flag API breaking changes, and "deferred" for future things. I'd probably add tags for performance improvements, docs, and build related issues. Then along side these, maybe tags for tag "easy" quick-to-fix issues, low/high priority tags) Regarding CI, There is a pull request to fix up the TravisCI config (#415). It would also be worth investigating Appveyor to test on Windows also Sent from my phone On 12 Jan 2017, at 11:12, Sean Cooper <se...@...> wrote:
|
||
|
|
||
|
Re: OCIO - Path Forward
Sean Cooper <se...@...>
Troy, would you be able to wrap this into an Issue on GH? With the coming addition of labels, this will be classified as a feature request. On Wed, Jan 11, 2017 at 5:03 PM, Troy Sobotka <troy.s...@...> wrote:
|
||
|
|
||
|
Re: OCIO - Path Forward
Troy Sobotka <troy.s...@...>
On Wed, Jan 11, 2017, 5:42 PM Sean Cooper <se...@...> wrote:
On a practical "get things done with the library" sense, it would be excellent to deal with OCIO for colour managing UI elements. Having spent plenty of time ramming into the problems, I believe that can be elegantly accomplished by: A) Providing metadata on the chromaticities for each Display cluster, or possibly per View? B) Providing metadata on the reference chromaticities. C) Provide some form of metadata that differentiates the transfer function portion of a view transform from any other colorimetric transforms. This would be needed for colour pickers and other things, where one needs to know the colorimetry of the reference and the destination, as well as how to apply *only* the transfer function to the UI element, post transform. Gradient UIs, color pickers, coloured sliders, etc. Many transforms are going to be of the transfer function variety, and it makes sense to tackle UI in the least invasive manner possible, hence limiting the metadata to the fewest possible areas makes sense? Per transform seems overkill unless a sane metadata structure can be arrived at that wraps up the needs. With respect, TJS |
||
|
|
||
|
OCIO - Path Forward
Sean Cooper <se...@...>
Hello all, and happy new year! I'd like to start a formal discussion around the steps we will take to give OCIO a breath of life. Hopefully we can work to make 2017 a year of progress. So in that spirit I'd like to layout a general game plan for comment and discussion. General Notes:
Game Plan:
Please join me in conversation about the future of OCIO! All of the above is open to suggestion and critique. Sean |
||
|
|
||
|
Re: LUT for linear exr to rec709
Sean Cooper <se...@...>
Hi Meiwa, It's a bit hard to remotely debug from the info you've provided, but the general answer is that you'd want to bring your Linear source (presumably in Arri Wide Gamut primaries) into a V3LogC space. Depending on the tools at your disposal you should be able to do this in most grading applications and in Nuke's native "colorspace" node, or uses OCIO's ACES 1.0.1 config. Then use the ARRI Lut Generator, but coming from LogC source instead of Sensor Linear.On Tue, Dec 13, 2016 at 4:21 AM, <mei...@...> wrote:
|
||
|
|
||
|
Re: LUT for linear exr to rec709
mei...@...
Dear Andrew, I have tried the lut generator, from normalized sensor linear to video, but it fails to get a correct outcome. The output lut generate an over-expose image. Is that because there is difference between "scene linear" and "normalized sensor linear"? I have the situation here same with Matt, hope find out solution asap. Thanks, Meiwa On Thursday, November 12, 2015 at 12:09:15 AM UTC+8, Andrew Britton wrote:
|
||
|
|
||
|
Re: link problem with Visual Studio 2012
Paul Miller <pa...@...>
On 12/5/2016 4:12 PM, Dithermaster wrote:
Is this 32-bit or 64-bit? If 32-bit, did you change the default callingNo, 64 bit only. I used the default cmake settings, though I did run cmake and build with cygwin in my path (so "patch" would work when building tinyxml). I'll look into the v0 vs v1 issue - that looks like it may be the culprit.
|
||
|
|
||
|
Re: link problem with Visual Studio 2012
Dithermaster <dither...@...>
Is this 32-bit or 64-bit? If 32-bit, did you change the default calling convention in your project (__cdecl vs __stdcall)? Undecorated headers with .lib files that use the default convention will fail if you've changed the default convention. In 64-bit this is moot since it's all __fastcall. On Mon, Dec 5, 2016 at 12:42 PM, Jeremy Selan <jeremy...@...> wrote:
|
||
|
|
||
|
Re: link problem with Visual Studio 2012
Jeremy Selan <jeremy...@...>
Are you using the proper generated headers? Are you overriding so version in CMake? All the symbols are in OpenColorIO::v0, and I would expect them to be in v1 (corresponding to the major version). #define OCIO_NAMESPACE_ENTER namespace OCIO_NAMESPACE { namespace OCIO_VERSION_NS
set(OCIO_VERSION_MAJOR 1) set(OCIO_VERSION_MINOR 0) set(OCIO_VERSION_PATCH 9) set(SOVERSION ${OCIO_VERSION_MAJOR} CACHE STRING "Set the SO version in the SO name of the output library") On Mon, Dec 5, 2016 at 10:24 AM, Paul Miller <pa...@...> wrote: I'm in the twilight zone today. After a bad merge from Mac->Windows, my application will no longer link against the shared OpenColorIO.lib on Windows, using Visual Studio 2012. This is the exact same set of headers and .lib I've been using for over a year. |
||
|
|
||
|
link problem with Visual Studio 2012
Paul Miller <pa...@...>
I'm in the twilight zone today. After a bad merge from Mac->Windows, my application will no longer link against the shared OpenColorIO.lib on Windows, using Visual Studio 2012. This is the exact same set of headers and .lib I've been using for over a year.
The link errors are all like this one: error LNK2019: unresolved external symbol "__declspec(dllimport) public: static int __cdecl OpenColorIO::v0::FileTransform::getNumFormats(void)" (__imp_?getNumFormats@FileTransform@v0@OpenColorIO@@SAHXZ) and there seems to be an error for every OCIO function or definition I make use of, including: error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_DATA" (__imp_?ROLE_DATA@v0@OpenColorIO@@3PEBDEB) error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_COLOR_PICKING" (__imp_?ROLE_COLOR_PICKING@v0@OpenColorIO@@3PEBDEB) error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_SCENE_LINEAR" (__imp_?ROLE_SCENE_LINEAR@v0@OpenColorIO@@3PEBDEB) Just for fun I cloned the current OCIO master branch, ran cmake on it, and rebuilt. I did have to make one change to OpenColorABI.h, and that is to get it to use <memory> and std::shared_ptr instead of boost or the tr1 stuff: #elif defined(_LIBCPP_VERSION) || defined(WIN32) #include <memory> #define OCIO_SHARED_PTR std::shared_ptr #define OCIO_DYNAMIC_POINTER_CAST std::dynamic_pointer_cast But that's a minor change. I'm linking with OpenColorIO.lib, but the linker is acting like nothing is being exported from it. Has anyone else experienced anything like this? |
||
|
|
||
|
Re: OCIO Configuration Reference Values
Troy Sobotka <troy.s...@...>
On Tue, Oct 25, 2016 at 3:25 PM Malcolm Humphreys <malcolmh...@...> wrote: The basic idea would be to add a header chromaticities field and retire the luma field along with adding metadata fields per ColorSpace for both chromaticities and luminance (as cd/m^2). This strikes me as clean, sensible, and very viable in short term. I also believe that this discussion could wander off into colour quackery and OCIO bloatification without keeping a guiding bit of design question in front of us. Namely: Q: "What is the design problem we are seeking to solve?" This is why I originally asked the question, and I can give a pretty clear answer: A:"How to make user interface elements and algorithms perform and display colour correct and accurate output?" If we take a simple HSV wheel, we can see that the values will not be aligned with the reference space without some problems. If we lay out the UI element, we could assume the values are in reference, scene referred, and roll it to the view chosen. The only problem with this is that the imager gets a particular transfer baked version of it, albeit properly transformed to the view from the reference in terms of chromaticities. If an imager tries to flip to a linearized transfer version of HSV, or a log encoded transfer, or another particular transfer, etc., the problem becomes much more complex. I see the following problems: *) How can we strip off the transfer function from a view and apply the image's desired transfer function to the UI element? *) How can an application / OCIO deduce what is a transfer function versus any other transform so that an application can present a sane list of options for the transfer options? *) How can an application apply a display correction to a view, after the above concerns? (IE Keep display corrections completely isolated from the view transform knot.) Extending this to the views, or per set of views under a display, is a halfway solution to solving the UI element issue. The transfer function problem isn't an easy one to solve, and as such I'd be interested to hear wise minds on how to tackle it with a shortest-path solution. I was thinking that the basis of the look modifiers on the views (+ and - to add or remove looks) could be useful to perhaps extend to transforms and get transfer function versus scene / display linear versions? Malcolm's reference metadata certainly solves the algorithm-dependent problems immediately, and is not terribly invasive. It should likely also be *mandatory* that trunk forward versions of OCIO force this definition such that an application and lean on the metadata to be present. A *huge* plus one to see this land as soon as possible. Thoughts? TJS |
||
|
|
||
|
Re: OCIO Configuration Reference Values
Thomas Mansencal <thomas.m...@...>
> I worry that trying to interleave color math into OCIO as a first class feature will a) open up a can of worms and b) actually limit OCIO's flexibility. Yes, this is exactly my concern and the reason why I joined the conversation. I quite like the minimalistic, almost agnostic approach of OCIO so far and if you introduce primaries, whitepoint, CAT support, the question of performing colour math is to be brought on the table. You might end up with some interesting issues to ensure consistency between your primaries, whitepoint, CAT specification and the matrices you define in the ColorMatrixTransform if no math is to be involved. We have been there with Colour and it has required a bit of work. Discrepancies might not be a big problem for OCIO, but it is something to be aware of. Cheers, Thomas On Wed, Oct 26, 2016 at 3:15 PM Andy Jones <andy....@...> wrote:
|
||
|
|
||
|
Re: OCIO Configuration Reference Values
Andy Jones <andy....@...>
(a) like in the example above metadata.chromaticties.red and start to add the set()/get() interface now. I like option A. I worry that trying to interleave color math into OCIO as a first class feature will a) open up a can of worms and b) actually limit OCIO's flexibility. Personally, I'd rather see OCIO remain an open-ended color transform framework that supports the kinds of metadata users need for interoperability with other color frameworks, but doesn't limit it to specific metadata tags, or specific interpretations of those tags. That's not to say I'm against encouraging more robust color management, but I think OCIO should draw a line in the sand and stick to facilitating, rather than enforcing the use of colorimetric relationships, and only move that line forward very carefully--if at all. Otherwise, it would be easy to end up simply duplicating the efforts of ICC and/or ACES. I think the metadata structure in Malcolm's example is immediately useful in its own right, and that's pretty much what I was imagining. I also think there is room for a global metadata structure, which could allow the config to define values like the "reference_chromaticities" in Malcolm's example, without having to add a new first class tag at the root. The significance of a token being defined in a metadata map would simply be that OCIO itself will not interpret the data, but will make it available as-is. Since the files are yaml-based, it might also be interesting to allow for the use of yaml anchors during parsing. That would allow for explicit use of values defined as metadata elsewhere in the file. For example, you could de-reference the colorspace chromaticities, and the reference chromaticities in a "CATTransform" plugin without having to define them twice, and without relying on any behind-the-scenes metadata query, or brittle reliance on naming conventions for the metadata tags. Lastly, although it wouldn't be required for adding arbitrary metadata tags, I do also support the idea of transform operator plugins and generalizing the API access for operator attributes as a longer term goal. That seems like it just makes sense. |
||
|
|
||
|
Re: OCIO Configuration Reference Values
Malcolm Humphreys <malcolmh...@...>
Hi,
toggle quoted message
Show quoted text
Sorry I have been a bit busy getting up to speed with a job. I have been musing some ideas with Robert Molholm about this separately and wanted to mention it to see what you think. The basic idea would be to add a header chromaticities field and retire the luma field along with adding metadata fields per ColorSpace for both chromaticities and luminance (as cd/m^2). Then add a CATTransform which can read this metadata. I would also like to add a find colorspace by chromaticities to help support image files that have this metadata. The main advantages to this are you have control on where chromaticities are used within the transform list per colorspace and it also allows you to have ColorSpaces with chromaticities metadata but are just extra descriptive data (so you don’t have to have messy flags to respect them or not). For example it could look something like this in a profile: … reference_chromaticities: red: [0.6400, 0.3300] green: [0.2100, 0.7100] blue: [0.1500, 0.0600] white: [0.3127, 0.3290] … - !<ColorSpace> name: AdobeRGB bitdepth: 8ui metadata: chromaticties: red: [0.6400, 0.3300] green: [0.2100, 0.7100] blue: [0.1500, 0.0600] white: [0.3127, 0.3290] luminance_max: [160] luminance_min: [0.5557] description: | AdobeRGB blah allocation: uniform allocationvars: [-0.125, 1.125] to_reference: - !<ExponentTransform> {value: [2.2, 2.2, 2.2, 1]} - !<CATTransform> {method: “bradford”} … Things I am still pondering are about the goal of having a plugin support in terms of what the api and format looks like. ie. to support plugins the Ops would need to be exposed and the Transform interface needs to be generalised so a plugin could expose it’s paramaters (ie. you wouldn’t have a explicit interface CDLTransform.setSlope(foo) vs Transform(“CDL”).set(“slope”, foo)). If this was done to expose Op and Transform parameters it would make sense to do this for ColorSpace as well to make the api consistent. That is not likely to happen anytime soon but it begs the question should chromaticties and luminance be either: (a) like in the example above metadata.chromaticties.red and start to add the set()/get() interface now. or instead (b) put the chromaticties and luminance on the ColorSpace as first class citizens with explicit interfaces to be consistent but add a special case internally for getting these explicit fields. .malcolm On 25 Oct 2016, at 9:32 pm, Troy Sobotka <troy.s...@...> wrote: |
||
|
|
||
|
Re: OCIO Configuration Reference Values
Troy Sobotka <troy.s...@...>
On Tue, Oct 25, 2016, 11:54 AM Joseph Slomka <joseph...@...> wrote:
Agree. The question then is, how to specify the XYZ transform. I added it in the above patch in a manner much like the luma tag. Is this a workable step forward? It would seem that we could depreciate the luma tag and replace it with a mandatory XYZ tag with values. Is this reasonable as a toe-in-water step? With respect, TJS |
||
|
|
||
|
Re: OCIO Configuration Reference Values
Joseph Slomka <joseph...@...>
Troy, The shortest path is going to be an RP of having an CIE1931XYZ named space. There is a certain bit of manual glue required, as OCIO only manages image transforms and standardize the processing. The next shortest is making it a requirement, and having it fail a sanity check and throw a flag if not implemented. If it's agreed to then it should make it to the trunk. It sounds like OCIO needs more builds and more feedback to get user input and involvement. I am not a fan of a required role, but if it is a choice between that and dealing with dozens of VFX houses each with their own color management tools I'd much rather have required roles. The slightly longer path is to make a metadata component to OCIO that provides some minimal API to manage color state of images. Ideally OCIO would be the part of a project that manages color. It sounds like there is a need for a color management framework that track image state,executes logic and interacts with other color management systems. -Joseph On Mon, Oct 24, 2016 at 10:13 PM, Troy Sobotka <troy.s...@...> wrote:
|
||
|
|
||
|
Re: OCIO Configuration Reference Values
Troy Sobotka <troy.s...@...>
On Mon, Oct 24, 2016, 6:18 PM Joseph Slomka <joseph...@...> wrote:
My issue with best practices is that they will fail where not implemented, which means an entire user interface stack or potentially shaders, algorithms, and a whole slew of other things fall apart and suddenly break. I am wondering: 1) What is the shortest path to a workable solution for OCIO in the near term that works. 2) Whether such a solution can make it into trunk and become reference. Happy to see longer term goals here, but given that OCIO appeared to have been taken off of life support, only to resume critical condition weeks later, perhaps our goals should be modest at this juncture. Implementing a mandatory XYZ set of values for reference, with applicable warnings or failure would at least be an entry point? With respect, TJS |
||
|
|
||
|
Re: OCIO Configuration Reference Values
Joseph Slomka <joseph...@...>
Andy, The XYZ role solution is a good compromise. It would be a good recommended practice when .ocio profiles are created. The idea of creating application specific keywords and application specific color data sounds like it could lead to situations where different applications could get mismatched information for the same image state. So perhaps and tone mapping,chromaticity and other metadata data could be added as tags to describe the inputs and outputs of each OCIO transform. That data can then be passed to the system that is used to track image state and metadata. That system could then create application specific metadata from a more general image state description. On Mon, Oct 24, 2016 at 8:27 AM, Andy Jones <andy....@...> wrote:
|
||
|
|
