|
Re: OCIO 1.0.10
Sean Cooper <se...@...>
Hi Jep, I've recently added you, let me know if you don't get the email. On Fri, Jun 23, 2017 at 1:49 PM, <jep...@...> wrote:
|
|
|
|
Re: OCIO 1.0.10
jep...@...
Hi Sean, I'd love an invite to the Slack conversation, please. Cheers, Jep On Wednesday, April 26, 2017 at 10:31:50 AM UTC-7, Sean Cooper wrote:
|
|
|
|
Re: OCIO Windows build
Patrick Hodoul <patric...@...>
Pull request #392 could help you a lot. On Wednesday, May 3, 2017 at 4:05:50 PM UTC-4, scott jones wrote:
|
|
|
|
Re: OCIO Windows build
villa...@...
Sorry I don't have an answer, but I am trying to do the same thing and having no luck. Were you ever able to get it working? If I can figure it out I will post my findings. Thanks On Friday, September 30, 2016 at 1:29:33 AM UTC-7, tde wrote:
|
|
|
|
Re: OCIO 1.0.10
Larry Gritz <l...@...>
I'm not really a part of the OCIO dev community, so take my opinion with a grain of salt, but,
I agree that any discussion about design or big issues of implementation really should happen on the archived, fully public mail list. The asynchronous, think and compose before you write, nature of email actually is an important feature. Slack or other chat seems good for ephemeral, realtime collaboration, "how do I fix this, I need it in an hour", or a quick question/answer that need not be archived. Slack history may be searchable, but it seems to me that it's mainly geared toward conversations that are ok to be missed by people who happen not to be logged in at the time that they happen. It strikes me as the equivalent of an office hallway conversation -- very important to the daily life of a project, but not where any big decisions should be made.
|
|
|
|
Re: OCIO 1.0.10
DBR - Ben <dbr....@...>
I would be interested in joining the Slack channel (although I'd rather discussions happened "in the open" - only so discussion/decisions can be easily referenced in future. However as long as people are diligent in transcribing relevant discussions into this mailing list, or ticket comments etc, that would also be perfectly fine) In terms of bugs I'd like fixed for a future patch version, these are the major problems we've encountered with 1.0.9, or have patched around in our internal builds: Problems mainly in Nuke: 1. https://github.com/imageworks/OpenColorIO/issues/397 EnvExpand infinite recursion (querying an unset env-var in a OCIO Nuke node "context" value causes Nuke to freeze forever) 2. https://github.com/imageworks/OpenColorIO/issues/383 HDL baking broken when a look is specified 3. https://github.com/imageworks/OpenColorIO/issues/385 OCIODisplay channel selection dropdown order changed in Nuke 9+ Build problems: 4. https://github.com/imageworks/OpenColorIO/issues/340 CMake fixes for OS X builds (we also apply pull request #321 as it as it not part of any released version, but it is already merged in master) Additionally, this seems pretty bad, although is not something I have personally encountered (but only because the en_AU locale we use happens to be compatible enough): 5. https://github.com/imageworks/OpenColorIO/issues/297 parsers should explicitly set LOCALE On 28 April 2017 at 01:56, Michael Root <mi...@...> wrote:
|
|
|
|
Re: OCIO 1.0.10
Michael Root <mi...@...>
I'd really like to see https://github.com/imageworks/OpenColorIO/pull/381 or some equivalent in the next official release. I personally don't like closed-door development of open-source projects, and I don't find Slack at all appealing. That said, I'm not really a major contributor, so whatever helps keep the OCIO project moving is great. -miker On 04/26/2017 10:31 AM, Sean Cooper wrote:
|
|
|
|
Re: OCIO 1.0.10
zach....@...
Hey guys, I'd love to join the Slack channel (provided our corporate proxy will let me use slack :/ ) I'm really pleased to see forward momentum, both in terms of discussions and development. Thanks! Zach On Wednesday, April 26, 2017 at 1:31:50 PM UTC-4, Sean Cooper wrote:
|
|
|
|
OCIO 1.0.10
Sean Cooper <se...@...>
Hello all, With a little bit of movement on the OCIO repo working towards addressing the most egregious image-quality-effecting bugs, we need to look to locking off to a 1.0.10 to help our users, and product partners. If you haven't been watching, I invite you to take a look at the OCIO repo, and point out other image quality *bugs* that you deem a requirement for the next minor version. Prior to my involvement there have been a number of commits to master since 1.0.9, and I think it's beneficial to put a stake in the ground as a firm mark of rejuvenation. We can proceed from there. If you haven't joined in the side Slack conversation where more day-to-day conversation has been centered, please reply below or message me personally I am more than happy to invite you. Or if you have a strong opinion against the "closed-door" conversation, I am open ears. Thoughts, and opinions welcomed, thanks! Sean |
|
|
|
Re: Error loading lut using environment variables
Simon Björk <bjork...@...>
Thanks Sean! I'll have a look at this and do some tests. Seems like it could do the trick :).
|
|
|
|
Re: Error loading lut using environment variables
Sean Cooper <se...@...>
I'll also point to this: https://github.com/imageworks/OpenColorIO/issues/234 On Tue, Mar 14, 2017 at 8:33 AM, Sean Cooper <se...@...> wrote:
|
|
|
|
Re: Error loading lut using environment variables
Sean Cooper <se...@...>
Per-shot colorspaces are generally handeled by the OCIOLooks not OCIOColorspace. Additionally, with Looks you are able to use conditionals (atleast on unix, Id have to try it on other systems) So if you had a Look called "perShot" with a file transform pointing to /path/to/$SHOW/$SHOT.lut you can then apply the Look using a conditional like "perShot|" where if perShot fails it will do the pipe/OR and instead do nothing. You can even do more complicated combinations like "+look1|+look1+look2|". This is pretty specific to Looks that modify the view, but that's usually how shot-specific transforms are used. You might be able to use this for other purposes if that isnt your use case. On Mar 14, 2017 12:33 AM, "Simon Björk" <bjork...@...> wrote:
|
|
|
|
Re: Error loading lut using environment variables
Simon Björk <bjork...@...>
Thanks Kevin, seems like it would work. However (if I'm not misunderstanding) this would require all shot luts to be named the same and also be in separate directories? In my case I would prefer to have the luts named shot01.cube, shot02.cube etc and store them in the same directory (i.e /show/luts/shot_luts/). I guess I can just create a dummy lut if it doesn't exist as a pre launch process. /Simon
|
|
|
|
Re: Error loading lut using environment variables
Kevin Wheatley <kevin.j....@...>
Create a null lut is about the best you can do, combined with the search path you could do search_path: path/to/${SHOT}:path/to/null then use a name like "mylut.cube" if you squint hard you can make this do sequence level as well as show wide level, by suitable nesting of directories in search paths. Kevin |
|
|
|
Error loading lut using environment variables
Simon Björk <bjork...@...>
I'm trying to add a colorspace that is using a $SHOT env. It all works as expected if the shot lut exist. If the shot lut does not exist an error is thrown: The specified file reference '${SHOT}.cube' could not be located. The following attempts were made: D:\ocio_test\luts\sh001.cube If I start Nuke i get an error saying it can't load the config file. Is there anyway to get around this (without creating "dummy" luts)? Can if/else statements be used in the config somehow? It would be great if there was a way to skip the colorspace if the evaluated file doesn't exist. /Simon |
|
|
|
Re: Force a refresh of context variables?
Tobias Pfeiffer <pixeld...@...>
Hi guys, we were forcing Nuke restarts for a long time now just to make OCIO's context work for fresh opened scripts. This is really unconvenient and artist-unfriendly. Thats why I wanted to give fixing that problem a second try. Im not a fan of using the Viewer Process, because than you are incorporating software specific color transforms that do not properly work in other software packages (Maya, Max, Houdini). Isn't being software agnostic one of the main reasons to use OCIO in the first place? I fiddled around with the getCurrentContext method Mark outlined aboved and this seems to work quite easily. But how do I get Nuke to recognize that fresh and updated config? Any tips? Best, Tobias Am Donnerstag, 16. Januar 2014 20:00:50 UTC+1 schrieb Mark Visser:
|
|
|
|
Re: ICC Profile color space with XYZ PCS
joshua.a...@...
So...the "input" color space would be XYZ and the "output" would be device color space RGB when using ociobakelut? Is that what you're saying?
|
|
|
|
Re: ICC Profile color space with XYZ PCS
Brendan Bolles <bre...@...>
On Friday, March 3, 2017 at 4:20:36 PM UTC-8, Joshua Jackson wrote: Is it possible to use ocio to crest an icc profile that can fully define a color space with XYZ PCS like a classic srgb or adobe rgb profile? What getting at is that I've defined a device color space with XYZ conversion matrix, shaper LUT for nonlinear response, all RGB and white chromaticities, flare, etc. for a device and would like to use this as an ICC profile in After Effects to define input footage for color management in AE. For input footage, I'd recommend using the OCIO plug-in for After Effects. Depending on your parameters, there are many transformations that the current code can not bake into an ICC profile. Where you will really need profiles in After Effects is for setting up a project working space and display transform. The included PDF shows how you can do it all with the plug-in, but it's pretty cumbersome. Brendan |
|
|
|
Re: ICC Profile color space with XYZ PCS
Joseph Slomka <joseph...@...>
Joshua, It's not a problem to make a profile work as you envision it. All you need to is make the XYZ PCS space as the linear color space that each colorpspaces transfers to and from. -Joseph On Fri, Mar 3, 2017 at 4:20 PM, <joshua.a...@...> wrote: Is it possible to use ocio to crest an icc profile that can fully define a color space with XYZ PCS like a classic srgb or adobe rgb profile? What getting at is that I've defined a device color space with XYZ conversion matrix, shaper LUT for nonlinear response, all RGB and white chromaticities, flare, etc. for a device and would like to use this as an ICC profile in After Effects to define input footage for color management in AE. |
|
|
|
ICC Profile color space with XYZ PCS
joshua.a...@...
Sorry for the bad grammar, I'm attempting to type all of this on a phone...
|
|
|