Date   

Re: LUT tables in OCIO

Gonzalo Garramuno <ggar...@...>
 


      c.rgb = exp( scale * texture3D(lut, c.rgb).rgb + offset ); 

Sorry, that should have been:
 
c.rgb = exp( tex3D(lut, c.rgb * scale + offset ).rgb );


Re: LUT tables in OCIO

Gonzalo Garramuno <ggar...@...>
 


  if (enableLut)
    {
      c.rgb = lutT + lutM * log( clamp(c.rgb, lutMin, lutMax) );
      c.rgb = exp( texture3D(lut, c.rgb).rgb ); 
    }


I was able to match the output of ociodisplay with a NUM_STOPS of 8, a lattice of 64x64x64 and with the following change to the shader code: 

      c.rgb = exp( scale * texture3D(lut, c.rgb).rgb + offset ); 

where scale and offset are based on the lut edge len, as shown in the original Sony Imageworks' GPUGems 2, chapter 24.

Now I need to understand why the GpuShaderDesc of OCIO spits out some more vector multiplications before the shader look up.  That seems to improve the lookup so that only a lattice of 32x32x32 is needed.


3D Lut from PackedImageDesc processor

Gonzalo Garramuño <ggar...@...>
 

I have a GL Lut that is not created with OCIO.  Instead an initial identity lut is created and this lut is passed on to the gfx card by my own code.  So long, so good.  However, this lut is not a perfect match and it fails in some images, like the sample openexr syntheticCard.exr.

My code is largely based on OpenEXR code.  I init the lut like:

--
void GLLut3d::init_pixel_values( Imf::Array< float >& pixelValues )
{
//
// Compute lutMin, lutMax, and scale and offset
// values, lutM and lutT, so that
//
// lutM * lutMin + lutT == 0
// lutM * lutMax + lutT == 1
//

static const float MIDDLE_GRAY = 0.18f;
static const int NUM_STOPS = 10:

lutMin = MIDDLE_GRAY / (1 << NUM_STOPS);
lutMax = MIDDLE_GRAY * (1 << NUM_STOPS);
float logLutMin = logf (lutMin);
float logLutMax = logf (lutMax);

lutM = 1 / (logLutMax - logLutMin);
lutT = -lutM * logLutMin;

//
// Build a 3D array of RGB input pixel values.
// such that R, G and B are between lutMin and lutMax.
//
for (size_t ib = 0; ib < _lutN; ++ib)
{
float b = float(ib) / float(_lutN - 1.0);
float B = expf((b - lutT) / lutM);

for (size_t ig = 0; ig < _lutN; ++ig)
{
float g = float(ig) / float(_lutN - 1.0);
float G = expf ((g - lutT) / lutM);

for (size_t ir = 0; ir < _lutN; ++ir)
{
float r = float(ir) / float(_lutN - 1.0);
float R = expf ((r - lutT) / lutM);

size_t i = (ib * _lutN * _lutN + ig * _lutN + ir) * 4;
pixelValues[i + 0] = R;
pixelValues[i + 1] = G;
pixelValues[i + 2] = B;
pixelValues[i + 3] = 1.0f;
}
}
}
}

// This is the main OCIO calculation routine

bool GLLut3d::calculate_ocio( const CMedia* img )
{
//
// We build a 3D color lookup table by running a set of color
// samples through a series of OCIO transforms.
//
// The 3D lookup table covers a range from lutMin to lutMax or
// NUM_STOPS f-stops above and below 0.18 or MIDDLE_GRAY. The
// size of the table is _lutN by _lutN by _lutN samples.
//
// In order make the distribution of the samples in the table
// approximately perceptually uniform, the Cg shaders that use
// the table perform lookups in "log space":
// In a Cg shader, the lookup table is represented as a 3D texture.
// In order to apply the table to a pixel value, the Cg shader takes
// the logarithm of the pixel value and scales and offsets the result
// so that lutMin and lutMax map to 0 and 1 respectively. The scaled
// value is used to perform a texture lookup and the shader computes
// e raised to the power of the result of the texture lookup.
//
//
// Generate output pixel values by applying CTL transforms
// to the pixel values. (If the CTL transforms fail to
// write to the output values, zero-initialization, above,
// causes the displayed image to be black.)
//
if ( !_inited )
{
//
// Init lut table to 0
//
clear_lut();

//
// Init table of pixel values
//
init_pixel_values( lut );
}
try
{
OCIO::ConstConfigRcPtr config = OCIO::GetCurrentConfig();
const std::string& display = mrv::Preferences::OCIO_Display;
const std::string& view = mrv::Preferences::OCIO_View;
OCIO::DisplayTransformRcPtr transform = OCIO::DisplayTransform::Create();
std::string ics = img->ocio_input_color_space();
if ( ics.empty() )
{
OCIO::ConstColorSpaceRcPtr defaultcs = config->getColorSpace(OCIO::ROLE_SCENE_LINEAR);
if(!defaultcs)
throw std::runtime_error( _("ROLE_SCENE_LINEAR not defined." ));
ics = defaultcs->getName();
}
transform->setInputColorSpaceName( ics.c_str() );
transform->setDisplay( display.c_str() );
transform->setView( view.c_str() );
OCIO::ConstContextRcPtr context = config->getCurrentContext();
OCIO::ConstProcessorRcPtr processor =
config->getProcessor(context, transform,
OCIO::TRANSFORM_DIR_FORWARD);

OCIO::PackedImageDesc img(&lut[0], lut_size()/4,
/*height*/ 1, /*channels*/ 4);
processor->apply( img );
_inited = true;
}
catch(OCIO::Exception& e)
{
OCIO_ERROR( e.what() );
return false;
}
catch( const std::exception& e )
{
LOG_ERROR( e.what() );
return false;
}
catch( ... )
{
LOG_ERROR( _("Unknown error returned from OCIO processor") );
return false;
}
return true;
}



//
// This is the main routine to create the gl 3d texture
// Create opengl texture from the log of lut values
//
void GLLut3d::create_gl_texture()
{
//
// Take the logarithm of the output values that were
// produced by the CTL transforms.
//

size_t num = lut_size();
for ( size_t i = 0; i < num; ++i )
{
if ( lut[i] >= std::numeric_limits<float>::min()
&& lut[i] <= std::numeric_limits<float>::max() )
{
//
// lut[i] is finite and positive.
//
lut[i] = (float) logf(lut[i]);
}
else
{
//
// lut[i] is zero, negative or not finite;
// log (lut[i]) is undefined.
//
lut[i] = (float) logf( std::numeric_limits<float>::min() );
}
}

//
// Convert the output values into a 3D texture.
//
glPixelStorei( GL_UNPACK_ROW_LENGTH, 0 );
glPixelStorei( GL_UNPACK_ALIGNMENT, 1 );

glActiveTexture( GL_TEXTURE3 );

glBindTexture( GL_TEXTURE_3D, texId );

glTexParameteri( GL_TEXTURE_3D, GL_TEXTURE_MIN_FILTER, GL_LINEAR );
glTexParameteri( GL_TEXTURE_3D, GL_TEXTURE_MAG_FILTER, GL_LINEAR );

GLenum gl_clamp = GL_CLAMP;
if ( GLEW_EXT_texture_edge_clamp )
gl_clamp = GL_CLAMP_TO_EDGE;

glTexParameteri( GL_TEXTURE_3D, GL_TEXTURE_WRAP_R, gl_clamp );
glTexParameteri( GL_TEXTURE_3D, GL_TEXTURE_WRAP_S, gl_clamp );
glTexParameteri( GL_TEXTURE_3D, GL_TEXTURE_WRAP_T, gl_clamp );


glTexImage3D( GL_TEXTURE_3D,
0, // level
GL_RGBA32F, // internal format
_lutN, _lutN, _lutN, // width, height, depth
0, // border
GL_RGBA, // format
GL_FLOAT, // type
(char *) &lut[0] );
}

--
 Gonzalo Garramuño


LUT tables in OCIO

ggar...@...
 

Currently, I am using OCIO with a mixed CPU/GPU pipeline.  Luts are 4 float colors which get fed like:


    //
    // Compute lutMin, lutMax, and scale and offset
    // values, lutM and lutT, so that
    //
    // lutM * lutMin + lutT == 0
    // lutM * lutMax + lutT == 1
    //
void init_pixel_values( float* pixelValues )
{
    static const float MIDDLE_GRAY = 0.18f;
    static const int NUM_STOPS = 10;

    lutMin = MIDDLE_GRAY / (1 << NUM_STOPS);
    lutMax = MIDDLE_GRAY * (1 << NUM_STOPS);
    
    float logLutMin = logf (lutMin);
    float logLutMax = logf (lutMax);

    lutM = 1 / (logLutMax - logLutMin);
    lutT = -lutM * logLutMin;

    //
    // Build a 3D array of RGB input pixel values.
    // such that R, G and B are between lutMin and lutMax.
    //
    for (size_t ib = 0; ib < _lutN; ++ib)
    {
        float b = float(ib) / float(_lutN - 1.0);
        float B = expf((b - lutT) / lutM);

for (size_t ig = 0; ig < _lutN; ++ig)
  {
              float g = float(ig) / float(_lutN - 1.0);
              float G = expf ((g - lutT) / lutM);

    for (size_t ir = 0; ir < _lutN; ++ir)
      {
                  float r = float(ir) / float(_lutN - 1.0);
                  float R = expf ((r - lutT) / lutM);

                  size_t i = (ib * _lutN * _lutN + ig * _lutN + ir) * 4;
                  pixelValues[i + 0] = R;
                  pixelValues[i + 1] = G;
                  pixelValues[i + 2] = B;
                  pixelValues[i + 3] = 1.0f;
      }
  }
      }
  }

void calculate_ocio()
{
      if ( !_inited )
      {
          //
          // Init lut table to 0
          //
          clear_lut();

          //
          // Init table of pixel values
          //
          init_pixel_values( lut );
      }

try {
          OCIO::DisplayTransformRcPtr transform = OCIO::DisplayTransform::Create();
          transform->setDisplay( display.c_str() );
          transform->setView( view.c_str() );
        
          OCIO::ConstContextRcPtr context = config->getCurrentContext();
          OCIO::ConstProcessorRcPtr processor =
          config->getProcessor(context, transform,
                               OCIO::TRANSFORM_DIR_FORWARD);
           // Create LUT
          OCIO::PackedImageDesc img(&lut[0], lut_size()/4,
                                    /*height*/ 1, /*channels*/ 4);
          processor->apply( img );
catch( const OCIOException& e )
{
LOG_ERROR( e.what() );
}


And finally, the glsl shader does:


// Images
uniform sampler2D fgImage;
uniform sampler3D lut;

// Lut variables
uniform bool  enableLut;
uniform bool  lutF;
uniform float lutMin;
uniform float lutMax;
uniform float lutM;
uniform float lutT;

void main()

  vec4 c = texture2D(fgImage, gl_TexCoord[0].st);


  if (enableLut)
    {
      c.rgb = lutT + lutM * log( clamp(c.rgb, lutMin, lutMax) );
      c.rgb = exp( texture3D(lut, c.rgb).rgb ); 
    }

  gl_FragColor = c;



This seems to work on some images and fail in others (syntheticChart.exr for example).  The problem, afaict, is in the init_pixel_values.  I am unsure what to set the minimum and maximum for that lut.  Currently, this is done like in CTL, which may not be optimal for OCIO.  I am still trying to find where in OCIO the  lut table is created, since ociodisplay seems to show color spaces better.


Re: OCIO 1.0.10

Patrick Hodoul <patric...@...>
 

Hi Sean,

What is the status for 1.0.10?

Thanks.


On Wednesday, September 20, 2017 at 9:29:12 PM UTC-4, Sean Cooper wrote:
Hi all,

Patrick Hodoul has just pushed a number of Windows build related fixes as PR #464 . If any of you have free time to look at his commits and perhaps more importantly to test the build process in your Windows environment it would be much appreciated.

Thanks!

On Wednesday, 26 April 2017 10:31:50 UTC-7, Sean Cooper wrote:
Hello all,

With a little bit of movement on the OCIO repo working towards addressing the most egregious image-quality-effecting bugs, we need to look to locking off to a 1.0.10 to help our users, and product partners.

If you haven't been watching, I invite you to take a look at the OCIO repo, and point out other image quality *bugs* that you deem a requirement for the next minor version. Prior to my involvement there have been a number of commits to master since 1.0.9, and I think it's beneficial to put a stake in the ground as a firm mark of rejuvenation. We can proceed from there.

If you haven't joined in the side Slack conversation where more day-to-day conversation has been centered, please reply below or message me personally I am more than happy to invite you. Or if you have a strong opinion against the "closed-door" conversation, I am open ears.

Thoughts, and opinions welcomed, thanks!
Sean


Re: mrViewer v3.8.4

ggar...@...
 

Thank you very much.


On Saturday, October 7, 2017 at 7:06:02 PM UTC-3, Sean Cooper wrote:
Wonderful, yes I will. Thank you.

On Sat, Oct 7, 2017 at 2:21 PM, <gga...@...> wrote:

This version of mrViewer is the first to add some support for OCIO.  Please add this software to the compatible list.

Thank you.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: mrViewer v3.8.4

Sean Cooper <se...@...>
 

Wonderful, yes I will. Thank you.

On Sat, Oct 7, 2017 at 2:21 PM, <ggar...@...> wrote:

This version of mrViewer is the first to add some support for OCIO.  Please add this software to the compatible list.

Thank you.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


mrViewer v3.8.4

ggar...@...
 

https://sourceforge.net/projects/mrviewer/files/v3.8.4

This version of mrViewer is the first to add some support for OCIO.  Please add this software to the compatible list.

Thank you.


Re: OCIO 1.0.10

Sean Cooper <se...@...>
 

Hi all,

Patrick Hodoul has just pushed a number of Windows build related fixes as PR #464 . If any of you have free time to look at his commits and perhaps more importantly to test the build process in your Windows environment it would be much appreciated.

Thanks!


On Wednesday, 26 April 2017 10:31:50 UTC-7, Sean Cooper wrote:
Hello all,

With a little bit of movement on the OCIO repo working towards addressing the most egregious image-quality-effecting bugs, we need to look to locking off to a 1.0.10 to help our users, and product partners.

If you haven't been watching, I invite you to take a look at the OCIO repo, and point out other image quality *bugs* that you deem a requirement for the next minor version. Prior to my involvement there have been a number of commits to master since 1.0.9, and I think it's beneficial to put a stake in the ground as a firm mark of rejuvenation. We can proceed from there.

If you haven't joined in the side Slack conversation where more day-to-day conversation has been centered, please reply below or message me personally I am more than happy to invite you. Or if you have a strong opinion against the "closed-door" conversation, I am open ears.

Thoughts, and opinions welcomed, thanks!
Sean


Re: After Effects OCIO Plugin code age

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

On Monday, August 14, 2017 at 5:31:29 PM UTC-7, Sean Cooper wrote:
I'll happily look at anything pushed our way.

Curious, would you be able to give a quick rundown of the PS plugin functionality / implementation?


What do you want to know? As Deke pointed out, I have a blog post where you can download it. Code is on GitHub.

It was made for use in a studio, so it's been tested. It's designed similarly to the After Effects plug-in.

This plug-in is a filter, so it can be applied to a layer to perform color space transformations. The big bummer about Photoshop is that a plug-in can't use used to modify the view continuously. It can export LUTs which can be used as a view LUT to the degree that Photoshop can do that.


Re: After Effects OCIO Plugin code age

Sean Cooper <se...@...>
 

I'll happily look at anything pushed our way.

Curious, would you be able to give a quick rundown of the PS plugin functionality / implementation?

On Mon, Aug 14, 2017 at 2:07 PM, Deke Kincaid <dekek...@...> wrote:
Yea, that's what I figured.  You have a pull request never fulfilled from 2016 so why bother with future ones. 

Now that we have Sean actively accepting changes you can probably update with your newer pull requests for AE and Photoshop.

On Mon, Aug 14, 2017 at 12:36 PM, Brendan Bolles <bre...@...> wrote:
On Monday, August 14, 2017 at 11:34:50 AM UTC-7, Sean Cooper wrote:
The latter mostly, most VFX studios that maintain the project don't actively use After Effects so it's not usually on our minds. So its also a question of, if its broken who cares enough to do something about it?


Au contraire! I've actually updated it as recently as January. See my ae_plugin_update branch:


I also have a Photoshop plug-in now in my "photoshop" branch.

I haven't done any pull requests lately because OCIO has been in hibernation until recently.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: After Effects OCIO Plugin code age

Deke Kincaid <dekek...@...>
 

Yea, that's what I figured.  You have a pull request never fulfilled from 2016 so why bother with future ones. 

Now that we have Sean actively accepting changes you can probably update with your newer pull requests for AE and Photoshop.

On Mon, Aug 14, 2017 at 12:36 PM, Brendan Bolles <bre...@...> wrote:
On Monday, August 14, 2017 at 11:34:50 AM UTC-7, Sean Cooper wrote:
The latter mostly, most VFX studios that maintain the project don't actively use After Effects so it's not usually on our minds. So its also a question of, if its broken who cares enough to do something about it?


Au contraire! I've actually updated it as recently as January. See my ae_plugin_update branch:


I also have a Photoshop plug-in now in my "photoshop" branch.

I haven't done any pull requests lately because OCIO has been in hibernation until recently.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: After Effects OCIO Plugin code age

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

On Monday, August 14, 2017 at 11:34:50 AM UTC-7, Sean Cooper wrote:
The latter mostly, most VFX studios that maintain the project don't actively use After Effects so it's not usually on our minds. So its also a question of, if its broken who cares enough to do something about it?


Au contraire! I've actually updated it as recently as January. See my ae_plugin_update branch:

https://github.com/fnordware/OpenColorIO/tree/ae_plugin_update

I also have a Photoshop plug-in now in my "photoshop" branch.

I haven't done any pull requests lately because OCIO has been in hibernation until recently.


Re: After Effects OCIO Plugin code age

Deke Kincaid <dekek...@...>
 

He also has a nice one for Photoshop

http://fnordware.blogspot.com/2017/02/opencolorio-for-photoshop.html

He hasn't made a pull request yet but you can see the source for it below
https://github.com/fnordware/OpenColorIO/tree/photoshop/src/photoshop

On Mon, Aug 14, 2017 at 12:16 PM, Sean Cooper <se...@...> wrote:
Ah great, that's good to know. I'd never get my hand on AE anytime soon so I think its fair to trust your opinion on the situation.

@cam Maybe you could be an additional tester on #405 and we can pull it in if all is in the clear

On Mon, Aug 14, 2017 at 12:12 PM, Deke Kincaid <dekek...@...> wrote:
I've used the plugin a few times.  Minus a few minor issues it works fairly well.  There is an updated pull request from 2016 though which we should probably accept.  I've used this version and not the current 5 year old version in the repo.

https://github.com/imageworks/OpenColorIO/pull/405

On Mon, Aug 14, 2017 at 11:34 AM, Sean Cooper <se...@...> wrote:
The latter mostly, most VFX studios that maintain the project don't actively use After Effects so it's not usually on our minds. So its also a question of, if its broken who cares enough to do something about it?

With OCIO going through a dry spell most effort has been focused on the core library, but it would be nice to see how the plugins hold up to modern inspection.

On Sun, Aug 13, 2017 at 6:42 PM, Cam Wright <cwr...@...> wrote:
Hi there,

I'm taking a passing glance at colour management in After Effects and
I found the OCIO plugin maintained as part of the OCIO Github project.
https://github.com/imageworks/OpenColorIO/tree/master/src/aftereffects

Appears like the code is a number of years old now though.

Before even considering implementing in our pipeline, I'd like to find
out whether the code age is a matter of "it's out of date because it
doesn't see use in the real world" or a "don't fix what isn't broken"
kind of deal.

I suspect the latter is true, but figure a quick recce not a bad idea!

Thanks.

-C

Cam Wright - Systems and Technical Resource Administrator
CUTTINGEDGE /
90 Victoria St, West End, Brisbane, QLD, 4101
T + 61 7 3013 6200    M 0420 827 007
E cwr...@... | W www.cuttingedge.com.au

/SYD /BNE /TYO

--


This email is confidential and solely for the use of the intended recipient.
  If you have received this email in error please notify the author and
delete it immediately. This email is not to be distributed without the
author's written consent. Unauthorised forwarding, printing, copying or use
is strictly prohibited and may be a breach of copyright. Any views
expressed in this email are those of the individual sender unless
specifically stated to be the views of Cutting Edge Post Pty Ltd (Cutting
Edge). Although this email has been sent in the belief that it is
virus-free, it is the responsibility of the recipient to ensure that it is
virus free. No responsibility is accepted by Cutting Edge for any loss or
damage arising in any way from receipt or use of this email.  This email may
contain legally privileged information and privilege is not waived if you
have received this email in error.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: After Effects OCIO Plugin code age

Sean Cooper <se...@...>
 

Ah great, that's good to know. I'd never get my hand on AE anytime soon so I think its fair to trust your opinion on the situation.

@cam Maybe you could be an additional tester on #405 and we can pull it in if all is in the clear

On Mon, Aug 14, 2017 at 12:12 PM, Deke Kincaid <dekek...@...> wrote:
I've used the plugin a few times.  Minus a few minor issues it works fairly well.  There is an updated pull request from 2016 though which we should probably accept.  I've used this version and not the current 5 year old version in the repo.

https://github.com/imageworks/OpenColorIO/pull/405

On Mon, Aug 14, 2017 at 11:34 AM, Sean Cooper <se...@...> wrote:
The latter mostly, most VFX studios that maintain the project don't actively use After Effects so it's not usually on our minds. So its also a question of, if its broken who cares enough to do something about it?

With OCIO going through a dry spell most effort has been focused on the core library, but it would be nice to see how the plugins hold up to modern inspection.

On Sun, Aug 13, 2017 at 6:42 PM, Cam Wright <cwr...@...> wrote:
Hi there,

I'm taking a passing glance at colour management in After Effects and
I found the OCIO plugin maintained as part of the OCIO Github project.
https://github.com/imageworks/OpenColorIO/tree/master/src/aftereffects

Appears like the code is a number of years old now though.

Before even considering implementing in our pipeline, I'd like to find
out whether the code age is a matter of "it's out of date because it
doesn't see use in the real world" or a "don't fix what isn't broken"
kind of deal.

I suspect the latter is true, but figure a quick recce not a bad idea!

Thanks.

-C

Cam Wright - Systems and Technical Resource Administrator
CUTTINGEDGE /
90 Victoria St, West End, Brisbane, QLD, 4101
T + 61 7 3013 6200    M 0420 827 007
E cwr...@... | W www.cuttingedge.com.au

/SYD /BNE /TYO

--


This email is confidential and solely for the use of the intended recipient.
  If you have received this email in error please notify the author and
delete it immediately. This email is not to be distributed without the
author's written consent. Unauthorised forwarding, printing, copying or use
is strictly prohibited and may be a breach of copyright. Any views
expressed in this email are those of the individual sender unless
specifically stated to be the views of Cutting Edge Post Pty Ltd (Cutting
Edge). Although this email has been sent in the belief that it is
virus-free, it is the responsibility of the recipient to ensure that it is
virus free. No responsibility is accepted by Cutting Edge for any loss or
damage arising in any way from receipt or use of this email.  This email may
contain legally privileged information and privilege is not waived if you
have received this email in error.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: After Effects OCIO Plugin code age

Deke Kincaid <dekek...@...>
 

I've used the plugin a few times.  Minus a few minor issues it works fairly well.  There is an updated pull request from 2016 though which we should probably accept.  I've used this version and not the current 5 year old version in the repo.

https://github.com/imageworks/OpenColorIO/pull/405

On Mon, Aug 14, 2017 at 11:34 AM, Sean Cooper <se...@...> wrote:
The latter mostly, most VFX studios that maintain the project don't actively use After Effects so it's not usually on our minds. So its also a question of, if its broken who cares enough to do something about it?

With OCIO going through a dry spell most effort has been focused on the core library, but it would be nice to see how the plugins hold up to modern inspection.

On Sun, Aug 13, 2017 at 6:42 PM, Cam Wright <cwr...@...> wrote:
Hi there,

I'm taking a passing glance at colour management in After Effects and
I found the OCIO plugin maintained as part of the OCIO Github project.
https://github.com/imageworks/OpenColorIO/tree/master/src/aftereffects

Appears like the code is a number of years old now though.

Before even considering implementing in our pipeline, I'd like to find
out whether the code age is a matter of "it's out of date because it
doesn't see use in the real world" or a "don't fix what isn't broken"
kind of deal.

I suspect the latter is true, but figure a quick recce not a bad idea!

Thanks.

-C

Cam Wright - Systems and Technical Resource Administrator
CUTTINGEDGE /
90 Victoria St, West End, Brisbane, QLD, 4101
T + 61 7 3013 6200    M 0420 827 007
E cwr...@... | W www.cuttingedge.com.au

/SYD /BNE /TYO

--


This email is confidential and solely for the use of the intended recipient.
  If you have received this email in error please notify the author and
delete it immediately. This email is not to be distributed without the
author's written consent. Unauthorised forwarding, printing, copying or use
is strictly prohibited and may be a breach of copyright. Any views
expressed in this email are those of the individual sender unless
specifically stated to be the views of Cutting Edge Post Pty Ltd (Cutting
Edge). Although this email has been sent in the belief that it is
virus-free, it is the responsibility of the recipient to ensure that it is
virus free. No responsibility is accepted by Cutting Edge for any loss or
damage arising in any way from receipt or use of this email.  This email may
contain legally privileged information and privilege is not waived if you
have received this email in error.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: After Effects OCIO Plugin code age

Sean Cooper <se...@...>
 

The latter mostly, most VFX studios that maintain the project don't actively use After Effects so it's not usually on our minds. So its also a question of, if its broken who cares enough to do something about it?

With OCIO going through a dry spell most effort has been focused on the core library, but it would be nice to see how the plugins hold up to modern inspection.

On Sun, Aug 13, 2017 at 6:42 PM, Cam Wright <cwr...@...> wrote:
Hi there,

I'm taking a passing glance at colour management in After Effects and
I found the OCIO plugin maintained as part of the OCIO Github project.
https://github.com/imageworks/OpenColorIO/tree/master/src/aftereffects

Appears like the code is a number of years old now though.

Before even considering implementing in our pipeline, I'd like to find
out whether the code age is a matter of "it's out of date because it
doesn't see use in the real world" or a "don't fix what isn't broken"
kind of deal.

I suspect the latter is true, but figure a quick recce not a bad idea!

Thanks.

-C

Cam Wright - Systems and Technical Resource Administrator
CUTTINGEDGE /
90 Victoria St, West End, Brisbane, QLD, 4101
T + 61 7 3013 6200    M 0420 827 007
E cwr...@... | W www.cuttingedge.com.au

/SYD /BNE /TYO

--


This email is confidential and solely for the use of the intended recipient.
  If you have received this email in error please notify the author and
delete it immediately. This email is not to be distributed without the
author's written consent. Unauthorised forwarding, printing, copying or use
is strictly prohibited and may be a breach of copyright. Any views
expressed in this email are those of the individual sender unless
specifically stated to be the views of Cutting Edge Post Pty Ltd (Cutting
Edge). Although this email has been sent in the belief that it is
virus-free, it is the responsibility of the recipient to ensure that it is
virus free. No responsibility is accepted by Cutting Edge for any loss or
damage arising in any way from receipt or use of this email.  This email may
contain legally privileged information and privilege is not waived if you
have received this email in error.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


After Effects OCIO Plugin code age

Cam Wright <cwr...@...>
 

Hi there,

I'm taking a passing glance at colour management in After Effects and
I found the OCIO plugin maintained as part of the OCIO Github project.
https://github.com/imageworks/OpenColorIO/tree/master/src/aftereffects

Appears like the code is a number of years old now though.

Before even considering implementing in our pipeline, I'd like to find
out whether the code age is a matter of "it's out of date because it
doesn't see use in the real world" or a "don't fix what isn't broken"
kind of deal.

I suspect the latter is true, but figure a quick recce not a bad idea!

Thanks.

-C

Cam Wright - Systems and Technical Resource Administrator
CUTTINGEDGE /
90 Victoria St, West End, Brisbane, QLD, 4101
T + 61 7 3013 6200 M 0420 827 007
E cwr...@... | W www.cuttingedge.com.au

/SYD /BNE /TYO

--


This email is confidential and solely for the use of the intended recipient.
If you have received this email in error please notify the author and
delete it immediately. This email is not to be distributed without the
author's written consent. Unauthorised forwarding, printing, copying or use
is strictly prohibited and may be a breach of copyright. Any views
expressed in this email are those of the individual sender unless
specifically stated to be the views of Cutting Edge Post Pty Ltd (Cutting
Edge). Although this email has been sent in the belief that it is
virus-free, it is the responsibility of the recipient to ensure that it is
virus free. No responsibility is accepted by Cutting Edge for any loss or
damage arising in any way from receipt or use of this email. This email may
contain legally privileged information and privilege is not waived if you
have received this email in error.


Re: SIGGRAPH 2017 - OpenColorIO Birds of a Feather

Patrick Hodoul <patric...@...>
 

That's a great news.

A better support of ACES (with new ops) and a better support of OpenGL capabilities (such as any types of texture & uniforms) will impose changes to the OCIO public API related to the GPU processor as well as lot of changes to the current implementation. So it seems to me that it would be better to wait the OCIO v2 API discussion in order to improve the current API using the SynColor OpenGL API and your OpenCL API proposals. The goal is to have a much more flexible OCIO v2 public API for the GPU support (i.e. full support of any kind of color transformations without any baking and support of several GPU languages). At that time it should be easier to understand how to proceed with the design & implementation.

Patrick.


Re: SIGGRAPH 2017 - OpenColorIO Birds of a Feather

Dithermaster <dither...@...>
 

Regarding the "No quality loss through GPU" bullet and the "Do studios maintain their own fork? / If so what features have been added" query, I have permission to contribute back our OpenCL kernel generator changes, which have no quality loss on the GPU path (unlike the OpenGL path which collapse all LUTs into one 3D LUT). If it makes sense prior to this v2.0 work, I can do that soon. However, if it makes more sense to just collaborate on the GPU support in v2.0 I can do that instead.

///d@
Dennis Adams


On Thu, Aug 3, 2017 at 10:20 AM, Sean Cooper <se...@...> wrote:
Hello all,

We've recently concluded the OpenColorIO Birds of a Feather here at SIGGRAPH 2017, so its time to mirror the discussion back to the greater community.

Central to the discussion this year was an exciting proposal put forth by the Autodesk SynColor team headed by Doug Walker. Autodesk and the OCIO leadership will be evaluating the technical feasibility of merging the SynColor codebase into OCIO as a v2.0 release. This merger would add the technical precision and flexibility of the SynColor system within the OCIO paradigm while maintaining the current open source license. A truncated list of features on the table are as follows:
  • Improved GPU renderer
  • Improved CPU renderer
  • Inversion of all transforms
  • Additional reference space
  • Rigorous ACES transforms
  • Academy/ASC Common LUT (CLF) Format & Autodesk Color Transform (CTF) Format support
  • Support ICC monitor profiles
  • Built-in common color transforms
  • A friendly API for manipulating configs
  • Config color space interchange
  • Additional descriptive color space properties
  • Comprehensive unit-tests
  • Per-shot Looks
I have attached the Birds of a Feather slides along with this email so everyone is on the same page. While the in-person discussions clearly cannot be replicated, feel free to post questions you may have on this thread.

We will maintain open communication on this forum and the Slack channel as both Autodesk and the OCIO task group work towards mutually acceptable functionality and API. So stay tuned for future updates.

Thanks!



On Tuesday, 18 July 2017 15:24:32 UTC-7, Sean Cooper wrote:
For those of you attending SIGGRAPH 2017 (conference pass required) in Los Angeles, we will be hosting a "Birds of a Feather" event for users and developers of OpenColorIO to get together and discuss anything and everything related to working with OpenColorIO.

Session Title: OpenColorIO Meetup
Date: Tuesday, 1 August
Location: LA Convention Center - Room 507
Time: 1-2pm

~Sean

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

581 - 600 of 2197