Date   

Re: .CDL in addition to .CC and .CCC?

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

On Fri, Nov 24, 2017 at 7:39 AM, Abraham Schneider <abraham....@...> wrote:
I would really like to see OCIO support .cdl files in addition to .cc and .ccc as an direct input for the FileTransform and CDLTransform.

Of course there are ways and tools like cdl_convert to convert files between the different CDL formats, so you could batch convert them before using. But if a pipeline/tool is already using .cdl, it would be so helpful to be able to use these files directly in Nuke etc., or for example in a custom .ocio config where you want to use contexts with separate CDL values per shot that already exist as .cdl files.

Thanks, Abraham

--
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.


.CDL in addition to .CC and .CCC?

Abraham Schneider <abraham....@...>
 

I would really like to see OCIO support .cdl files in addition to .cc and .ccc as an direct input for the FileTransform and CDLTransform.

Of course there are ways and tools like cdl_convert to convert files between the different CDL formats, so you could batch convert them before using. But if a pipeline/tool is already using .cdl, it would be so helpful to be able to use these files directly in Nuke etc., or for example in a custom .ocio config where you want to use contexts with separate CDL values per shot that already exist as .cdl files.

Thanks, Abraham


Re: OCIO 1.0.10

Jeremie Gerhardt <jeremie....@...>
 

hi all, 

I like to join the Slack conversation as well.

Thank you, 

Jeremie

On Wednesday, April 26, 2017 at 1:31:50 PM UTC-4, 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: Review: FileTransform will try all lut formats (if the initial read fails)

Matt Plec <mp...@...>
 

I've also gotten away with putting no extension on them. It felt a little ropey, but not quite as misleading or prone to creating further problems if someone picked up the file and tried to use it otherwise. At least if there's no extension you have to look in the file and see what it is instead of just assuming.


On Mon, Nov 13, 2017 at 5:58 AM, <er...@...> wrote:
Figured out i could rename the cube to cc and ocio identified it correctly anyways.


On Monday, November 13, 2017 at 2:56:51 PM UTC+1, Erik Johansson wrote:
Digging this up

I have a config setup looking for $SHOT.cc but client decided to start sending .cube files instead

How would the config file need to look for this fallback to work?

On Monday, November 15, 2010 at 7:12:57 PM UTC+1, Jeremy Selan wrote:
In the absence of any objections, I will check this into master.

-- Jeremy

--
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: Review: FileTransform will try all lut formats (if the initial read fails)

er...@...
 

Figured out i could rename the cube to cc and ocio identified it correctly anyways.


On Monday, November 13, 2017 at 2:56:51 PM UTC+1, Erik Johansson wrote:
Digging this up

I have a config setup looking for $SHOT.cc but client decided to start sending .cube files instead

How would the config file need to look for this fallback to work?

On Monday, November 15, 2010 at 7:12:57 PM UTC+1, Jeremy Selan wrote:
In the absence of any objections, I will check this into master.

-- Jeremy


Re: Review: FileTransform will try all lut formats (if the initial read fails)

er...@...
 

Digging this up

I have a config setup looking for $SHOT.cc but client decided to start sending .cube files instead

How would the config file need to look for this fallback to work?


On Monday, November 15, 2010 at 7:12:57 PM UTC+1, Jeremy Selan wrote:
In the absence of any objections, I will check this into master.

-- Jeremy


Re: Using environment variables/context to point to a colorspace

Jonas Lindfors <jonas.l...@...>
 

Awesome!

On Mon, Nov 6, 2017 at 9:48 PM, Patrick Hodoul <patric...@...> wrote:
Please refer to pull request #477


On Thursday, November 2, 2017 at 12:12:47 PM UTC-4, jonas...@... wrote:
Hi guys. Does anyone know if this is solved? Is it possible to use variables to point to a colorspace?

On Thursday, June 12, 2014 at 1:14:36 AM UTC+2, do...@... wrote:
Hi,

I did post this question to OCIO-users and did not get any reaction, so I'm trying here as it might be a question related to development. Anyway I'm sorry if this is against posting rules.



I've been implementing OCIO at our company. Thanks a lot for your efforts with this project, it is making things a lot easier for me, and more future proof.

I'm using per-shot viewer luts using context variables inside the OCIO nodes in Nuke. That works like it is supposed to. 

I'm facing some difficulties from the fact that on our projects (mostly television commercials) we frequently get footage shot with different cameras. I'd like to find a system to avoid having to tell the artist which camera has been used for which shot. I'd like to define a 'CameraRaw' colorspace that would point to other colorspaces in function of a context. So for example I would define it like this :


- !<ColorSpace>
    name: CameraRaw
    family: ""
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Camera Raw depends on context
    isdata: false
    allocation: uniform
    allocationvars: [-0.125, 1.125]
    from_reference: !<ColorSpaceTransform> {src: linear, dst: $CAMERARAW}

I tried this and in Nuke I used an OCIO colorspace node, setting the out colorspace to CameraRaw, and setting the context of the node of key1 =CAMERARAW and value1 = Alexa_Rec709
Of course the Alexa_Rec709 colorspace is also defined in the config file.

When I do this get an error from Nuke's viewer. OCIOColorSpace1: BuildColorSpaceOps failded, null dstColorSpace.

I'm not sure this is a bug report or a feature request. Anyway I think it would be quite valuable to be able to use context variables/environement variables to not only point to files on the disk but to other colorspaces as well.

Regards

Donat Van Bellinghen

--
You received this message because you are subscribed to a topic in the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ocio-dev/Pj3SJs-hW6U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
CHIMNEY
Jonas Lindfors
VFX Artist

CHIMNEY
Skeppsbron 38
111 30 Stockholm
Mobile: +46 706 530 538
www.chimneygroup.com

Constantly challenging ourselves and our clients
to engage the audience through innovation and creation


Re: Using environment variables/context to point to a colorspace

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

Please refer to pull request #477


On Thursday, November 2, 2017 at 12:12:47 PM UTC-4, jonas...@... wrote:
Hi guys. Does anyone know if this is solved? Is it possible to use variables to point to a colorspace?

On Thursday, June 12, 2014 at 1:14:36 AM UTC+2, do...@... wrote:
Hi,

I did post this question to OCIO-users and did not get any reaction, so I'm trying here as it might be a question related to development. Anyway I'm sorry if this is against posting rules.



I've been implementing OCIO at our company. Thanks a lot for your efforts with this project, it is making things a lot easier for me, and more future proof.

I'm using per-shot viewer luts using context variables inside the OCIO nodes in Nuke. That works like it is supposed to. 

I'm facing some difficulties from the fact that on our projects (mostly television commercials) we frequently get footage shot with different cameras. I'd like to find a system to avoid having to tell the artist which camera has been used for which shot. I'd like to define a 'CameraRaw' colorspace that would point to other colorspaces in function of a context. So for example I would define it like this :


- !<ColorSpace>
    name: CameraRaw
    family: ""
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Camera Raw depends on context
    isdata: false
    allocation: uniform
    allocationvars: [-0.125, 1.125]
    from_reference: !<ColorSpaceTransform> {src: linear, dst: $CAMERARAW}

I tried this and in Nuke I used an OCIO colorspace node, setting the out colorspace to CameraRaw, and setting the context of the node of key1 =CAMERARAW and value1 = Alexa_Rec709
Of course the Alexa_Rec709 colorspace is also defined in the config file.

When I do this get an error from Nuke's viewer. OCIOColorSpace1: BuildColorSpaceOps failded, null dstColorSpace.

I'm not sure this is a bug report or a feature request. Anyway I think it would be quite valuable to be able to use context variables/environement variables to not only point to files on the disk but to other colorspaces as well.

Regards

Donat Van Bellinghen


Re: Using environment variables/context to point to a colorspace

jonas.l...@...
 

Hi guys. Does anyone know if this is solved? Is it possible to use variables to point to a colorspace?


On Thursday, June 12, 2014 at 1:14:36 AM UTC+2, do...@... wrote:
Hi,

I did post this question to OCIO-users and did not get any reaction, so I'm trying here as it might be a question related to development. Anyway I'm sorry if this is against posting rules.



I've been implementing OCIO at our company. Thanks a lot for your efforts with this project, it is making things a lot easier for me, and more future proof.

I'm using per-shot viewer luts using context variables inside the OCIO nodes in Nuke. That works like it is supposed to. 

I'm facing some difficulties from the fact that on our projects (mostly television commercials) we frequently get footage shot with different cameras. I'd like to find a system to avoid having to tell the artist which camera has been used for which shot. I'd like to define a 'CameraRaw' colorspace that would point to other colorspaces in function of a context. So for example I would define it like this :


- !<ColorSpace>
    name: CameraRaw
    family: ""
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Camera Raw depends on context
    isdata: false
    allocation: uniform
    allocationvars: [-0.125, 1.125]
    from_reference: !<ColorSpaceTransform> {src: linear, dst: $CAMERARAW}

I tried this and in Nuke I used an OCIO colorspace node, setting the out colorspace to CameraRaw, and setting the context of the node of key1 =CAMERARAW and value1 = Alexa_Rec709
Of course the Alexa_Rec709 colorspace is also defined in the config file.

When I do this get an error from Nuke's viewer. OCIOColorSpace1: BuildColorSpaceOps failded, null dstColorSpace.

I'm not sure this is a bug report or a feature request. Anyway I think it would be quite valuable to be able to use context variables/environement variables to not only point to files on the disk but to other colorspaces as well.

Regards

Donat Van Bellinghen


Re: After Effects OCIO Plugin code age

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

Oh ok, good to know, I had assumed they were independent. This should be fine then, thanks!

On Fri, Oct 27, 2017 at 12:12 PM, Brendan Bolles <bre...@...> wrote:
On Thursday, October 26, 2017 at 6:44:29 PM UTC-7, Sean Cooper wrote:
I'll have to look at this shortly. Before I go too far, do you think you could separate it into two pull requests? One for the AE plugin and another for the PS plugin? It will allow for separate discussion on each.


I could pull them apart if absolutely necessary, but since they sort of depend on each other it's easier said than done. For example, I made some changes to the AE files so that the Photoshop plug-in could use it too.

But I don't think there should be a need for too much discussion. There are no changes to the main OCIO codebase and I'm the only ones working on these. They don't even get built by CMake because there are a few Adobe SDK build quirks that we haven't been able to accommodate with CMake.

--
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 Thursday, October 26, 2017 at 6:44:29 PM UTC-7, Sean Cooper wrote:
I'll have to look at this shortly. Before I go too far, do you think you could separate it into two pull requests? One for the AE plugin and another for the PS plugin? It will allow for separate discussion on each.


I could pull them apart if absolutely necessary, but since they sort of depend on each other it's easier said than done. For example, I made some changes to the AE files so that the Photoshop plug-in could use it too.

But I don't think there should be a need for too much discussion. There are no changes to the main OCIO codebase and I'm the only ones working on these. They don't even get built by CMake because there are a few Adobe SDK build quirks that we haven't been able to accommodate with CMake.


Re: After Effects OCIO Plugin code age

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

Wonderful, thanks for the effort Brendan!

I'll have to look at this shortly. Before I go too far, do you think you could separate it into two pull requests? One for the AE plugin and another for the PS plugin? It will allow for separate discussion on each.

Virus-free. www.avast.com

On Thu, Oct 26, 2017 at 6:10 PM, Brendan Bolles <bre...@...> wrote:
On Monday, August 14, 2017 at 2:08:10 PM UTC-7, Deke Kincaid wrote:
Now that we have Sean actively accepting changes you can probably update with your newer pull requests for AE and Photoshop.


OK, I have a new pull request that should have everything up to date.



 

--
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 2:08:10 PM UTC-7, Deke Kincaid wrote:
Now that we have Sean actively accepting changes you can probably update with your newer pull requests for AE and Photoshop.


OK, I have a new pull request that should have everything up to date.

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


 


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.

561 - 580 of 2190