|
Re: 776393: added comment
Jeremy Selan <jeremy...@...>
Testing, 1 2 3...
I've updated our github acct. so all pull requests get cc'd to this list. I really like how OpenImageIO reviews commits in their public dev forum before adding them to the repo, this will let us automate the process similarly. If anyone objects to this approach (as spam!) please let me know, but if no one says otherwise we'll let the commit threads begin! -- Jeremy
|
|
|
|
[imageworks/OpenColorIO] 776393: added comment
nor...@...
Branch: refs/heads/master
Home: http://github.com/imageworks/OpenColorIO Commit: 77639305a291d929b257bb1b3211462b8c9428ed http://github.com/imageworks/OpenColorIO/commit/77639305a291d929b257bb1b3211462b8c9428ed Author: Jeremy Selan <jeremy...@gmail.com> Date: 2010-09-22 (Wed, 22 Sep 2010) Changed paths: M src/pyglue/PyGroupTransform.cpp Log Message: ----------- added comment Commit: 13dfeebb9ba726e4a9131ce73ed772d9cc12420d http://github.com/imageworks/OpenColorIO/commit/13dfeebb9ba726e4a9131ce73ed772d9cc12420d Author: Jeremy Selan <jeremy...@gmail.com> Date: 2010-09-22 (Wed, 22 Sep 2010) Changed paths: M src/core/ExponentOps.cpp Log Message: ----------- exponentop implements gpu path Commit: 6d75841a64bd110a78ba000abbca25574fd1ff05 http://github.com/imageworks/OpenColorIO/commit/6d75841a64bd110a78ba000abbca25574fd1ff05 Author: malcolmhumphreys <malcolmh...@gmail.com> Date: 2010-09-23 (Thu, 23 Sep 2010) Changed paths: M export/OpenColorIO/OpenColorIO.h M export/OpenColorIO/OpenColorTransforms.h M export/OpenColorIO/OpenColorTypes.h M src/core/Config.cpp M src/core/FileFormat3DL.cpp M src/core/FileFormatCSP.cpp A src/core/JPLogOp.cpp A src/core/JPLogOp.h A src/core/JPLogTransform.cpp M src/core/OpBuilders.h M src/core/Transform.cpp A src/core/UnitTest.cpp Log Message: ----------- - added OCIO::Config::CreateFromStream() so we can read a config from a stream - added UnitTest.cpp which defines BOOST_TEST_MODULE for the core unit tests - added BOOST_AUTO_TEST_SUITE to CSP and 3DL unit tests so you can differentiate between test when running 'ocio_core_tests --log_level=test_suite' - added JPLogOp for applying the Josuha Pines loglin method - added JPLogTransform so you can use the JPLogOp in the OCIO config - added Config code of the <JPLog \> type
|
|
|
|
Re: 3D lut size and bit depth questions
Jeremy Selan <jeremy...@...>
Est,
toggle quoted messageShow quoted text
A 32x32x32 cube lut is a totally reasonable size, it's what we happen to use internally at Imageworks. Some other popular sizes include 17x17x17 (flame), and 33x33x33 (a few commercial color graders). There are probably some clients that use larger sizes, but as you get to larger sizes there can be noticeable performance degradation. (Which is often image content dependent, has anyone else noticed that!?!) There's currently no way to query a recommended lut size through the OpenColorIO API. In the case of a transform having a 3d lut there may be times where one particular size is 'native', but on many other occasions there wont be native resolution. The question for whether or not to add such a function is based on whether a 3d display transform size is most often tied to a particular color configuration (in which case OCIO is the right place), or if it's more appropriately tied to a client or plugin (in which case and API call does not belong in OCIO). Thoughts? Good observation on the vd16 - vdf issue. That's a bug with the spi-cg profile, and we'll have it fixed in the next few weeks. (Both profiles will be getting a huge upgrade). What should be happening is that they both reference the same LUT, but that the vdf profile should be using linear interpolation, and the vd16 profile nearest. (This table has 17 bits of entries, so there is no quality difference using nearest neighbor for 16-bit int data, and the performance is a lot better). You are completely correct in that the bit depth tag is not used when converting colorspaces. It is merely a tag that the UI can use. (All of this will be explained in the docs in the near future). :) -- Jeremy ps - I'll be out of town for the next week, so my email response time may suffer.
On Thu, Sep 23, 2010 at 10:48 AM, Est <rame...@gmail.com> wrote:
Hi All,
|
|
|
|
3D lut size and bit depth questions
Est <rame...@...>
Hi All,
I recently started using OpenColorIO and I have some questions: In my current code, I'm using a 32x32x32 lut, just for the display, not for processing. Is it a good size? How do you choose a 3d lut size? In the spi-cg config, what's the difference between vd16 and vdf? I see they have the same parameters and lut. The only difference is the bitdepth. I haven't read all the code yet but it doesn't seem that the bitdepth is used when converting colorspaces. Thank you. Est.
|
|
|
|
Re: Compilation fail on FC13
Malcolm Humphreys <malcolmh...@...>
The downsides are the the build process (for core) is twice as long,I think thats fine, the DEBUG/TEST build would build both and the RELEASE wouldn't. .malcolm
|
|
|
|
OCIO 0.6.0 posted
Jeremy Selan <jeremy...@...>
Version 0.6.0 (Sept 21 2010):
* Start of 0.6, "stable" branch All 0.6.x builds will be ABI compatible (forward only). New features (even experimental ones) will be added to the 0.6 branch, as long as binary and source compatibility is maintained. Once this no longer is possible, a 0.7 "dev" branch will be forked. * Split public header into 3 parts for improved readability (you still only import <OpenColorIO/OpenColorIO.h> though) * Added MatrixTransform * Refactored internal unit testing * Fixed many compile warnings
|
|
|
|
Re: Compilation fail on FC13
Jeremy Selan <jeremy...@...>
Ok, so I just checked in a bunch of changes to the unit testing (spi
github repository). These changes may or may not affect the build error you've gotten. I'll check your error on OSX when I get home tonight, my hope is that i'll be able to re-create your error there). Previously, the unit tests were in their own .cpp files, interleaved within the src/core directory. This had the advantage of simplicity, but one major disadvantage that anything that wanted to be unit tested had to be available in an include. Being a major fan of anonymous namespaces, and really prefering to keep as much as possible in .cpp files (rather than .h files), this wasn't ideal. In this new unittest approach we build src/core twice. Once normally, and then again with an additional #define, OCIO_UNIT_TEST. (This is controlled through the src/core_tests submodule). The upside is we can build the core library without including boost symbols: nm -C lib/libOpenColorIO.so | grep unit | wc -l0 and then build the test library including boost testing, as a build-time dependency nm -C bin/ocio_core_tests | grep unit | wc -l1430 I also really like that you can easily nit test small helper functions that do not escape the file. For an example of this in practice see src/core/FileFormatCSP.cpp The downsides are the the build process (for core) is twice as long, and that the implementation files may get longer. But I think it's worth it to keep the code and associated tests together. Thoughts? -- Jeremy On Mon, Sep 20, 2010 at 3:19 PM, Alan Jones <sky...@gmail.com> wrote: Hi Jeremy,
|
|
|
|
Re: Compilation fail on FC13
Alan Jones <sky...@...>
Hi Jeremy,
On Mon, Sep 20, 2010 at 5:09 PM, Jeremy Selan <jeremy...@gmail.com> wrote: Actually, I dont believe there currently is a link dependency to boost.Ahhh, my bad. In quick reading up on it I'd assumed that they were referring to linking with boost's libraries, rather than the test modules created within the user's code. I did a little more reading here http://www.boost.org/doc/libs/1_44_0/libs/test/doc/html/utf/user-guide/usage-variants/dynamic-lib-variant.html It seems that BOOST_TEST_DYN_LINK can be specified in Makefiles instead. Perhaps there's some logic that can be dropped into the CMakeLists.txt to handle this transparently? Cheers, Alan.
|
|
|
|
Re: Compilation fail on FC13
Jeremy Selan <jeremy...@...>
Actually, I dont believe there currently is a link dependency to boost.
toggle quoted messageShow quoted text
ldd src/core/libOpenColorIO.so : linux-vdso.so.1 => (0x00007fff63afb000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f4b3241a000) libm.so.6 => /lib64/libm.so.6 (0x00007f4b32196000) libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f4b31f80000) libc.so.6 => /lib64/libc.so.6 (0x00007f4b31c30000) /lib64/ld-linux-x86-64.so.2 (0x00007f4b329e5000) And, a bit surprisingly, even the unit test program doesnt appear to link to boost: ldd src/core/ocio_core_tests: linux-vdso.so.1 => (0x00007fff09fb8000) libOpenColorIO.so => libOpenColorIO.so (0x00007f41d812d000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f41d7e1f000) libm.so.6 => /lib64/libm.so.6 (0x00007f41d7b9c000) libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f41d7986000) libc.so.6 => /lib64/libc.so.6 (0x00007f41d7636000) /lib64/ld-linux-x86-64.so.2 (0x00007f41d83b3000) So the only benefit would be to remove it as a compile time dependency (presuming that we dont let anyone use at link time, either). -- Jeremy
On Mon, Sep 20, 2010 at 2:35 PM, Alan Jones <sky...@gmail.com> wrote:
Hi Jeremy,
|
|
|
|
Re: Compilation fail on FC13
Alan Jones <sky...@...>
Hi Jeremy,
On Mon, Sep 20, 2010 at 4:10 PM, Jeremy Selan <jeremy...@gmail.com> wrote: I've also been rethinking the use of boost within OCIO. Currentlyshared_ptr is header only and you're already using CMake, so perhaps it'd be worth looking at using CMake's unit testing instead of boost's? This way there's no linking dependencies against boost. Cheers, Alan.
|
|
|
|
Re: Development Priorities?
Jeremy Selan <jeremy...@...>
Thanks for all the feedback, everyone! It has been very helpful.
Having tabulated the results, the winner - by a landslide - is documentation! So this will be the (rough) order of development: 1) Developer API / Facility Integration Docs 2) End User (Artist) Docs 3) Color Config Authoring Docs / Examples 4) Flesh out existing OCIO configs I think this will go a long way towards making OCIO useful in practice. -- Jeremy
|
|
|
|
Re: Compilation fail on FC13
Jeremy Selan <jeremy...@...>
Hmmm, that patch doesnt quite work for us locally at Imageworks. (I
toggle quoted messageShow quoted text
think it's probably because we use a namespaced version of boost, and the macro isn't quite right in our context). Let me see if I can find a solution that works for both of us. I've also been rethinking the use of boost within OCIO. Currently there are only two things we use it for: shared_ptr and the unit test framework. Given the issues that can occur when linking against other apps the rely on different boost versions, boost may be a can of worms worth avoiding, particularly considering that at this time it may be a pretty simple dependency to remove. Does anyone have any strong feelings (or experience) on this? -- Jeremy
On Mon, Sep 20, 2010 at 1:05 PM, Alan Jones <sky...@gmail.com> wrote:
Best way to solve a problem? Post on a mailing list asking for help, then
|
|
|
|
Re: Compilation fail on FC13
Alan Jones <sky...@...>
Best way to solve a problem? Post on a mailing list asking for help, then
you'll find the solution within minutes. Cheers, Alan.
|
|
|
|
Compilation fail on FC13
Alan Jones <sky...@...>
Hi All,
For some reason the compilation of the latest trunk is failing on FC13. It's complaining about main not being defined, but from what I've read on the boost unit testing defining BOOST_TEST_MODULE should take care of that. Any ideas? Error output is below. Cheers, Alan. Linking CXX executable ocio_core_tests /usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status make[2]: *** [src/core/ocio_core_tests] Error 1 make[1]: *** [src/core/CMakeFiles/ocio_core_tests.dir/all] Error 2
|
|
|
|
Re: Development Priorities?
srluka <srl...@...>
Hello Jeremy,
toggle quoted messageShow quoted text
I would like to see OCIO grow into a library that can handle all our color transformations. I can see it being used in the current xml'ized form within our production environment to keep the color options well- defined, but still want the eventual capability for dynamic color transformations. Performance for realtime playback is also important to us. With that in mind, here are my top five: - Developer API Docs - Color Config Authoring Docs - Overall performance optimization - Dynamic Color API - OpenImageIO Stefan
On Sep 16, 8:36 am, Marie Fétiveau <m....@mikrosimage.eu> wrote:
Hello Jeremy and all !
|
|
|
|
OCIO 0.5.16 posted
Jeremy Selan <jeremy...@...>
Version 0.5.16 (Sept 16 2010):
* PyTransforms now use native python class inheritance * OpenColorIO C++ namespace can now be configured at build time (for safe distribution in commercial apps) * Updated make install behavior * DisplayTransform accepts generic cc operators (instead of CDL only) * A few bug fixes / compile warning fixes And coming next week, 0.6.0 !
|
|
|
|
Re: Development Priorities?
Marie Fétiveau <m...@...>
Hello Jeremy and all !
toggle quoted messageShow quoted text
I don't have much time to focus on OCIO now but soon or late I will...;) And when that day will come, I'll be happy to find : - Developer API Docs
- Color Config Authoring Docs
- Add a example ACES ocio config - End User (Artist) Docs
- Live CDL Support
Thanks !
Marie
On Thu, Sep 16, 2010 at 1:39 AM, Est <rame...@...> wrote: Hi Jeremy,
|
|
|
|
Re: Development Priorities?
Est <rame...@...>
Hi Jeremy,
toggle quoted messageShow quoted text
I'm currently adding OpenColorIO support to my compositor. My list would be: - End User (Artist) Docs - Developer API Docs - Flesh out the existing ocio configs (spi-anim,spi-vfx) for real use - Color Config Authoring Docs - Add example color config authoring scripts I can port the existing Colorspace and Display Nuke plugins to OFX if there is interest. Just let me know. Est.
On Sep 15, 4:49 pm, Alan Jones <sky...@gmail.com> wrote:
Hi Jeremy,
|
|
|
|
Re: Development Priorities?
Alan Jones <sky...@...>
Hi Jeremy,
On Tue, Sep 14, 2010 at 6:59 PM, Jeremy Selan <jeremy...@gmail.com> wrote: Perhaps reply with the top 5 items you care about?The top five for me would be as follows. 1) API Documentation (the classes and how the pieces are supposed to work together - I guess that may count as config documentation) 2) LUT export 3) Unit testing (this kinda should be number one, but I'm trying to be somewhat pragmatic) 4) Color config authoring docs 5) Additional LUT formats I'd say for now the biggest thing holding me back on OIIO is there is no big picture documentation. I don't really know how OCIO is intended to work and what all the pieces are. I can try piece it together from the code, but a document covering intended structure would make both using it and identifying areas to provide meaningful contribution much easier. The reason I say big picture rather than purely API is I'm thinking not just of the API for how to access it, but how it's intended to work within a pipeline. Cheers, Alan.
|
|
|
|
Re: Development Priorities?
"Nathaniel Hoffman" <na...@...>
1) Document 'best practice' for each config, provide examples with imagery
toggle quoted messageShow quoted text
2) Flesh out the existing ocio configs (spi-anim,spi-vfx) for real use 3) Add example color config authoring scripts 4) End User (Artist) Docs 5) Color Config Authoring Docs Naty
Folks,
|
|
|