Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ctlrender scaling behavior and documention #58

Open
scottdyer opened this issue Mar 12, 2015 · 0 comments
Open

ctlrender scaling behavior and documention #58

scottdyer opened this issue Mar 12, 2015 · 0 comments

Comments

@scottdyer
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant