bug: ffmpeg decoding of dnx36,prores, etc. not correct

[groucho86]

Extracting an image from DNxHD or ProRes and saving it as a TIFF, PNG, etc. is darker than expected. This matches ffmpeg's default behavior when a -vf is not explicitly set.

% oiiotool --buildinfo OIIO 3.1.8.0 | MacOS/ARM Build compiler: Apple clang 17.0 | C++17/201703 HW features enabled at build: neon No CUDA support (disabled / unavailable at build time) Dependencies: BZip2 1.0.8, FFmpeg 8.0, fmt 12.1.0, Freetype 2.14.1, GIF 5.2.2, Imath 3.2.2, JXL 0.11.1, Libheif 1.20.2, libjpeg-turbo 3.1.2, LibRaw 0.21.4, libuhdr NONE, OpenColorIO 2.5.0, OpenEXR 3.4.4, openjph 0.25.3, OpenVDB NONE, PNG 1.6.51, pugixml 1.15, pybind11 3.0.1, Python3 3.14.0, Robinmap 1.4.0, TBB 2022.3.0, TIFF 4.7.1, WebP 1.6.0, ZLIB 1.3.1

To Reproduce

WRONG OUTPUT:
oiiotool --debug -v --info -i /tmp/imagery_dnxhd36.mov --subimage 1 -o /tmp/oiio_png_from_imagery_dnxhd36.png

Which matches

ffmpeg -v debug -i /tmp/imagery_dnxhd36.mov -vframes 1 -pix_fmt rgb24 -y /tmp/ffmpeg_implicit_png_from_imagery_dnxhd36.png

CORRECT OUTPUT (with explicit color scaling operations):
ffmpeg -v debug -i /tmp/imagery_dnxhd36.mov -vf "colorspace=all=bt709:range=pc:iall=bt709:irange=tv" -vframes 1 -pix_fmt rgb24 -y /tmp/ffmpeg_explicit_png_from_imagery_dnxhd36.png

Attaching sample legal range DNxHD 36 (exported out of Resolve)
https://github.com/user-attachments/assets/81027a1a-6bcc-454b-b66a-6ff6ae0f26a2

[zachlewis]

Ah ha... so, the problem is, OpenImageIO isn't scaling narrow range video levels to full range as expected.

I think it's reasonable to expect OIIO readers that support CICP to automatically convert to full range when CICPRange == 0 (when the video full range flag is off); and maybe a global attribute for disabling that behavior? I believe Nuke Read nodes have a similar "Convert Video Range to Full Range" toggle that's enabled by default.

[lgritz]

Yes, OIIO convention is that on the app-side of the API, only 8-, 16- and 32-bit data types are supported, and for unsigned integer types, always assuming the full range represents the 0-1 scale. Any "in between" bit depths read from a file are rounded up to the next bigger type and scaled to take up the full range. For example, a TIFF file with 12 bits per sample data (0-4095) looks like a 16 bit TIFF file (0-65535), but an extra metadata hint "oiio:BitsPerSample" is set to 12 as a hint that this is how it was stored in the file. That same hint, upon output, is taken as a request to please try to write with that bit depth (with automatic range rescaling) if the output format supports such a thing.

[groucho86]

To be clear, this is not a "ffmpeg is misinterpreting the source as full range". The mismatch isn't that drastic.

According to claude.ai (apologies...), the issue is swscale is combining the scaling+matrix operation "in one integer math pass", compounding the errors. By separating the two operations, it reduces the accumulated errors.

Claude.ai offered a minimal patch for ffmpeginput.cpp but I don't know C++ and don't want to pollute this great library with potential AI-slop. Happy to copy-paste the suggestion here though.