You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The documentation for ctlrender’s scaling of integer content reads like this:
> ctlrender -help scale
input and output value scaling:
To deal with differences in input and output file bit depth, the ability
to scale input and output values has been provided. While these options
are primarily of use for integral file formats, they can be used with
file formats that store data in floating point or psuedo-floating point
formats. The default handling of the input and output scaling is variant
on the format of the input (and output) file, but is intended to behave
as one expects.
integral input files (integer tiff, integer dpx):
If the '-input_scale' option is provided then the sample value from
the file is *divided by* the specified scale.
If the '-input_scale' option is not provided, then the input values
are scaled to the range 0.0-1.0 (inclusive). For the purposes of
this argument, DPX files are considered an integral file format,
however ACES files are *not*. This is equivalent to specifying
-input_scale <bits_per_sample_in_input_file>
floating point input files (exr, floatint point TIFF, floating point
dpx):
If the '-input_scale' option is provided then the sample values
are *multiplied by* the scale value.
If the '-input_scale' option is not provided then the sample values
from the file is used as-is (with a scale of 1.0).
integral output files (integer tiff, integer dpx):
If the '-output_scale' option is provided then the sample value from
the CTL transformation is *multiplied by* the scale factor.
If the '-output_scale' option is not provided, then the values of
0.0-1.0 from the CTL transformation are scaled to the bit depth of
the output file. For the purposes of this argument, DPX files are
considered an integral file format, however ACES files are *not*.
This is equivalent to specifying
-output_scale <bits_per_sample_in_output_file>
floating point output files (exr, floatint point TIFF, floating point
dpx):
If the '-output_scale' option is provided then the sample values
are *divided by* the scale value.
If the '-output_scale' option is not provided then the sample values
from the file is used as-is (with a scale of 1.0).
In all cases the CTL output values (after output_scaling) are clipped
to the maximum values supported by the output file format.
The final sentences of the paragraphs on integral input and output files say This is equivalent to specifying -input_scale <bits_per_sample_in_input_file> and This is equivalent to specifying -output_scale <bits_per_sample_in_output_file>
Is that correct? I would think the equivalences was to specifying -input_scale 2^<bits_per_sample_in_input_file> - 1 and -output_scale 2^<bits_per_sample_in_output_file> - 1
If the -help scale output is incorrect, this should be fixed. In practice, actual behavior does not seem to correlate with the documentation. It would be helpful to have an example provided for each option to make clear when and how one might use each option.
The text was updated successfully, but these errors were encountered:
The documentation for ctlrender’s scaling of integer content reads like this:
The final sentences of the paragraphs on integral input and output files say
This is equivalent to specifying -input_scale <bits_per_sample_in_input_file>
andThis is equivalent to specifying -output_scale <bits_per_sample_in_output_file>
Is that correct? I would think the equivalences was to specifying
-input_scale 2^<bits_per_sample_in_input_file> - 1
and-output_scale 2^<bits_per_sample_in_output_file> - 1
If the
-help scale
output is incorrect, this should be fixed. In practice, actual behavior does not seem to correlate with the documentation. It would be helpful to have an example provided for each option to make clear when and how one might use each option.The text was updated successfully, but these errors were encountered: