|
Re: parseColorSpaceFromString() issue
Mark Boorer <mark...@...>
Hi, > May I suggest making parseColorSpaceFromString() optionally a little more strict? I'm certainly happy to add in this functionality if it makes your lives easier. > This is an especially egregious failure, considering that JPEG files are by specification LDR and sRGB (so very not "lnf"). As a quick aside, do many people use this functionality? I was under the impression that this was mostly an SPI thing (baking the colorspaces in to the filenames). Personally we use metadata / heuristics to determine which colorspaces our images are in. (eg, JPG files are sRGB, DPX's are in the camera's log space). If you feel like knocking up a pull request containing your patch, I'll merge it (assuming it's all good). Otherwise I'm happy to do so on your behalf. Cheers, Mark
On Wed, Oct 1, 2014 at 9:49 PM, Sean Looper <sean....@...> wrote:
|
|
|
|
Re: parseColorSpaceFromString() issue
Sean Looper <sean....@...>
I've been bitten by this as well. Ended up writing my own parsing function.
On Wed, Oct 1, 2014 at 1:43 PM, Larry Gritz <l...@...> wrote:
|
|
|
|
Re: parseColorSpaceFromString() issue
Larry Gritz <l...@...>
+1 on the suggestion of recognizing OCIO color spaces in the filenames only if they are fully delimited.
This is an especially egregious failure, considering that JPEG files are by specification LDR and sRGB (so very not "lnf"). On Oct 1, 2014, at 12:46 PM, Michael Root <mi...@...> wrote: May I suggest making parseColorSpaceFromString() optionally a little more strict?
--
Larry Gritz l...@...
|
|
|
|
parseColorSpaceFromString() issue
Michael Root <mi...@...>
May I suggest making parseColorSpaceFromString() optionally a little more strict? The basic problem is that as we're transitioning to using OCIO, there are still many situations where a file might have an OCIO colorspace in the filename....but it may also not have one. Even if strictparsing is true, the 'strictness' is still pretty lax. Any part of the filename that happens to line up with a colorspace suddenly becomes the colorspace. For example, parseColorSpaceFromString() returns: "dialogSync1020.0100.dpx" => "nc10" "brickKilnFront.jpg" => "lnf" "digiDoubleForeign1029.0100.dpx" => "gn10" May I suggest a config option like: delimiters: _./ Which would restrict the parser to only consider substrings delimited on both sides by one of those chars (or the beginning or end of the string). By default, delimiters is an empty string, which results in the current behavior. Attached is a patch against 1.0.9 that implements this idea. -miker
|
|
|
|
OSX 10.9 static build fails compiling ociocheck
andersl...@...
Hello, I'm trying to build 1.0.9 on OSX 10.9, but the build is failing compiling ociocheck: Linking CXX executable ociocheck To do the static build I'm just setting OCIO_BUILD_SHARED to OFF and OCIO_BUILD_STATIC to ON. libOpenColorIO.a is present in build/src/core, but isn't getting found, which is strange as I thought CMake was supposed to handle all that stuff. I'm also a little bit worried by this message: Linking CXX static library libtinyxml.a
If I manually add libOpenColorIO.a's path to the environment using link_directories() then it gets found, but then I get a stream of missing symbols: Undefined symbols for architecture x86_64:
(this carries on for what must be every single symbol in the library) Any ideas?
|
|
|
|
Re: advice, supporting dynamic color space additions to config
Steve Agland <sag...@...>
Yes, this is basically what I was thinking. It'd probably work for us.
On 26 September 2014 10:50, Haarm-Pieter Duiker <li...@...> wrote:
|
|
|
|
Re: advice, supporting dynamic color space additions to config
Haarm-Pieter Duiker <li...@...>
If you're working in a single facility and have some way of prompting configs to be regenerated, the Python API gives you most of the functionality needed for an inheritance model. Something along the lines of a 'global' config module which defined the base color spaces, views, displays and so on followed by show/shot/sequence specific modules that could import that global config module, use it to generate a Python config object and then modify that config object as necessary before writing the config to disk could work for a single facility. HP
On Thu, Sep 25, 2014 at 3:53 PM, Steve Agland <sag...@...> wrote:
|
|
|
|
Re: advice, supporting dynamic color space additions to config
Steve Agland <sag...@...>
I've also been thinking about the general idea of configs "inheriting" from one another. I haven't delved far into the API for manipulating configs yet, so perhaps there is some support there if you're okay with dynamically creating configs on the fly. It'd be great if there was a formal way to have a "global" config from which "show" configs (or some other more specific context) can be automatically derived with some overrides. Overrides could include defining new color spaces, limiting/extending the available display/view options, reassigning "roles" etc. Steve
On 26 September 2014 05:16, Haarm-Pieter Duiker <li...@...> wrote:
|
|
|
|
advice, supporting dynamic color space additions to config
Haarm-Pieter Duiker <li...@...>
Hello, I'm working on a project that has a base set of well-defined transforms and a more extended set of transforms/color spaces that are less well-defined. The 'less well defined' transforms are going to come from 3rd parties and will likely be delivered after a config including the main set of 'well-defined' transforms is locked down and released to a number of users. I'm hoping for a bit of advice from the list on the best approach to deploying this config, and potential feature additions to OCIO to support this situation (if they're deemed in the best interest of the overall project, of course). The options that I see are:
Are there better approaches to that problem? The 3rd party transforms aren't show, shot or sequence LUTs so just substituting LUT paths based on environment variables isn't enough. They will need to be named and differentiated from each other. Additionally, the number and names of the color spaces/transforms can't be known before the main config is released. This email was originally going to be a question about 'What happened to the idea of having an $include statement' but I figured that that was just the tip of the iceberg. Any thoughts or advice you can provide would be appreciated. Thanks, HP
|
|
|
|
ocionuke module different in nuke 9.0
Ashley Retallack <ashley.r...@...>
Hi guys I was wondering what the strategy is between the project and the Foundry as far as keeping python modules up to date etc. As I have found the there are changes to the ocionuke module included with nuke 9.0+ compared with the latest branch of OCIO. Which means in order to use our build of OCIO, we need to either merge these changes to our version or edit nuke to not call these new features. cheers Ash
|
|
|
|
building latest release w/ Visual Studio 2012
Paul Miller <pa...@...>
Trying to build master and the build process is failing trying to process tinyxml and yaml, such as this:
2>------ Build started: Project: tinyxml, Configuration: Debug x64 ------ 2> Building Custom Rule D:/paul/src/OpenColorIO/CMakeLists.txt 2> CMake does not need to re-run because D:\paul\src\OpenColorIO\build\CMakeFiles\generate.stamp is up-to-date. 2> Creating directories for 'tinyxml' 2> Performing download step (verify and extract) for 'tinyxml' 2> -- verifying file... 2> file='D:/paul/src/OpenColorIO/ext/tinyxml_2_6_1.tar.gz' 2>CUSTOMBUILD : -- verifying file... warning : did not verify file - no URL_HASH specified? 2> -- extracting... 2> src='D:/paul/src/OpenColorIO/ext/tinyxml_2_6_1.tar.gz' 2> dst='D:/paul/src/OpenColorIO/build/tinyxml-prefix/src/tinyxml' 2> -- extracting... [tar xfz] 2> -- extracting... [analysis] 2> -- extracting... [rename] 2> -- extracting... [clean up] 2> -- extracting... done 2> No update step for 'tinyxml' 2> Performing patch step for 'tinyxml' 2> 'patch' is not recognized as an internal or external command, 2> operable program or batch file. 2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(172,5): error MSB6006: "cmd.exe" exited with code 9009. ========== Build: 1 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== This later prevents the OpenColorIO target from building. I also tried with the frederikaalund:master pull request with the same results. Any suggestions?
|
|
|
|
Re: OS X 10.9 build/link issues w/ XCode 5.1.1
Mark Boorer <mark...@...>
Hi Paul,
toggle quoted messageShow quoted text
Could you perhaps copy in the link errors here? Also are you building OCIO with the same C++11 features enabled? Cheers, Mark
On Fri, Sep 5, 2014 at 4:14 PM, Paul Miller <pa...@...> wrote:
I'm trying to use OCIO with an application built with XCode 5.1.1.
|
|
|
|
OS X 10.9 build/link issues w/ XCode 5.1.1
Paul Miller <pa...@...>
I'm trying to use OCIO with an application built with XCode 5.1.1.
I can configure and build OCIO fine, but when I try to link it into my application there are link errors. I'm not using boost pointers, but standard C++11 pointers, in both places. Anyone else have a similar issue?
|
|
|
|
How to use OCIO::ROLE_COLOR_PICKER
Antony Riakiotakis <kal...@...>
Hi, I'm trying to hook up OCIO properly to blender's color picker system and allow choosing an arbitrary color tranform before uploading the color picker colors to our display device. In blender, by default, we have a standard linear reference color space with srgb primaries, and our display transform is non-linear srgb. The issue I am having is that I suspect that defining a color picker color space and then defining a processor from that space to display space will not help at all since it will void the transform to the color picker color space. I could probably write additional color spaces that "act" on display color space but I imagine that if I did that then OCIO would first convert my colors to the display space and then perform the transforms (I may misunderstand something here, please correct me if I'm wrong). Is there a way to keep the color picker space transform and upload properly to the device by applying the device dependent transform without transforming to the device color space? I have digged a few emails and found that OCIO::ROLE_COLOR_PICKER may do what I want, but found no comprehensive examples. Can someone point me to an example and/or explain how to use something like this? Thanks!
|
|
|
|
Re: PyOpenColorIO on Windows - how?
Simon Björk <si...@...>
Hi Mark, thanks for your reply. I'm using Python 2.7.8, downloaded from python.org. Thanks for taking a look at it! Best regards, Simon
|
|
|
|
Re: PyOpenColorIO on Windows - how?
Mark Boorer <mark...@...>
Hi Simon, Unfortunately I haven't really had much of a look into the windows building process. Just wanted to clarify a few things though. Which version of python are you using (and was it one distributed by python.org or one you built yourself?).Mark
On Tue, Aug 19, 2014 at 10:45 PM, Simon Björk <si...@...> wrote:
|
|
|
|
PyOpenColorIO on Windows - how?
Simon Björk <si...@...>
I'm trying to install PyOpenColorIO on my Windows machine, but I'm not having any success. Does anyone have this working? I've tried with both Marie's build and the one that comes with the precompiled Windows version of OpenImageIO found here.
When I try to import PyOpenColorIO I get the following message: mportError: DLL load failed: %1 is not a valid Win32 application. Thanks for you help. Best regards, Simon
|
|
|
|
Re: Review: Inital pass at searchpath impl
Kevin Wheatley <kevin.j....@...>
When I looked at trying to use per-shot grades last, I ended up with the limitation that you couldn't dynamically determine the representation which meant you could not have say a 3D LUT for one shot and a CDL for another. Something that I did manage to make work was a layering approach allowing a top level look to be published, followed by more specific sequence and under that shot grades, although that didn't scale well it involved well structuring paths and names of files and using the search path capability to find the right one - needless to say this was a very twisted approach to achieving this - it didn't handle multiple versions of looks/grades, which combined with the fact that vendor supplied applications don't necessarily fully expose the OCIO capabilities meant I gave up and did something less twisted.
As for per shot variables with edited timelines, I was utilizing the config overrides to replace environment variable settings, this worked great in Nuke and other similar applications where this is exposed, but lots of tools don't expose the feature for instance heiro/heiroplayer would be a suitable place to do this.
Kevin
|
|
|
|
Re: Review: Inital pass at searchpath impl
Tobias Pfeiffer <pixeld...@...>
Hi guys, I do understand the limitations of the use of env vars to point to shot grades, but dont know how to deal with it (even 4 years later) in case of flipbooking with RV. Do you have any suggestions / Best Practices for that? Thank you. Tobi Am Freitag, 29. Oktober 2010 00:24:03 UTC+2 schrieb Jeremy Selan:
There's a lot of good ideas here, it's taken me a bit of time to think
|
|
|
|
Re: Windows Build
Tobias Pfeiffer <pixeld...@...>
thanks a lot for this! Am Montag, 21. Oktober 2013 17:15:40 UTC+2 schrieb Marie Fétiveau:
|
|
|