Broken relation between aces_to_acesLog16i output and acesLog16i_to_aces input about aces-dev HOT 3 CLOSED

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.

from aces-dev.

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?

from aces-dev.

In ACES Version 1.0, ACESlog is replaced with ACEScc.

from aces-dev.