Default behavior when input and output files are different bit depths seems unexpected

[scottdyer]

When input file is 10-bit, and output file is 16-bit OpenEXR, the following error is received:
"exception thrown (oops...): EXR files only support 16 or 32 bps at the moment."

This may actually be the intended behavior, but it seems like ctlrender should automatically scale correctly when the input format is an integral file and the output file is floating point. Adding an explicit -format exr16 works but the default behavior seems different than it was prior to CTL 1.5.

To reproduce, run the following line using the Sony F35 IDT available from aces-dev on the SonyF35.StillLife.dpx file available from the reference images 'camOrig' directory also available on aces-dev. For testing, I have used the 10-bit S-Log DPX file through the Sony F35 IDT.

This throws the exception:

ctlrender -ctl ~/aces-dev/transforms/ctl/idt/vendorSupplied/sony/F35/idt-SonyF35-10i.ctl -param1 aIn 1.0 SonyF35.StillLife.dpx  test_idt.exr

This will work:

ctlrender -ctl ~/aces-dev/transforms/ctl/idt/vendorSupplied/sony/F35/idt-SonyF35-10i.ctl -param1 aIn 1.0 SonyF35.StillLife.dpx  test_idt.exr -format exr16

[aforsythe]

This issue may have been introduced when the 32 bps output file option was added.

When specifying an integral input and output file type ctlrender will, by default, match the bit depth of the input file. That's not supposed to be the case for floating point file types. Prior to adding 32f exr files, specifying -format exr caused the files to scale and write as expected. Now it seems as if ctlrender is trying to match the bit depth of the 10-bit input file and write a 10-bit EXR, hence the error.

16-bit exr should be the default for the .exr extension and scaling should happen automatically regardless of the bit depth of the integral input file.

Alex

Alexander Forsythe - Imaging Engineering Manager - Science and Technology Council

Academy of Motion Picture Arts and Sciences - Tel 310-247-3000 x3310
Fax 310-247-3611 - www.oscars.org - aforsythe@oscars.org

On Feb 3, 2014, at 3:10 PM, Scott Dyer notifications@github.com wrote:

When input file is 10-bit, and output file is 16-bit OpenEXR, the following error is received:
"exception thrown (oops...): EXR files only support 16 or 32 bps at the moment."

This may actually be the intended behavior, but it seems like ctlrender should automatically scale correctly when the input format is an integral file and the output file is floating point. Adding an explicit -format exr16 works but the default behavior seems different than it was prior to CTL 1.5.

To reproduce, run the following line using the Sony F35 IDT available from aces-dev on the SonyF35.StillLife.dpx file available from the reference images 'camOrig' directory also available on aces-dev. For testing, I have used the 10-bit S-Log DPX file through the Sony F35 IDT.

This throws the exception:

ctlrender -ctl ~/aces-dev/transforms/ctl/idt/vendorSupplied/sony/F35/idt-SonyF35-10i.ctl -param1 aIn 1.0 SonyF35.StillLife.dpx test_idt.exr

This will work:

ctlrender -ctl ~/aces-dev/transforms/ctl/idt/vendorSupplied/sony/F35/idt-SonyF35-10i.ctl -param1 aIn 1.0 SonyF35.StillLife.dpx test_idt.exr -format exr16

—
Reply to this email directly or view it on GitHub.

[scottdyer]

In lieu of a default of 16-bits and automatic scaling regardless of the bit depth of the input file, the error message “EXR files only support 16 or 32 bps at the moment.” could be changed to say (since the code throwing the error clearly has knowledge of the requested bit depth)
“EXR files only support 16 or 32 bits per sample; the implicitly requested 10 bits per sample is unsupported. Use -format exr16 or -format exr32 to explicitly request 16-bit or 32-bit floating-point EXR output.”
However, adding automatic scaling and allowing for override using -format exr32 seems the more elegant solution.