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
Alan Jones <sky...@...>
Hi Jeremy,
On Mon, Sep 20, 2010 at 4:10 PM, Jeremy Selan <jeremy...@...> 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: 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...@...> 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...@...> 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...@...>
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...@...> wrote: Hi Jeremy,
|
|
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
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
|
|
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: 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...@...> wrote:
Hi All,
|
|
[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...@...> 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...@...> 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...@...> 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: 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
|
|
Re: 776393: added comment
Jeremy Selan <jeremy...@...>
Oops. This is actually a callback on commits themselves, not pull
requests. I'll disable the callback until I get it worked out.
|
|
Re: 3D lut size and bit depth questions
Est <rame...@...>
Hi Jeremy,
Thank you for your replies. Everything is clear now. I think that the lut size is an implementation detail of the client and a recommended lut size function wouldn't have much use as most of the clients / plugins would use a fixed size lut. Est.
|
|
[imageworks/OpenColorIO] 5a24dc: bump
nor...@...
Branch: refs/heads/master
Home: http://github.com/imageworks/OpenColorIO Commit: 5a24dca1b81c5275051b769adeaef6c634a10e1d http://github.com/imageworks/OpenColorIO/commit/5a24dca1b81c5275051b769adeaef6c634a10e1d Author: Jeremy Selan <jeremy...@...> Date: 2010-10-05 (Tue, 05 Oct 2010) Changed paths: M ChangeLog M export/OpenColorIO/OpenColorIO.h M tgz_create Log Message: ----------- bump
|
|
OCIO 0.6.1 posted
Jeremy Selan <jeremy...@...>
Version 0.6.1 (Oct 5 2010):
* Exposed ExponentTransform * Added CineonLogToLinTransform - a simple 'straight-line' negative linearization. Not strictly needed (could be done previously with LUTs) but often convenient to have. * Added DisplayTransform.displayCC for post display lut CC. * Many python improvements * A few bug fixes * A few Makefile enhancements
|
|
Inital Houdini lut support
Malcolm Humphreys <malcolmh...@...>
Hi,
I have a few emails to send through I have been discussing with jeremy, I have split them up so they can be discussed in different threads. Here is an initial pass at the Houidini lut loader. I have only really tested the 3D+1D type as that what we are using. There is support for the 3D type and partial support for the 1D type. There is no support for the binary type. houdini luts has a not so good extension (.lut) and (.blut for the binary version),. Do you think we need a better way to choose a lut loader other than file extensions? I have attached another patch staticlink_breaksRegisterFileFormat.patch which you need to edit a little to get OCIO to link statically but on OSX at least RegisterFileFormat() will not be called for the AutoRegister struct in each loader. I'm not sure this is expected. .malcolm
|
|
ICC Support
Malcolm Humphreys <malcolmh...@...>
I have been playing with littlecms a little (building profiles for photoshop etc) and was wondering if people have an idea on how they envisioned these fitting into OCIO?
There could be reader and writers. But the icc tag system isn't super straight forward. Most ICC profiles need to have there PCS (profile connection space) as Lab for them to be used in photoshop for soft proofing etc.. with OCIO being RGB and all the options for rendering intent, some ideas on how this could fit would help. .malcolm
|
|
XML Profile Format
Malcolm Humphreys <malcolmh...@...>
Are people super into the idea of using xml?
We used xml for nearly everything at RSP, over time it became clear that it's a pretty poor choice for a lot of things. One of the developers introduced the use of YAML (http://www.yaml.org/ http://en.wikipedia.org/wiki/YAML) and it took off with everyone, it happened again when I recommended it's introduction at DrD (where pretty much everything was XML). RV has started to use it for it's package descriptions as well. As I don't think any other apps will actually be writing ocio profiles other than the ocio api, and people will be hand writing these profiles. I don't see a benefit to using xml for a profile description, if we using as an interchange format then maybe. btw. I really don't like file format discussions but I think this would really help ocio profile readability. If people are into the idea I'm happy to do the leg work to get it to work. I have attached a small demo python script for you to check out, it mostly shows off how to define your own custom yaml serialisation. You need PyYaml (http://pyyaml.org/) to run the demo. Why I like it: - super simple to parse and serialise objects - human readable / editable - easy to define your own custom types - using yaml in python is so simple It would be quite easy to have binary data (eg file luts) interweaved inside a yaml file. http://en.wikipedia.org/wiki/YAML#Other_specified_data_types --snip-- picture: !!binary | R0lGODlhDAAMAIQAAP//9/X 17unp5WZmZgAAAOfn515eXv Pz7Y6OjuDg4J+fn5OTk6enp 56enmleECcgggoBADs=mZmE --snip-- http://www.yaml.org/spec/1.2/spec.html#id2759572 - Relation to JSON http://www.yaml.org/spec/1.2/spec.html#id2759732 - Relation to XML YAML --snip-- ocs_profile_version: 1 resource_path: luts luma_b: '0.0722' luma_g: '0.7152' luma_r: '0.2126' role_compositing_log: lgh role_scene_linear: lnh strictparsing: true displays: Film1D: !Display {colorspace: vd8, device: sRGB} Log: !Display {colorspace: lg10, device: sRGB} colorspaces: dt8: !ColorSpace bitdepth: 8ui description: null family: vd8 gpuallocation: uniform gpumax: 1 gpumin: 0 isdata: false to_reference: - !File {interpolation: null, src: diffusemult.spimtx} - !ColorSpaceTransform {dst: lnh, src: vd8} lg10: !ColorSpace bitdepth: 10ui description: lg10 converts from scanned film to the show linear reference space. This is a custom conversion based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This 10bit uiint version is used for DI deliveries. family: lg gpuallocation: uniform gpumax: 1 gpumin: 0 isdata: false to_reference: lnh: !ColorSpace bitdepth: 16f description: The show reference space. This is a sensor referred linear representation of the scene with primaries that correspond to scanned film. 0.18 inthis space corresponds to a properly exposed 18% grey card. family: ln gpuallocation: lg2 gpumax: 6 gpumin: -15 isdata: false to_reference: null vd8: !ColorSpace bitdepth: 8ui description: vd8 is an 8 bit sRGB like,2.2 gamma, conversion to and from the reference colorspace. This is a 1-d representation does not include any subtractive color mixing or crosstalk compensation. This is commonly used to interchange files between internal and external vendors. This is used as the interchange space for final images on direct to video or television products. family: vd8 gpuallocation: uniform gpumax: 1 gpumin: 0 isdata: false to_reference: - !File {interpolation: linear, src: vd10.spi1d} --snip-- XML --snip-- <ocioconfig version="1" resourcepath="luts" strictparsing="true" luma_r="0.2126" luma_g="0.7152" luma_b="0.0722" role_scene_linear="lnh" role_compositing_log="lgh"> <display device="sRGB" name="Film1D" colorspace="vd8"/> <display device="sRGB" name="Log" colorspace="lg10"/> <colorspace name="lnh" family="ln" bitdepth="16f" isdata="false" gpuallocation="lg2" gpumin="-15" gpumax="6"> <description>The show reference space. This is a sensor referred linear representation of the scene with primaries that correspond to scanned film. 0.18 in this space corresponds to a properly exposed 18% grey card. </description> </colorspace> <colorspace name="lg10" family="lg" bitdepth="10ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1"> <description>lg10 converts from scanned film to the show linear reference space. This is a custom conversion based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This 10bit uiint version is used for DI deliveries.</description> <to_reference> <group> <file src="lg10.spi1d" interpolation="nearest" /> </group> </to_reference> </colorspace> <colorspace name="lg16" family="lg" bitdepth="16ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1"> <description>lg16 converts from scanned film to the show linear reference space. This is a custom conversion based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This 16bit uiint version is used for DI deliveries in the rare case where this is requested. </description> <to_reference> <group> <file src="lgf.spi1d" interpolation="nearest" /> </group> </to_reference> </colorspace> <colorspace name="lgh" family="lg" bitdepth="16f" isdata="false" gpuallocation="uniform" gpumin="-0.2" gpumax="1.615"> <description>Converts from scanned film to the show linear reference space. This is a custom curve based on several Kodak acquisition stocks. All three color channels have the same response and there is no cross talk. This transform has a shoulder and toe compensation. This floating point version of the conversion that includes a large range of over-shoot and under-shoot values. This allows for colortiming offsetsto be applied and reversed out losslessly. For internal use only. </description> <to_reference> <group> <file src="lgf.spi1d" interpolation="linear" /> </group> </to_reference> </colorspace> <colorspace name="vd8" family="vd" bitdepth="8ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1"> <description>vd8 is an 8 bit sRGB like,2.2 gamma, conversion to and from the reference colorspace. This is a 1-d representation does not include any subtractive color mixing or crosstalk compensation. This is commonly used to interchange files between internal and external vendors. This is used as the interchange space for final images on direct to video or television products. </description> <to_reference> <group> <file src="vd10.spi1d" interpolation="linear" /> </group> </to_reference> </colorspace> <colorspace name="dt8" family="dt" bitdepth="8ui" isdata="false" gpuallocation="uniform" gpumin="0" gpumax="1"> <description> </description> <to_reference> <group> <file src="diffusemult.spimtx"/> <colorspacetransform src="vd8" dst="lnh"/> </group> </to_reference> </colorspace> </ocioconfig> --snip-- .malcolm
|
|
Development Guidelines + New Website
Jeremy Selan <jeremy...@...>
Now that we've got a few people actively contributing code, we're
going to start formalizing the development process. (Thanks to Malcolm Humphreys for being the guinea-pig in the process). Please refer to our new website, opencolorio.org (still in development), for further details. Thanks!
|
|
Review: pkg-config support and some OCIO_VERSION changes
Malcolm Humphreys <malcolmh...@...>
I wanted some pkgconfig (http://en.wikipedia.org/wiki/Pkg-config) support to make it easier to build against OCIO.
Part of this needed burning the ocio version into the .pc file, so I rejigged things a little so there is only one place to change the OCIO_VERSION Notes: * added some basic pkg-config .pc building * moved OCIO_VERSION into top most CMakeLists.txt * added OpenColorVersion.h.in which gets configured() at build time with OCIO_VERSION * added ${CMAKE_BINARY_DIR}/export/ to a few CMakeLists.h so they can find the resloved OpenColorVersion.h * added OpenColorIO.pc.in which gets configured() at build time with OCIO_VERSION and CMAKE_INSTALL_PREFIX .malcolm
|
|