Broken relation between aces_to_acesLog16i output and acesLog16i_to_aces input

[irieger]

While playing with some acesLog transformations I found a problem acesLog16i_to_aces and aces_to_acesLog16i ctl files. The last converts aces to logarithmic values in the range of 0.0 to 1.0 which seem reasonable for me when looking at the way 16 bit tiffs are written. However the reverse transform (acesLog16i_to_aces) expects values in the range 0 to 65535 (max for 16 bit integer).

More analysis on this on the Google group: https://groups.google.com/forum/#!topic/academyaces/VD7Yd0Yh7Sg

[scottdyer]

Yes, the problem is ctlrender's handling of scaling values when writing various file formats. There is a note warning about this on lines 69-80:

  // **NOTE**: The scaling step below is NOT a part of the ACESlog conversion. 
  //
  // This step is only required when using ctlrender to process the images. 
  // When ctlrender sees a floating-point file as the input and an integral file 
  // format as the output, it assumes that values out the end of the transform 
  // will be floating point, and so multiplies the output values by 
  // (2^outputBitDepth)-1. Therefore, although the values of acesLog16i are the 
  // correct integer values, they must be scaled into a 0-1 range on output 
  // because ctlrender will scale them back up in the process of writing the 
  // integer file.
  // The ctlrender option -output_scale could be used for this, but it 
  // currently this option does not appear to function correctly.
  const float scalar = pow(2.,16)-1.;
  rOut = acesLog16i[0] / scalar;
  gOut = acesLog16i[1] / scalar;
  bOut = acesLog16i[2] / scalar;

To get what you're after, either remove the scalar or set it equal to 1.

[irieger]

For my use-case it's the other way round. I like that aces_to_aceslog16i.ctl scles the values to a 0-1 range but don't understand why on the other side acesLog16i_to_aces.ctl is expecting values in the integer range 0-65535.

So it either works with acesLog files written from ctlrender (for testing purpose) nor with a chain of "-ctl aces_to_acesLog16i.ctl -ctl acesLog16i_to_aces.ctl" which I would expect to be a unity function when combined.

I'm using modified acesLog and acesProxy CTL files now anyway but I think it should be one of two way:

1. acesLog16i_to_aces is also expecting an input scale of 0-1 or
2. aces_to_acesLog16i converts to 0-65535.

Just to have a consistent transform chain. And maybe an information somewhere for people looking into this. But just getting a fully black image when converting through acesLog16i_to_aces due to it's different input range shouldn't happen I'd say?

[scottdyer]

In ACES Version 1.0, ACESlog is replaced with ACEScc.