|
Re: Reversed transform for a OCIO::DisplayTransform
Joseph Slomka <joseph...@...>
Remember that colorspaces can be defined to and from the reference. You can manually define the inverse and come up with an inverse 3d lut for the color picker that is close enough to fully inverted. I don't believe that OCIO inverts any 3d luts, even if you had a unity lut where rgb in = rgb out. Typically the design of OCIO does not automatically do anything that will get you into trouble. You have to deliberately make those choices. Example code below. -Joseph cs = OCIO.ColorSpace(family='kodak',name='kdk2383') cs.setDescription("kdk2383: Kodak Vision stock") cs.setBitDepth(OCIO.Constants.BIT_DEPTH_UINT10) # this sets the conversion to reference XYZ from film log groupTransform = OCIO.GroupTransform() groupTransform.push_back(OCIO.FileTransform('2383_to_bt1886.3dl',interpolation=OCIO.Constants.INTERP_LINEAR)) groupTransform.push_back(OCIO.ColorSpaceTransform(src='bt1886', dst='lxyz')) cs.setTransform(groupTransform, OCIO.Constants.COLORSPACE_DIR_TO_REFERENCE) config.addColorSpace(cs) # this sets the conversion from reference XYZ to film log values groupTransform = OCIO.GroupTransform() groupTransform.push_back(OCIO.ColorSpaceTransform(src='lxyz', dst='bt1886')) groupTransform.push_back(OCIO.FileTransform('bt1886_to_2383.3dl',interpolation=OCIO.Constants.INTERP_LINEAR)) cs.setTransform(groupTransform, OCIO.Constants.COLORSPACE_DIR_FROM_REFERENCE) config.addColorSpace(cs)
On Fri, Apr 11, 2014 at 4:29 PM, Kevin Wheatley <kevin.j....@...> wrote:
|
|
|
|
Re: Reversed transform for a OCIO::DisplayTransform
Kevin Wheatley <kevin.j....@...>
As Piotr points out this is in general not mathematically possible, in particular if any LUTs are not invertible, you'll not be able to do this. in a 1D sense imagine if you have a curve which has a turning point which results in there being multiple cases where two values of x give y having the same value, when generalised into a 3D LUT this problem becomes even more difficult to invert in a general sense even in typical outputs this is not necessarily going to give you predictable outcomes (typical for a display transform emulating another device/output especially a subtractive one like film prints or other CMY(K) outputs). These 3D luts often feature gamut compression which is where a lot of the loss comes from. In specific cases there can be techniques to invert, but these need hand selecting, which is probably why OCIO won't do it, something like Argyll CMS or another ICC profile tool might do something for you, which might be interesting to implement, alternatively the CTL code has a scattered data interpolation code that might work.
Kevin
On Fri, Apr 11, 2014 at 10:29 PM, Piotr Stanczyk <piotr.s...@...> wrote:
|
|
|
|
Re: Reversed transform for a OCIO::DisplayTransform
Piotr Stanczyk <piotr.s...@...>
From what I remember, you can do this if the transforms are analytical. If you are referring to a baked in file based one then you will have to provide your own from for that. Piotr
On 11 April 2014 10:24, Dmitry Kazakov <dimu...@...> wrote:
|
|
|
|
Reversed transform for a OCIO::DisplayTransform
Dmitry Kazakov <dimu...@...>
Hi, all! I am a developer of Krita [0] painting
application and we use OCIO for displaying wide range images. I'm having
a bit of a problem now. Since we are a painting application, we need to
be able not only to display a color on screen (which we do using
DisplayTransform), but also to pick an already displayed color back into
app (for usage in color selectors or for drag-and-dropped colors). So,
effectively, I need to get a reversed transform for a DisplayTransform.
But it seems to be explicitly prohibited (it throws an exception in the
case). I'm wondering, is it possible to get a reversed transform for a
DisplayTransform without reimplementing it completely using
GroupTransform? Thank you in advance! -- Dmitry Kazakov
|
|
|
|
Uses of OCIO Looks?
Rod Bogart <bog...@...>
If you are using Looks heavily (and successfully), I’d like to hear from you.
Currently, the documentation is somewhat inaccurate on the format of the definition and usage of Looks, so I’m wondering to what degree folks have taken advantage of them. They seem to be a great way to build pipelines with intentional steps (i.e. separate operations for Neutral Grades and Primary Grades followed by an overall Show Look). The specification of process_space is super helpful to allow LUTs to operate on the kind of data they expect. And they can be applied with +/- to allow specific inversion setups. So, that’s all good. Any info you can share would be appreciated: positive results, hassles, example configs, whatever. Thanks in advance, RGB
|
|
|
|
Re: Allow config's context to be replaced?
Nathan Rusch <natha...@...>
Ah cool, that could be quite handy. Just for posterity, the biggest problem with trying to take a dynamic approach in Nuke is timing. Ideally, when a user opens a script, one would be able to look at the incoming script path, decide what config they need, load it into the process environment, and then proceed to load the script. However, because the `onScriptLoad` callback currently runs after all of the nodes being loaded from the script have been created, swapping out the config will screw up any saved knob values on config-dependent OCIO nodes. I've requested the current callback be broken into beforeScriptLoad and afterScriptLoad callbacks, but I'm not very optimistic about a change like that ever being implemented. It's possible to handle most of the cases where switching is required by monkey-patching nuke.scriptOpen with your own function and handling things in there, but in the end, the $OCIO environment variable is the only foolproof way to go. -Nathan
On Thursday, February 6, 2014 7:21:45 PM UTC-8, Jeremy Selan wrote:
Cool.
|
|
|
|
Re: OSX 10.9 compile expectations?
Rod Bogart <bog...@...>
Agreed. I inserted unistd.h above the #elif, and it compiles fine on 10.9.
toggle quoted messageShow quoted text
RGB
On Feb 9, 2014, at 5:23 PM, Colin Doncaster <colin.d...@...> wrote:
|
|
|
|
Re: OSX 10.9 compile expectations?
Colin Doncaster <colin.d...@...>
It looks like PathUtils.cpp needs unistd.h included.
toggle quoted messageShow quoted text
Looking at the source there’s: #if defined(__APPLE__) && !defined(__IPHONE__) #include <crt_externs.h> // _NSGetEnviron() #elif !defined(WINDOWS) #include <unistd.h> extern char **environ; #endif so I’m not too sure how one would want to rework those conditionals. Mavericks headers are closer to Linux now, there’s a few projects I’ve rebuilt now that require the __APPLE__ defines to compile. Cheers
On Feb 8, 2014, at 6:14 PM, Rod Bogart <bog...@...> wrote:
|
|
|
|
Re: Digest for ocio...@googlegroups.com - 3 Messages in 1 Topic
Joseph Goldstone <jgold...@...>
On Feb 9, 2014, at 12:43 PM, <ocio...@...> <ocio...@...> wrote:
No, but 338 does:
Rod, if you can have a go at this, it would be much appreciated; I’ve lived in a Mac monoculture for so long that I have no clue how to produce modern portable headers.
—joseph
|
|
|
|
Re: OSX 10.9 compile expectations?
Rod Bogart <bog...@...>
Thanks.
toggle quoted messageShow quoted text
Yes, it is the master branch. I have not yet spent time on the fix, but I believe you are correct; it should just be headers. RGB
On Feb 8, 2014, at 4:46 PM, Jeremy Selan <jeremy...@...> wrote:
I haven't yet updated by OSX dev machine to 10.9 yet, so unfortunately
|
|
|
|
Re: OSX 10.9 compile expectations?
Jeremy Selan <jeremy...@...>
I haven't yet updated by OSX dev machine to 10.9 yet, so unfortunately
toggle quoted messageShow quoted text
I can't test this at home. (Sounds like a good weekend project though). When I browse the open issues list, https://github.com/imageworks/OpenColorIO/issues?state=open there is a topic for compiliation problems on 10.9, https://github.com/imageworks/OpenColorIO/issues/340 but it doesn't mention getcwd. I'm not sure how you did the git checkout, but can you confirm if you're on master or instead the tagged 1.0.9 release? The sha for master is 63c6bde2, the sha for 1.0.9 is 2b12063e22 We'd very much welcome a patch if you'd like to take a stab at getting this working. (probably a simple header fix?) :) -- Jeremy
On Sat, Feb 8, 2014 at 3:14 PM, Rod Bogart <bog...@...> wrote:
Do we expect 10.9 to properly compile the git master version of OpenColorIO?
|
|
|
|
OSX 10.9 compile expectations?
Rod Bogart <bog...@...>
Do we expect 10.9 to properly compile the git master version of OpenColorIO?
Steps to reproduce: “Clone in Desktop” to download software Cmake (with defaults) to populate build dir cd build make [ 38%] Building CXX object src/core/CMakeFiles/OpenColorIO.dir/ParseUtils.cpp.o [ 39%] Building CXX object src/core/CMakeFiles/OpenColorIO.dir/PathUtils.cpp.o /Users/ocio/OpenColorIO/src/core/PathUtils.cpp:154:15: error: no member named 'getcwd' in the global namespace ::getcwd(path, MAXPATHLEN); ~~^ 1 error generated. Will continue to debug, but thought I’d ask if someone has been here first… RGB
|
|
|
|
Re: Allow config's context to be replaced?
Jeremy Selan <jeremy...@...>
Cool.
toggle quoted messageShow quoted text
In the medium term, we hope to do a cleanup of the OCIO API to make it easy to install as a system library in a binary compatible manner. That way, should similar circumstances arise again you could just load the latest OCIO on your system and then move the library that ships with the commercial app out of the way. If memory serves, Mari ships with a recent OpenColorIO.so, so if you have an install of that it would probably work to copy the .so from Mari into the Nuke install. -- Jeremy
On Thu, Feb 6, 2014 at 6:24 PM, Nathan Rusch <natha...@...> wrote:
Foundry bug ID is 40576 in case anyone comes across this later and wants to
|
|
|
|
Re: Allow config's context to be replaced?
Nathan Rusch <natha...@...>
Foundry bug ID is 40576 in case anyone comes across this later and wants to poke them about it.
On Thursday, February 6, 2014 9:54:26 AM UTC-8, Nathan Rusch wrote:
|
|
|
|
Re: Allow config's context to be replaced?
Nathan Rusch <natha...@...>
Thanks Jeremy. Good to know I'm not missing something. Unfortunately The Foundry have a tendency to drag their feet when it comes to updating third-party libraries, so they're still shipping OCIO 1.0.7 (even in Nuke 8... a little disappointing). I've got a request in with them, and I'll throw the reference number in this thread once I get one back in case anyone else wants to help apply more pressure. Tweak also seem to be using 1.0.7 in RV 4 as well. Anyway, 1.0.7 doesn't provide a Config.addEnvironmentVar method, so it looks like I may be stuck with replacing the config outright or swapping out the OCIO libraries that ship with Nuke. I'll hold out hope for the future though... Thanks again for the info. -Nathan
On Wednesday, February 5, 2014 9:44:01 PM UTC-8, Jeremy Selan wrote:
It was definitely our intent to have a setCurrentContext, that looks
|
|
|
|
Re: Allow config's context to be replaced?
Jeremy Selan <jeremy...@...>
It was definitely our intent to have a setCurrentContext, that looks
toggle quoted messageShow quoted text
like an oversight. In the meantime, can you see if your config object has a "addEnvironmentVar" option? This was introduced rather recently, so I am not sure if it's available in Nuke, but this would allow you to modify value of existing entries in the context, and also add new ones). -- Jeremy
On Wed, Feb 5, 2014 at 4:06 PM, Nathan Rusch <natha...@...> wrote:
Hey all,
|
|
|
|
Allow config's context to be replaced?
Nathan Rusch <natha...@...>
Hey all, I'm wondering if there has been any thought or discussion internally about allowing a config's Context to be replaced in place. I've been looking at ways to change the context variables of the active config on the fly using the Python bindings, and actually having them affect the existing processing environment, but after perusing the library and binding sources, it seems there isn't any way to do this currently. Some of the machinery is already there: You can get an editable copy of the active config's current context and modify its context variables to your heart's content. However, at that point, there isn't really anything useful you can do with that object unless you're actually doing color processing yourself. I was hoping to find a way to inject the updated context back into the currently active config via Python, to affect all future processor lookups within Nuke, but there's a distinct lack of symmetry to the interface in that regard. What I'm hoping for: config = ocio.GetCurrentConfig() ctx = config.getCurrentContext().createEditableCopy() ctx.setStringVar('FOO', 'BAR') config.setCurrentContext(ctx) # <-- The missing link Unless I'm mistaken, the only way to do something like this right now (at either the C++ or Python level) would be to modify the process environment (not ideal), and then call ocio.SetCurrentConfig(ocio.Config.CreateFromEnv()), which feels... dirty. Now, I'm guessing this isn't the first time you've crossed paths with an idea like this, so I feel like it's worth asking: Am I overlooking something blatantly obvious here? I've done my best to sniff out any existing functionality like this, but haven't found anything. However, if this is in fact a nonexistent feature, I'm wondering if there is a specific reason for excluding it, and if you would be willing to consider adding it in the future. Thanks for any information, -Nathan P.S. In the case of Nuke, I know it's possible to work around this using node-level context overrides and making Nuke do the environment lookups for you using TCL, but that's far from an ideal solution when a simple context replacement would let me do the same thing much more cleanly (and doesn't address other applications).
|
|
|
|
Re: OCIO 1.0.9 released
"Matteo F. Vescovi" <mfve...@...>
Hi again!
On 2014-01-17 at 17:33, Matteo F. Vescovi <mfve...@...> wrote: Actually, this version FTBFS as you can see at [1].[1] is now attached to avoid unavailability due to build machine refresh. Former versions didn't have this kind of problem.So, any advice? TIA. -- Matteo F. Vescovi Debian Maintainer GnuPG KeyID: 0x83B2CF7A Q29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9wZ3Atc2lnbmF0dXJlOyBuYW1lPSJzaWduYXR1cmUu YXNjIg0KQ29udGVudC1EZXNjcmlwdGlvbjogRGlnaXRhbCBzaWduYXR1cmUNCg0KLS0tLS1CRUdJ TiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYyLjAuMjIgKEdOVS9MaW51eCkN CkNvbW1lbnQ6IERlYmlhbiBwb3dlcmVkIQ0KDQppUUljQkFFQkNBQUdCUUpTNjhtQ0FBb0pFS1VH TmJ5L0FsZHNjYkVRQUorNXN0dDRqZlpNNmJUZ0hCSGtFVFg1DQo2N2FSUERxRWhwT2NWS2psK1V5 alozcDRESEZsMjFmYzUxemtKZ2FiNkhOeEFSUk8vYjB3NStmbjdFTHJnajBHDQpNR1NsQ0JxbERD VmI1RVEvZ2xxeEcxV0VKWDVPUHhtbHpQc0VJd0k2SGlTSkE5dnRGNHJBdEc5WXhpTlg3czdZDQpL M2w0bVJqdWlHSnVRd21HSGppNzdpa1pWMzBLQ2N0dU54QWVKdjM1SVFRTzRTeTlKWDZNVnA1bHhs dXQ5aXZuDQpYMzh1QWx0dTZDYmlmaE81a1JYekh1MWtOTUw3dFI2MXlvRHJHZ3hjOVVmU2loSlg5 N0VCWEZ3Ulg1eXhyalBQDQpTbTB6N05oTWIwYktyTUM2MTUrdXBhcmMyOGVVMVV2NnNMbllTczh6 Uk9qNlliNEs2Y2o4RlczMzJjMDIxTktsDQpqUXVZZ0pIdXBic0lwekpXOHhjTHoyUU9XNStrWURo d0hSN01PRG9LM3MyZmdKbVJGYUdpNHRjUXJYQ0pHdkFQDQpFUVJUekJVVmJOeEVDbjAzWVZZTGlu Z1pacDB4STZiOVpURmdIUy9uN3pBK1RZZWJDRGFJK1pDcHhoMXlON2pMDQpVaHlGeEtyWUZ3S2h3 UTFkaUVsMVdDS21nRXVwVkhIcnlHSGo5SEIzY3NKcFJBMWlpekc2MktFSkxVRjliVDB3DQpGajQ2 VjlOdmpacjVEalp6N1BUckJsU2wrSzQ5VkhFaE5odThLZFh1ek0ybDVEdUo5dUp4MzBoVmhUeSs2 VW1IDQptenFYb3lpQkJXLzIxcXlhVEJPSnBKRHBZbk55djBndFNSTndwaEJrdisrekh0WHJBUnEz VWNVN3VnOTg0cmQvDQpkb2NUY1NESFlMTWw4aU9MV2lpeg0KPTZOdG4NCi0tLS0tRU5EIFBHUCBT SUdOQVRVUkUtLS0tLQ0K
|
|
|
|
Re: OpenColorIO FTBFS on GNU/kFreeBSD boxes
Malcolm Humphreys <malcolmh...@...>
Hi Matteo can you checkout https://github.com/imageworks/OpenColorIO/pull/345 and see if this solves the issue for building against yaml-cpp-0.5.x? before we merge this into master. .malcolm
On 12/12/2013, at 2:41 PM, Matteo F. Vescovi wrote:
|
|
|
|
Re: An Academy Award for OpenColorIO!
Andrew Britton <andrew.d...@...>
Congrats and great job! - this message sent using an e-approved device
|
|
|