|
Re: icc profile for photoshop
Kevin Wheatley <kevin.j....@...>
On Fri, Jan 20, 2017 at 3:59 AM, <lrs...@gmail.com> wrote:
Now's the time to make better ICC profiles ?! Whilst I'm don't think OCIO has perfect ICC support, I'm not sure what you propose is even possible. Last time I read the ICC specifications the only options for profile connection space are L*a*b* and XYZ, neither of which have any limits which prevent you using 2020 gamut - I certainly have profiles using ACES AP1 which is wider than 2020. Could you describe what you are trying to do? As a random guess are you perhaps relying on the inbuilt sRGB display profile, when really you need a wider one? Kevin
|
|
|
|
ACES 1.0.2 and 1.0.3 configs in the Sony repo
Haarm-Pieter Duiker <li...@...>
Hello OCIO-ers, The ACES 1.0.2 and 1.0.3 configs were accepted into the main OCIO repo this weekend. The 1.0.3 config includes the latest 1.0.3 transforms, including the sRGB Output Transform, some updates to organization that should be helpful to newcomers and updates to the Input Transforms for ARRI, Canon and Red. One thing to note, the names of a few colorspaces changed as follow:
Please post OCIO-specific issues here and ACES-specific issues on acescentral.com Thanks! HP
|
|
|
|
Re: OCIO - Path Forward
Larry Gritz <l...@...>
TravisCI supports OSX and Linux.
toggle quoted messageShow quoted text
On January 17, 2017 5:56:34 AM PST, Ben De Luca <bd...@...> wrote:
--
Larry Gritz l...@...
|
|
|
|
Re: OCIO - Path Forward
Ben De Luca <bde...@...>
Absolutely pick the best thing, the only real benefit to what I am providing is I can give you exactly the environment that you want if its not provided by one of the cloudy tools. I don't believe any of them supported OSX. Its would be running on my virtual CI infrastructure.
On 16 January 2017 at 23:52, Larry Gritz <l...@...> wrote:
|
|
|
|
Re: OCIO - Path Forward
Larry Gritz <l...@...>
I don't have any Jenkins experience, but Travis is pretty straightforward and I've really come to rely on it for my open source projects. It's a big boost to know before you merge something that it's been built and passes tests on a matrix of several platforms, compilers, and build options. Well worth the time investment to get it set up. Appveyor is also helpful as the rough equivalent on Windows.
|
|
|
|
Re: OCIO - Path Forward
Sean Cooper <se...@...>
@ben, though iId look into the other contributors opinion on TravisCI vs. Jenkins
On Mon, Jan 16, 2017 at 12:37 PM, Sean Cooper <se...@...> wrote:
|
|
|
|
Re: OCIO - Path Forward
Sean Cooper <se...@...>
That would be great if you have the cycles!
|
|
|
|
Re: OCIO - Path Forward
Ben De Luca <bde...@...>
On the CI front I can provide windows Linux and mac systems plus Jenkins if you want.
On Fri., 13 Jan. 2017 at 1:40 am, Sean Cooper <se...@...> wrote:
|
|
|
|
Re: OCIO - Path Forward
Sean Cooper <se...@...>
Whoops, try giving it another go
On Thu, Jan 12, 2017 at 3:39 PM, Deke Kincaid <dekek...@...> wrote:
|
|
|
|
Re: OCIO - Path Forward
Deke Kincaid <dekek...@...>
You probably have to move the file to your personal gmail. Google docs are not view-able outside of our domain either.
On Thu, Jan 12, 2017 at 3:38 PM, Deke Kincaid <dekek...@...> wrote:
|
|
|
|
Re: OCIO - Path Forward
Deke Kincaid <dekek...@...>
You need permission This form can only be viewed by users in the owner's organization. Try contacting the owner of the form if you think this is a mistake. Learn More.
On Thu, Jan 12, 2017 at 3:33 PM, Sean Cooper <se...@...> wrote:
|
|
|
|
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.
|
|
|
