fmtconv: resize, bitdepth and colorspace conversions

[Cary Knoop]

Originally Posted by groucho86

Hi everyone,
Just opened up an issue on fmtconv's github, wondering if anyone had any insight here.

I have a SGamut3.Cine Linear EXR. It seems like the Linear to Slog3 conversion is clipping in the highlights.

What is the bitdepth of the EXR and it is a float representation?

[groucho86]

Hey Cary,
EXR is 16bit half float. Sample file is downloadable here.

exrheader inspection:

$ exrheader source_sgamut3cine_linear.exr 

file source_sgamut3cine_linear.exr:

file format version: 2, flags 0x0
channels (type chlist):
    B, 16-bit floating-point, sampling 1 1
    G, 16-bit floating-point, sampling 1 1
    R, 16-bit floating-point, sampling 1 1
compression (type compression): none
dataWindow (type box2i): (0 0) - (319 239)
displayWindow (type box2i): (0 0) - (319 239)
framesPerSecond (type rational): 24/1 (24)
lineOrder (type lineOrder): increasing y
pixelAspectRatio (type float): 1
screenWindowCenter (type v2f): (0 0)
screenWindowWidth (type float): 1
timeCode (type timecode):
    time 00:00:00:00
    drop frame 0, color frame 0, field/phase 0
    bgf0 0, bgf1 0, bgf2 0
    user data 0x0
type (type string): "scanlineimage"

[redbtn]

Is there any differences between fmtc Spline36 and internal Vapoursynth Spline36? If yes, what is better for HDR downscale? Thanks!

[Jukus]

Originally Posted by redbtn

better for HDR downscale

There is information on these pages:
http://www.vapoursynth.com/doc/functions/resize.html
http://avisynth.nl/index.php/Resize
But some say it is out of date.
I don’t know, I use bicubic with b=0,c=0.5.

[cretindesalpes]

Originally Posted by groucho86

Any idea why fmtconv would be clipping? I looked at TransOpSLog3.cpp and nothing's jumping out at me. Maybe I'm not looking in the right place.

I just fixed this issue. The clipping was caused by an inappropriate lookup table selection. There is a new release, check fmtconv r21.
Sorry for the trouble! It’s been years since I worked on fmtconv so it was a bit difficult to dive into the code again.

[redbtn]

Originally Posted by cretindesalpes

I just fixed this issue. The clipping was caused by an inappropriate lookup table selection. There is a new release, check fmtconv r21.

Sorry for the trouble! It’s been years since I worked on fmtconv so it was a bit difficult to dive into the code again.

Thank you for new release!
Glad to see you!

[ChaosKing]

Could you also make a release on github?

[Pat357]

Originally Posted by Wolfberry

If you are using the dll from the official release, I will recommend to use the one from ChaosKing's FATPACK or the one in my signature as it is compiled with a newer compiler and might save you from random crashes.

I checked the files in your signature but couldn't find the newly compiled fmtconv.dll.
Can you tell me the name of the file ?
Thank you !

[ChaosKing]

Just use the new r21 version posted by cretindesalpes.

[cretindesalpes]

Originally Posted by adsun701

I actually discovered a bug in the primaries conversion code. When converting to ciexyz primaries, there is a divide by zero error due to the coordinates of the primaries. Hopefully it gets fixed!

Fixed. Thanks for your report!

[cretindesalpes]

Originally Posted by J1Man

When "1886a" (alternative approximation of 1886) transfer function is used before and after primaries conversion, it creates heavy pink artifacts on bright areas of the video.

Fixed now.

[Pat357]

Originally Posted by cretindesalpes

Fixed now.

Any link to the "fixed" version ? (Windows binaries)

The link to r21 still has 8/12/2019 date-stamp

[cretindesalpes]

There is no new release yet, but there will be soon a r22 with all the fixes. In the meantime, it is possible to compile the source code from the git repository.

[cretindesalpes]

Here it is. fmtconv r22:

• bitdepth: upconversions for full range data now scale to the maximum value instead of shifting bits. Thanks to Z4ST1N for the report.
• matrix: added support for the YDzDx, ICtCp-PQ and ICtCp-HLG colorspaces.
• matrix: fixed a case issue for matrix identifiers.
• primaries: added support for P3-DCI, P3-D65 and P3-D60. The old DCI-P3 was actually P3-D65. The code "dcip3" remains for backward compatibility but is deprecated.
• primaries: added support for the EBU 3213-E colorspace.
• primaries: added a "2100" alias for the BT.2020/BT.2100 colorspace.
• primaries: fixed a divide-by-0 crash when using CIEXYZ as destination colorspace
• primaries: fixed a bug preventing to use the "uhdtv" string for BT.2020 primaries
• transfer: added support for hybrid log-gamma (HLG) curves.
• transfer: for the SMPTE SM 2084 curve, the specific value of 0 now gives a true 0 in both directions (minor change).
• transfer: BT.2020 curve for 12-bit data now uses exact values giving a continuous derivative (minor change).
• transfer: now uses more accurate constants for the sRGB curve, giving a better derivative continuity (minor change).
• transfer: fixed a bug with the alternate formula for BT.1886 curve.
• Should now build correctly on FreeBSD (patch by jbeich)
• Fixed compilation for Linux on ARM or aarch64. Binaries not tested yet.

[redbtn]

Originally Posted by cretindesalpes

Here it is. fmtconv r22

Thank you!
Can I ask why spline64 and spline taps=4 doesn't produce the same result?

[cretindesalpes]

Originally Posted by redbtn

Can I ask why spline64 and spline taps=4 doesn't produce the same result?

This is because the splineNN algorithms are hardcoded plain cubic splines (see here for details), while the spline + taps are natural cubic splines, as implemented by Wilbert in SplineResize 0.2.

[Pat357]

I have some problems building fmtconv for x64 using Mingw64.

Created an issue on your git : https://github.com/EleonoreMizo/fmtconv/issues/14

After applying the patch I attached at the issue https://github.com/EleonoreMizo/fmtc...fmtc.patch.txt , the building works ok, but I'm not sure my patch doesn't mess up anything.....

[cretindesalpes]

Originally Posted by Pat357

I have some problems building fmtconv for x64 using Mingw64.

Thank you, the patch was correct. I did several other modifications. Please check the git repository.

[dev-null]

One of the primary issues I run into, when building myself a VapourSynth setup for my outdated OS X system (10.10), was a broken/ non working build of "fmtconv".

I fetched the r22 release and build it with clang ("clang-700.1.81", as included in XCode 7.2, last available for Yosemite). It compiled w/o a hitch, just had the known linking problem with a missing libatomic (the GCC thingy). Removing the respective -latomic flag fixed that. But calling any "fmtc" stuff from a VapourSynth script made vspipe never return. It was busy looping a single thread @ ~100% CPU usage. A build of the older r21 release works fine. Also a build of r22 with gcc 9.2 works fine too (no -latomic linking problem this way either.) So there's some sort of change in r22 that makes older clang mess up the build.

Interestingly I can't build the current master version from git with old clang nor gcc 9.2. The compilation fails rather similarly on stuff in src/conc/Interlocked.hpp. Here's the gcc9.2 output: https://pastebin.com/3NWWBJKW . Sadly I can't wrap my brain around this C++ stuff, so I have no idea what it wants to do there and how I could fix it. Also interesting is that this Interlocked stuff seems to be the stuff where the broken r22 clang build has trouble with. That's according to a process sample taken with Activity Monitor: it seems to hang around some of those "OSAtomicCompareAndSwap" functions in the stack trace.

Just reporting. Maybe someone has run into the same issue and knows details why it happens exactly: compiler bug, fmtconv's code broken, etc.? Anyway… to make it short: if you got busy-looping issues with fmtc[onv] stuff on an outdated Mac OS X system, try a build of the lib with gcc-9.2!

[Cary Knoop]

Any idea why this fails on a ProRes4444 format? I presume it is the alpha channel.

c = core.ffms2.Source("prores4444.mov")
c = core.fmtc.bitdepth(c, bits=16)

Error:
c = core.fmtc.bitdepth(c, bits=16)
File "src\cython\vapoursynth.pyx", line 1862, in vapoursynth.Function.__call__
vapoursynth.Error: bitdepth: argument clip is not of array type but more than one value was supplied

Edited to add:

Found out the solution myself, if an alpha channel is present two clips will be returned.
This works fine:

c = core.ffms2.Source("prores4444.mov")
c = core.fmtc.bitdepth(c[0], bits=16)