Date   

Re: SceneLinear to LogC into an ICC profile

Kai-Uwe Behrmann <ku...@...>
 

There are at least two open source CMM's around, which support float style lookup tables. One is used in Krita, which in turn links to OCIO.
The involved Lcms CMM has since version 2.4 a option to apply pre and post linearisation curves to ICC transforms, which greatly improves linear to gamma conversion quality.

kind regards
Kai-Uwe
--
www.oyranos.org

Am 29.11.2012 14:35, schrieb dbr/Ben:

The --inputspace/--outputspace arguments are only required when using an OCIO config. The --lut argument is used, alone, for "Config-free baking":

http://opencolorio.org/userguide/baking_luts.html#config-free-baking

So you would just do something like:

ociobakelut --lut ln_1_logC.3dl --format icc mynewlut.icc

..which will make an ICC which applies the same transform as the 3dl.


However, I suspect there's a bigger problem with what you are trying to do - the .3dl and .icc profiles don't tend to work well with scene-linear values:

- 3dl only works with integer values (usually print-denstity-space scans or Rec709 video), it would clamp scene-linear values over 1.0 (to about 0.6 in LogC)

- ICC probably can, there was an update to the ICC spec to support their equivalent to a floating-point shaper LUT ("unbounded Device-side encoding"?)

http://www.color.org/ICCSpecRevision_02_11_06_Float.pdf

However this requires that the host application supports that version of ICC (Photoshop CS4 doesn't, and pretty sure neither does CS5). Also I'd guess OCIO's baker would need updated also.

On 28/11/2012, at 12:52 PM, Andrew Britton wrote:

A question about converting from scene linear to ARRI LogC via an icc profile:

when I use ociobakelut I'm wondering how to create an icc file that will be a viewing profile for a scenelinear image, to view it in LogC. My assumptions are as follows with a question about the direction of a LUT.

First I'm assuming this will be the proper command for creating said ICC profile:
ociobakelut --inputspace lnf --lut ln_2_logC.3dl --format icc /path/finalPath/LogC_Viewer.icc

So the question I have when making the ln_2_logC.3dl is which direction should the LUT be created? ie... should the .cube be created to convert from SceneLinear to LogC or vice versa? My apologies if this seems obvious, and my assumption is that the .cube should be from SceneLinear to LogC, but I'm confused as to why there would need to be an --inputspace predefined if it's already in the .3dl LUT. In this case of converting a .3dl to a .icc, I would expect the command to only need one .3dl file.

Thank you,
Andrew


Re: SceneLinear to LogC into an ICC profile

dbr/Ben <dbr....@...>
 

The --inputspace/--outputspace arguments are only required when using an OCIO config. The --lut argument is used, alone, for "Config-free baking":


So you would just do something like:

ociobakelut --lut ln_1_logC.3dl --format icc mynewlut.icc

..which will make an ICC which applies the same transform as the 3dl.


However, I suspect there's a bigger problem with what you are trying to do - the .3dl and .icc profiles don't tend to work well with scene-linear values:

- 3dl only works with integer values (usually print-denstity-space scans or Rec709 video), it would clamp scene-linear values over 1.0 (to about 0.6 in LogC)

- ICC probably can, there was an update to the ICC spec to support their equivalent to a floating-point shaper LUT ("unbounded Device-side encoding"?)


However this requires that the host application supports that version of ICC (Photoshop CS4 doesn't, and pretty sure neither does CS5). Also I'd guess OCIO's baker would need updated also.

On 28/11/2012, at 12:52 PM, Andrew Britton wrote:

A question about converting from scene linear to ARRI LogC via an icc profile:

when I use ociobakelut I'm wondering how to create an icc file that will be a viewing profile for a scenelinear image, to view it in LogC. My assumptions are as follows with a question about the direction of a LUT.

First I'm assuming this will be the proper command for creating said ICC profile:
ociobakelut --inputspace lnf --lut ln_2_logC.3dl --format icc /path/finalPath/LogC_Viewer.icc

So the question I have when making the ln_2_logC.3dl is which direction should the LUT be created? ie... should the .cube be created to convert from SceneLinear to LogC or vice versa? My apologies if this seems obvious, and my assumption is that the .cube should be from SceneLinear to LogC, but I'm confused as to why there would need to be an --inputspace predefined if it's already in the .3dl LUT. In this case of converting a .3dl to a .icc, I would expect the command to only need one .3dl file.

Thank you,
Andrew


SceneLinear to LogC into an ICC profile

Andrew Britton <cbsd....@...>
 

A question about converting from scene linear to ARRI LogC via an icc profile:

when I use ociobakelut I'm wondering how to create an icc file that will be a viewing profile for a scenelinear image, to view it in LogC. My assumptions are as follows with a question about the direction of a LUT.

First I'm assuming this will be the proper command for creating said ICC profile:
ociobakelut --inputspace lnf --lut ln_2_logC.3dl --format icc /path/finalPath/LogC_Viewer.icc

So the question I have when making the ln_2_logC.3dl is which direction should the LUT be created? ie... should the .cube be created to convert from SceneLinear to LogC or vice versa? My apologies if this seems obvious, and my assumption is that the .cube should be from SceneLinear to LogC, but I'm confused as to why there would need to be an --inputspace predefined if it's already in the .3dl LUT. In this case of converting a .3dl to a .icc, I would expect the command to only need one .3dl file.

Thank you,
Andrew


Re: Problems with displaying exposure

Boudewijn Rempt <bo...@...>
 

On Sunday 25 November 2012 Nov, Boudewijn Rempt wrote:
On Saturday 24 November 2012 Nov, Paul Miller wrote:
On 11/24/2012 2:47 PM, Brendan Bolles wrote:
On Nov 24, 2012, at 12:19 PM, Brendan Bolles wrote:

Looks like a known issue. MatrixOps.cpp line 457 says:

Or I guess in ociodisplay/main.cpp you could change line 480 to read:

const float slope4f[] = { gain, gain, gain, 1.0f };


Not sure what effect it might have on channel swizzling.
I made this change recently after customer feedback. Seems to do the
job, and nobody has complained yet.
Cool, I will try that. Maybe it's something that can be part of the next release? It doesn't matter for the binaries I build and redistribute myself, but for Linux distributions carrying Krita, it's a problem: they don't want to have patched 3rd party libraries in an application.
Ah, I thought it was a patch to the library -- I was looking in the wrong place. I've fixed this in krita itself now and everything is fine! Thanks for the replies.


--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl


Re: Problems with displaying exposure

Boudewijn Rempt <bo...@...>
 

On Saturday 24 November 2012 Nov, Paul Miller wrote:
On 11/24/2012 2:47 PM, Brendan Bolles wrote:
On Nov 24, 2012, at 12:19 PM, Brendan Bolles wrote:

Looks like a known issue. MatrixOps.cpp line 457 says:

Or I guess in ociodisplay/main.cpp you could change line 480 to read:

const float slope4f[] = { gain, gain, gain, 1.0f };


Not sure what effect it might have on channel swizzling.
I made this change recently after customer feedback. Seems to do the
job, and nobody has complained yet.
Cool, I will try that. Maybe it's something that can be part of the next release? It doesn't matter for the binaries I build and redistribute myself, but for Linux distributions carrying Krita, it's a problem: they don't want to have patched 3rd party libraries in an application.

--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl


Re: Problems with displaying exposure

Paul Miller <pa...@...>
 

On 11/24/2012 2:47 PM, Brendan Bolles wrote:
On Nov 24, 2012, at 12:19 PM, Brendan Bolles wrote:

Looks like a known issue. MatrixOps.cpp line 457 says:

Or I guess in ociodisplay/main.cpp you could change line 480 to read:

const float slope4f[] = { gain, gain, gain, 1.0f };


Not sure what effect it might have on channel swizzling.
I made this change recently after customer feedback. Seems to do the job, and nobody has complained yet.


Re: Problems with displaying exposure

Brendan Bolles <bre...@...>
 

On Nov 24, 2012, at 12:19 PM, Brendan Bolles wrote:

Looks like a known issue. MatrixOps.cpp line 457 says:

Or I guess in ociodisplay/main.cpp you could change line 480 to read:

const float slope4f[] = { gain, gain, gain, 1.0f };


Not sure what effect it might have on channel swizzling.


Brendan


Re: Problems with displaying exposure

Brendan Bolles <bre...@...>
 

On Nov 24, 2012, at 5:05 AM, Boudewijn Rempt wrote:

I must be missing something else.

Looks like a known issue. MatrixOps.cpp line 457 says:

// TODO: This should not act upon alpha,
// since we dont apply it on the CPU?


Maybe you could figure out a way to keep the alpha multiplied by 1.0?



Brendan


Re: Problems with displaying exposure

Boudewijn Rempt <bo...@...>
 

On Thursday 22 November 2012 Nov, Andrew Hunter wrote:

> Hey Boudewijn,

>

> Sounds like the exposure function affecting the alpha channel. Alpha is

> usually normalized to 0 - 1, so it would make sense if positive exposure

> adjustments are clamped.

 

Yes -- that's what I figured. Unfortunately, I don't know why -- or rather, I don't know why that doesn't happen with the ocio display demo app. The code in Krita is pretty much the same, down to the same generated LUT -- and the shader calls the OCIODisplay method to calculate the color:

 

const char * m_fragShaderText = ""

"\n"

"uniform sampler2D tex1;\n"

"uniform sampler3D tex2;\n"

"\n"

"void main()\n"

"{\n"

" vec4 col = texture2D(tex1, gl_TexCoord[0].st);\n"

" gl_FragColor = OCIODisplay(col, tex2);\n"

"}\n"

 

I must be missing something else.

--

Boudewijn Rempt

http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl

 


Re: Problems with displaying exposure

Andrew Hunter <and...@...>
 

Hey Boudewijn,

Sounds like the exposure function affecting the alpha channel. Alpha is usually normalized to 0 - 1, so it would make sense if positive exposure adjustments are clamped.

Cheers,

Andrew

On Nov 19, 2012 4:29 AM, "Boudewijn Rempt" <bo...@...> wrote:

Hi,

I've got some problems using the code from the ocio display application in Krita, and I'm not sure what's going on. The problem is that when the exposure gets negative, the image gets more transparent, and I cannot figure out why that should be...
--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl


Re: parsing configs with non-C locale

Paul Miller <pa...@...>
 

On 11/19/2012 8:28 AM, Dithermaster wrote:
Ben's description aligns with my own experiences. We had a similar bug
reading/writing a text file with decimals, and fixed it in a similar way
(by saving/setting/restoring the locale setting).
Same here. But in that case, rather than fiddling with the locale (I wasn't sure of any unintended consequences of doing that), I swapped in a custom sscanf() that assumed decimal separators.

Still, I'll manually swap into the C locale when using OCIO in my imminent update, but I agree it should probably be done inside OCIO at some point. One less implementation detail to worry about.


Re: parsing configs with non-C locale

Dithermaster <dither...@...>
 

Ben's description aligns with my own experiences. We had a similar bug reading/writing a text file with decimals, and fixed it in a similar way (by saving/setting/restoring the locale setting).

///d@


On Nov 19, 2012, at 6:54 AM, dbr/Ben <dbr....@...> wrote:

I've not had much experience with locales either, but it seemed like an interesting thing to read up on.. so..

With LANG=de_DE, sscanf expects to see floats like "0,12" (compared to 0.12 as required in the LUT file)

Doesn't happen often because the locale defaults to "C", and the user's environment is ignored unless setlocale() has been called elsewhere in the process:


I think OCIO should definitely set the locale to "C" temporarily while parsing/writing files, otherwise it might end up with invalid LUT's that happen to work for the current user but no-one else..

Based on this page..
..I think the tidiest way to fix this would be:

- Replace the few usages of the C string-parsing methods (sscanf/atof/etc) with the C++ stdlib equivalents (the *stream stuff)
- Modify FileTransform.cpp:GetFile to imbue the filestream with the "C" locale (as described in the above apache.org link)
- Same imbue'ing wherever else std::ofstream or std::ifstream is used (not many places - main ones are FileTransform, ociobakelut, and the CDLTransform)

I think that should make the reading/writing of files locale-independant, but there might still be other issues..? (e.g the stringstream used to construct exception messages)

Python has a kind of similar problem, seems like their approach was to write their own atof/stdtod methods, but I don't think this will work for OCIO, since it mainly uses the C++ *stream stuff..

On 17/11/2012, at 2:46 AM, Jeremy Selan wrote:

Hm...

I have to admit I dont have much experience with locales.  Can someone
with experience on such issues please comment?  On first glance, it
feels like it should certainly be fixed inside OCIO, but perhaps I am
mistaken?

-- Jeremy

On Thu, Nov 15, 2012 at 7:01 AM, Paul Miller <pa...@...> wrote:
I think I found a bug in either my code or OCIO. When our software is run on
a Ubuntu 12.04 machine with a German locale, parsing of srgb.spi1d fails and
we get an "Invalid 'From' Tag" exception. I think the sscanf() there is
attempting to parse the string using the German locale. Should I be forcing
the C locale before calling into OCIO, or should OCIO be doing this itself?


Re: parsing configs with non-C locale

dbr/Ben <dbr....@...>
 

I've not had much experience with locales either, but it seemed like an interesting thing to read up on.. so..

With LANG=de_DE, sscanf expects to see floats like "0,12" (compared to 0.12 as required in the LUT file)

Doesn't happen often because the locale defaults to "C", and the user's environment is ignored unless setlocale() has been called elsewhere in the process:


I think OCIO should definitely set the locale to "C" temporarily while parsing/writing files, otherwise it might end up with invalid LUT's that happen to work for the current user but no-one else..

Based on this page..
..I think the tidiest way to fix this would be:

- Replace the few usages of the C string-parsing methods (sscanf/atof/etc) with the C++ stdlib equivalents (the *stream stuff)
- Modify FileTransform.cpp:GetFile to imbue the filestream with the "C" locale (as described in the above apache.org link)
- Same imbue'ing wherever else std::ofstream or std::ifstream is used (not many places - main ones are FileTransform, ociobakelut, and the CDLTransform)

I think that should make the reading/writing of files locale-independant, but there might still be other issues..? (e.g the stringstream used to construct exception messages)

Python has a kind of similar problem, seems like their approach was to write their own atof/stdtod methods, but I don't think this will work for OCIO, since it mainly uses the C++ *stream stuff..

On 17/11/2012, at 2:46 AM, Jeremy Selan wrote:

Hm...

I have to admit I dont have much experience with locales.  Can someone
with experience on such issues please comment?  On first glance, it
feels like it should certainly be fixed inside OCIO, but perhaps I am
mistaken?

-- Jeremy

On Thu, Nov 15, 2012 at 7:01 AM, Paul Miller <pa...@...> wrote:
I think I found a bug in either my code or OCIO. When our software is run on
a Ubuntu 12.04 machine with a German locale, parsing of srgb.spi1d fails and
we get an "Invalid 'From' Tag" exception. I think the sscanf() there is
attempting to parse the string using the German locale. Should I be forcing
the C locale before calling into OCIO, or should OCIO be doing this itself?


Problems with displaying exposure

Boudewijn Rempt <bo...@...>
 

Hi,

I've got some problems using the code from the ocio display application in Krita, and I'm not sure what's going on. The problem is that when the exposure gets negative, the image gets more transparent, and I cannot figure out why that should be...
--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl


Re: parsing configs with non-C locale

Jeremy Selan <jeremy...@...>
 

Hm...

I have to admit I dont have much experience with locales. Can someone
with experience on such issues please comment? On first glance, it
feels like it should certainly be fixed inside OCIO, but perhaps I am
mistaken?

-- Jeremy

On Thu, Nov 15, 2012 at 7:01 AM, Paul Miller <pa...@...> wrote:
I think I found a bug in either my code or OCIO. When our software is run on
a Ubuntu 12.04 machine with a German locale, parsing of srgb.spi1d fails and
we get an "Invalid 'From' Tag" exception. I think the sscanf() there is
attempting to parse the string using the German locale. Should I be forcing
the C locale before calling into OCIO, or should OCIO be doing this itself?


parsing configs with non-C locale

Paul Miller <pa...@...>
 

I think I found a bug in either my code or OCIO. When our software is run on a Ubuntu 12.04 machine with a German locale, parsing of srgb.spi1d fails and we get an "Invalid 'From' Tag" exception. I think the sscanf() there is attempting to parse the string using the German locale. Should I be forcing the C locale before calling into OCIO, or should OCIO be doing this itself?


Re: Compiling for Windows 7, VS2010

Jeremy Selan <jeremy...@...>
 

My apologies that compilation is not easier on windows.

Our choice to use an external shared_ptr, in retrospect, makes portability more challenging than it need be; this is one of our top priorities to address next year.  Along these lines, distributing OCIO precompiled binaries as 'system installs' is one of my major goals for next year.  This would take a huge step forwards for allowing people to upgrade their OCIO system library version to alleviate apps that ship with older library versions.

Currently in our CMake install, it appears we DO require the use of boost on windows for access to ptr:

# Use boost's shared_ptr by default on Windows (as <VS2010 doesn't have it),
# Use std::tr1::shared_ptr by default on other platforms
option(OCIO_USE_BOOST_PTR "Set to ON to enable boost shared_ptr (necessary when tr1 is not available)" WIN32)

However, reading the docs online it's pretty clear that both VS2010 and 2012 DO include a ptr:

So you have two options to try:
- install boost, and then compile with OCIO_USE_BOOST_PTR 1
- dont install boost, and path the OpenColorABI.h to define the ptr from the proper location

(in this case, the code would look something like...

#if OCIO_USE_BOOST_PTR
#include <boost/shared_ptr.hpp>
#define OCIO_SHARED_PTR boost::shared_ptr
#define OCIO_DYNAMIC_POINTER_CAST boost::dynamic_pointer_cast

#elif __GNUC__ >= 4
#include <tr1/memory>
#define OCIO_SHARED_PTR std::tr1::shared_ptr
#define OCIO_DYNAMIC_POINTER_CAST std::tr1::dynamic_pointer_cast

<NEWCODE>
#elif (_MSC_VER > 1600)
#include <memory>
#define OCIO_SHARED_PTR std::shared_ptr
#define OCIO_DYNAMIC_POINTER_CAST std::dynamic_pointer_cast
</NEWCODE>

#else
#error OCIO needs gcc 4 or later to get access to <tr1/memory> (or specify USE_BOOST_PTR instead)
#endif


-- Jeremy




On Wed, Nov 7, 2012 at 11:22 AM, Andrew Britton <cbsd....@...> wrote:
Good afternoon,

First let me say that I'm very grateful for the efforts of all involved in making OCIO come to be.

I'm currently attempting to compile OCIO for Win7 and am having a difficult time finding a best practices document outlining this process. It should be said, and for this I apologize in advance, that I am not well experienced with compilers or the science of compiling. I'm just a coder trying to get OCIO built so I can start turning LUTs into ICC profiles and ACES into all other magical concoctions.
Currently, I'm found the documentation regarding cmake and have installed that.

So my steps, to date, are as follows:
given: (I already have VS2010 installed)
  • install CMAKE (I'm currently running 2.8)
  • From this resource, make these directories:
    • software/ocio = C:\Program Files (x86)\ocio
    • source/ocio = E:\Tools\Research\OpenColorIO\SourceCode\imageworks-OpenColorIO-v1.0.7-17-g533f85e\imageworks-OpenColorIO-533f85e
    • tmp/ociobuild = E:\Tools\Research\OpenColorIO\SourceCode\tmp\ociobuild
  • I then run cmake from a cmd.exe window (running as administrator, and when not running as administrator)
    • cmake -D CMAKE_INSTALL_PREFIX="C:\Program Files (x86)\ocio" -G "NMake Makefiles" E:\Tools\Research\OpenColorIO\SourceCode\imageworks-OpenColorIO-v1.0.7-17-g533f85e\imageworks-OpenColorIO-533f85e > cmake_results.txt
  • And then things get a little hairy.
    • First, no files appear in "C:\Program Files (x86)\ocio"
    • This is the result of the cmake_results.txt

-- The C compiler identification is MSVC 16.0.30319.1
-- The CXX compiler identification is MSVC 16.0.30319.1
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Setting Build Type to: Debug
-- Setting Namespace to: OpenColorIO
-- Exec prefix not specified, defaulting to C:/Program Files (x86)/ocio
-- Use Boost Ptr: OFF
-- Setting EXTDIST_BINPATH:
-- Setting EXTDIST_PYTHONPATH:
-- Generate Documentation: OFF
-- SSE Optimizations: ON
-- Could NOT find Truelight (missing:  Truelight_INCLUDE_DIR Truelight_LIBRARIES Truelight_LIBRARY_DIR)
-- Not building truelight transform support. Add the flag -D TRUELIGHT_INSTALL_PATH=... or set the TRUELIGHT_ROOT environment variable
-- Create OpenColorABI.h from OpenColorABI.h.in
-- Setting OCIO SOVERSION to: 1
-- Setting OCIO SOVERSION to: 1
-- Create OpenColorIO.pc from OpenColorIO.pc.in
-- Build Unit Tests: OFF
-- OIIO not found. Specify OIIO_PATH to locate it
-- Not building ocioconvert/ociolutimage. Requirement(s) found: OIIO:FALSE
-- Found OpenGL: opengl32 
-- Found OpenGL library glu32;opengl32
-- Found OpenGL includes
-- Could NOT find GLUT (missing:  GLUT_glut_LIBRARY GLUT_INCLUDE_DIR)
-- GLUT not found
-- GLEW not found
-- Not building ociodisplay. Requirement(s) found, OpenGL:TRUE, GLUT:FALSE, GLEW:FALSE, OIIO:FALSE
-- Could NOT find PkgConfig (missing:  PKG_CONFIG_EXECUTABLE)
-- Using bundled lcms.
-- Could NOT find Nuke (missing:  Nuke_INCLUDE_DIR Nuke_LIBRARIES Nuke_LIBRARY_DIR)
-- Not building Nuke plugins. Add the flag -D NUKE_INSTALL_PATH=... or set the NDK_PATH environment variable
-- Python bindings will not be built:
-- Configuring done
-- Generating done
-- Build files have been written to: E:/Tools/Research/OpenColorIO/SourceCode/tmp/ociobuild

I understand that the applications are building and that the Python bindings aren't as well. This is not a problem.

Possible areas of trouble:
  • I don't have Boost installed, BUT I am running VS2010. Do I still need to install Boost?
  • I didn't set the build to be a "release" build


Alternate attempt:

I've also tried compiling this from VS2010 by starting with cmake. This time though I use this cmake call:

  • cmake -D CMAKE_INSTALL_PREFIX="C:\Program Files (x86)\ocio" E:\Tools\Research\OpenColorIO\SourceCode\imageworks-OpenColorIO-v1.0.7-17-g533f85e\imageworks-OpenColorIO-533f85e -G "Visual Studio 10 Win64" > cmake_results.txt
    • I get the same result if I do not specify a makefile generator with the "-G" flag (except that the .sln file is built for win32)
This creates a series of VS2010 projects and a single solution (.sln) file in the \tmp\ociobuild directory. I open the OpenColorIO.sln file. So I open the .sln and build ALL_BUILD. The first error I receive is that Patch.exe has unexpectedly quit. It took me a while to track down exactly what "patch.exe" was. It's the Perl patch function installed with my "strawberry" flavor of Perl.
So my next question is:
Q: Is there a specific flavor or version of Perl for the windows environment to properly build OCIO?

Lastly, I keep getting multiple errors about OCIO needing gcc 4 or later to get access to <tr1/memory> and it suggests that instead I should specify USE_BOOST_PTR. So, it looks like I should install Boost and recompile.

I know I'm going to have more questions so I'll end this here and keep investigating.

Thank you


Cinematic Color Course Notes

Jeremy Selan <jeremy...@...>
 

A shameless plug:

The course notes for "Cinematic Color" are now available for download
at cinematiccolor.com. My intent is to continue updating this document
in the future with additions and corrections as needed.*

And don't forget for those attending siggraph, to stop by and see the
course in person Tuesday at 9AM. There won't be enough time to cover
everything in the pdf, but my hope is to throw enough details into the
class to keep it interesting for folks at all levels of expertise.

Cheers,
Jeremy

* Both the website and the pdf are backed by a github repo - how cool! :)


Re: Message via your Google Profile: OCIO Colorspaces

Jeremy Selan <jeremy...@...>
 

On Thu, Aug 2, 2012 at 1:11 AM, Nhat Phong Tran
<nhatpho...@...> wrote:
Hi! I think I got most part of OCIO configs now. The only few
questions that I have left are

- COLORSPACE_DIR_TO_REFERENCE, what is that exactly supposed to mean?
Practically it seemed like one was just the inverse of the same
transformation. Should I be aware of anything that could be breaking
in the future if I have swapped TO and FROM but with the inverted
transform on one of the settings (thus getting the same result w/ both
TO and FROM).

You can specify the set of transforms (luts, matricies, etc) either
"to reference", "from reference", or both. Most of the time, it's
only required to specify the transform in one of the directions, and
users are free to do which ever is most convenient. There is
absolutely no difference in the result for tranform chains which are
"trivially invertible" (matricies, 1dluts, gamma, etc). however, if
user utilize 3d luts OCIO will not make any attempt to automatically
provide the inverse transform. In these cases a user who wanted to
specify both the inverse and reverse transform, referencing separate
files, is free to do so.

- allocation vars is that something that only affects viewing the
images or also the transformation from one colorspace to another?
This used to be called GPUAllocationVars, and perhaps we should have
left it with that name. This only affects image display on
applications which utilize the GPU pathway (including Katana, Mari,
etc). This does not impact the CPU processing. Setting up the
allocation vars is currently a subtle operation, which requires a bit
too much special knowledge. I've put together this web page,
http://opencolorio.org/configurations/allocation_vars.html, but it
definitely needs a bit more details.

We have some code improvement ideas related to AllocationVars which
will hopefully make it less magical to write configs (and easier to
test!) and hope to have time to implement these post siggraph.

- what is that setIsData() for? Isn't this just like raw if true and done?
data spaces are intended to denote spaces used for 'data' (normals,
depth, etc.) They are handled specially inside OCIO, in that all
colorspace transforms to or from a 'data' space is ALWAYS a no-op.
This is particularly important inside the DisplayTransform (used
inside the viewer), because it means that even if an app asks for a
'scene-linear' exposure change, or a 'color timing cc', they can be
assured that on data image no accidental color-specific conversions
will be applied.

- how's the RRT in the ACES config specified? To me it should start
with a scene-linear to inverted adx10 conversion, but what comes next?
I've not managed to reproduce the ACES RRT in the config.
https://github.com/imageworks/OpenColorIO-Configs/blob/master/aces/README

ociolutimage is used to make an exr, representing a 3d lattice, with
an analytical log encoding:

ociolutimage --generate --colorconvert log aces --output log_aces.exr
ctlrender then applies both the rrt and ODT
ctlrender -ctl rrt/rrt.ctl -ctl odt/p3d60/odt_p3d60.ctl log_aces.exr rrt_ut33_p3d60.exr
ociolutimage then converts the exr lattice to a 3dlut:
ociolutimage --extract --input rrt_ut33_p3d60.exr --output rrt_ut33_p3d60.spi3d
(cc'ing ocio-dev)

-- Jeremy


Re: Siggraph Events

Jeremy Selan <jeremy...@...>
 

After feedback from the community, I think its probably simplest to
NOT have an OpenColorIO BOF this year. Given that we wont have the
opportunity to prepare a rockin' BOF presentation, and that people's
time Siggraph week is really precious, I think it makes the most sense
to meet instead at the already scheduled color events:

Tuesday 9 AM, 408A: "Cinematic Color", (with an informal hangout /
discussion immediately following)
Wednesday 7PM, Cork Bar. "Open Source VFX Beer of a Feather".

Next year I promise to put together an awesome OCIO BOF, something at
least twice as good as usual. ;)

And stay tuned for some really exciting announcements post-siggraph,
concerning commercial apps which will soon have native OCIO support.

Cheers,
Jeremy

1161 - 1180 of 2242