fmtconv: resize, bitdepth and colorspace conversions

[MonoS]

I do tonemap that way
den = core.resize.Bicubic(clip=den, format=vs.RGBS, filter_param_a=0.0, filter_param_b=0.75, range_in_s="limited", matrix_in_s="2020ncl", primaries_in_s="2020", primaries_s="2020", transfer_in_s="st2084", transfer_s="linear",dither_type="none", nominal_luminance=mcll)
den = core.tonemap.Mobius(clip=den, exposure=exposure, transition=0.3, peak=mcll)
den = core.fmtc.resample(den, resw, resh, kernel="bilinear", invks=True, invkstaps=3, taps=4)
den = core.resize.Bicubic(clip=den, format=vs.YUV444PS, filter_param_a=0.0, filter_param_b=0.75, matrix_s="709", primaries_in_s="2020", primaries_s="709", transfer_in_s="linear", transfer_s="709")
res = core.fmtc.resample(den, resw, resh, invks=True, kernel="bicubic", invkstaps=3, css="420").fmtc.bitdepth(bits=8, dmode=3, flt=False)

the parameters you need to pass are resw and resh for the final resolution, mcll for the mcll parameter of your stream, you can get it with mediainfo, and exposure you need to set as you like it, i suggest you to compare with the SDR bluray, as the tonemap filter i use this one https://github.com/ifb/vapoursynth-tonemap

[asarian]

You may like this one as it is GPU accelerated. Apply it after resizing on the GPU (if needed) for maximum performance.

This looks like just what the doctor ordered! :) Unfortunately, the pertinent thread points to an invalid rar: https://forum.doom9.org/showthread.php?t=175624


EDIT: Nevermind: found a newer version in the directory itself. :)

[videoh]

Latest version is always linked on my web page:

http://rationalqm.us/mine.html

[ChaosKing]

@videoh could you make a vapoursynth section on your webpage too? Or mark filters with native vapoursynth support somehow?

[videoh]

OK, will do. Thanks for the suggestion.

[asarian]

OK, will do. Thanks for the suggestion.

And, while we're at it, could you please also make DGDenoise native to vapoursynth? (so that DGDecodeNV.dll doesn't need to be loaded as legacy avs filter any more for it, with LoadPlugin).

[videoh]

And, while we're at it, could you please also make DGDenoise native to vapoursynth? (so that DGDecodeNV.dll doesn't need to be loaded as legacy avs filter any more for it, with LoadPlugin). The problem for me is that implementing both native Avisynth and native Vapoursynth versions creates a lot of code duplication and extra maintenance. I have not found a solution to this. Myrsloik has stated, and testing bears out, that there is no performance penalty for using the avscompat mechanism. So unless a compelling argument is advanced, I'll prefer to just make one version. If Avisynth could import Vapoursynth filters then I would reverse things. :)

I had already implemented native Vapoursynth for DGSource() before I settled on this policy.

[asarian]

The problem for me is that implementing both native Avisynth and native Vapoursynth versions creates a lot of code duplication and extra maintenance. I have not found a solution to this. Myrsloik has stated, and testing bears out, that there is no performance penalty for using the avscompat mechanism. So unless a compelling argument is advanced, I'll prefer to just make one version. If Avisynth could import Vapoursynth filters then I would reverse things. :)

I had already implemented native Vapoursynth for DGSource() before I settled on this policy.

Okay, thx. That sounds entirely reasonable. :) I tried it out last night on a re-encode, and was worried that maybe the avs route would be less stable somehow, but turned out to be rocksolid after all.

[asarian]

^^ P.S. I'm continually amazed at how fast the GPU stuff is. Naturally, my GTX 1080 Ti is a beast, but especially the GPU load (measured by GPU-Z) is extremely low: along with OpenCL support for x264, the gpu-assisted resize, and DGDenoise, the entire GPU load only dips into a few percent, every now then. nVidea, ftw! :)

[videoh]

^^ P.S. I'm continually amazed at how fast the GPU stuff is. Yes, it clearly outperforms CPU implementations and if you can eliminate unnecessary CPU<->GPU transfers (think CUDASynth) it blows CPU away into the next galaxy.

Naturally, my GTX 1080 Ti is a beast, but especially the GPU load (measured by GPU-Z) is extremely low: along with OpenCL support for x264, the gpu-assisted resize, and DGDenoise, the entire GPU load only dips into a few percent, every now then. nVidea, ftw! :) Who can argue with that? I like to remind people to look at the CPU utilization too, because savings can be applied to CPU things, especially encoding.

[asarian]

I like to remind people to look at the CPU utilization too, because savings can be applied to CPU things, especially encoding.

Consider my following script:

import vapoursynth as vs

core = vs.get_core ()
core.max_cache_size = 8192

core.avs.LoadPlugin ("C:/Program Files (x86)/dgdecnv/x64 Binaries/DGDecodeNV.dll")

vid = core.avs.DGSource (r'i:\jobs\inter.dgi', resize_w=1920, resize_h=1080, fulldepth=True)
vid = core.dghdrtosdr.DGHDRtoSDR (clip=vid, fulldepth=False)
vid = core.avs.DGDenoise (vid, strength=0.12, searchw=9)

vid.set_output ()



The typical CPU-utilization for a job like this is 99% CPU (for the x264 process), and about 0.3% for vspipe (YAY GPU!)

On a non-GPU accelerated jon, CPU saturation for the vspipe process is around 50% (with haf.QTGMC). So, yeah, whatever can be done in GPU, I'll take it! :)

[videoh]

So, yeah, whatever can be done in GPU, I'll take it! :) Have a look at DGBob() and PVBob() instead of QTGMC for deinterlacing if you are after blazing speed. Decomb is also implemented for GPU (DGTelecide and DGDecimate).

Maybe getting OT for this thread.

[asarian]

You may like this one as it is GPU accelerated. Apply it after resizing on the GPU (if needed) for maximum performance.

I'm loving it! :)

I noticed, however, that sometimes DGHDRtoSDR still leaves things too washed out, as it were. See: https://1drv.ms/u/s!AhSxhQ9g_mrMlEJQ6vC4Z8ExAKlg

Those are stills from the movie Divergent. The overlapped image (on the right, with the black bars) is from the original blu-ray; the underlying, big image is what DGHDRtoSDR produced (with default values).

In Photoshop, I needed +48 contrast to have it look kinda like the blu-ray. Sadly, I found no contrast parameter for DGHDRtoSDR (brightness didn't seem to affect much of anything). Is there a way to achieve this?

Thanks.

EDIT: 'what DGHDRtoSDR produced' from the UHD source, of course. :)

[videoh]

Sadly, I found no contrast parameter for DGHDRtoSDR (brightness didn't seem to affect much of anything). Is there a way to achieve this? Use Tweak() in your Avisynth script.

[asarian]

Use Tweak() in your Avisynth script.

Thanks. I see it's part of havsfunc itself. :)

[RainyDog]

Is it possible to use fmtconv to resize and crop together?

For example, in avisynth you can the below script when the exact crop is a row of 21 black pixels at both the top and bottom to avoid either overcropping or undercropping by 2 pixels.

Spline36Resize(1920, 1038, 0, 21, -0, -21)

Thanks.

[sneaker_ger]

See documentation about "resample" "sx", "sy", "sw", "sh" parameters.

sx, sy

Coordinate of the top-left corner of the picture sub-area used as source for the resizing. They can be fractional. If negative, the picture is extended by replicating the left pixel column.

These parameters are arrays, so it’s possible to specify a different value for each plane. The last value is used for the unspecified planes. The coordinates are always related to the pixel dimensions, you don’t need to scale them with the chroma subsampling.

sw, sh

Size in pixels of the sub-area to resize. They can be fractional. If 0, the area has the same size as the source clip. If negative, they define coordinates relative to the bottom-right corner, in a Crop-like manner. These parameters are arrays like sx and sy.

[zorr]

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'm using the FATPACK version but fmtconv.dll is dated March 2016 and has the exact same date as the official version. Is the more recent (and hopefully less buggy (https://forum.doom9.org/showthread.php?p=1866388#post1866388)) version still available somewhere?

[asarian]

I'm using the FATPACK version but fmtconv.dll is dated March 2016 and has the exact same date as the official version. Is the more recent (and hopefully less buggy (https://forum.doom9.org/showthread.php?p=1866388#post1866388)) version still available somewhere?

I'm using the one Wolfberry linked to (his own version), but the link doesn't seem valid any more. Sad, because that one is very stable.

[zorr]

I'm using the one Wolfberry linked to (his own version), but the link doesn't seem valid any more. Sad, because that one is very stable.

Could you share the file? It could be included in the next FATPACK.

[asarian]

Could you share the file? It could be included in the next FATPACK.

Here it is: fmtconv.dll (https://1drv.ms/u/s!AhSxhQ9g_mrMlgeOR7S66IbtuWOw)

It's for 64-bit, btw.

[poisondeathray]

wolfberry has 3 public shared fmtconv versions, which one are you linking to? or is it a different one ?
https://drive.google.com/drive/folders/1xZQABtoaSFgGu11YstmHKYLzO3elemlC

[asarian]

wolfberry has 3 public shared fmtconv versions, which one are you linking to? or is it a different one ?
https://drive.google.com/drive/folders/1xZQABtoaSFgGu11YstmHKYLzO3elemlC

If I recall correctly, he had a separate vapoursynth directory there (which I couldn't find any more earlier either). The fmtconv version I took was dated 8 Dec 2018 (which I don't see any more either). Said directory had things like a new libdfttest too.

[wonkey_monkey]

A warning, as people still seem to be posting directly to threads and may not be aware:

It appears that the forum may have been hacked. There is a suspicious "test" announcement, apparently from tebasuna51 (but probably not), parts of the forum are not working, and there appear to be some malicious javascript files.

I'm not speaking in any official capacity here, but I would recommend, at the very least, NOT entering your password anywhere on Doom9 for the time being.

Please refer to this post: https://forum.doom9.org/showthread.php?goto=newpost&t=176128

[asarian]

A warning, as people still seem to be posting directly to threads and may not be aware:

It appears that the forum may have been hacked. There is a suspicious "test" announcement, apparently from tebasuna51 (but probably not), parts of the forum are not working, and there appear to be some malicious javascript files.

I'm not speaking in any official capacity here, but I would recommend, at the very least, NOT entering your password anywhere on Doom9 for the time being.

Please refer to this post: https://forum.doom9.org/showthread.php?goto=newpost&t=176128


The guy that did speak in an official capacity ('Swede'), is he legit?! He has locked his announcement, so I can't react, but suggests ppl change their password... which would be an ideal hack (as you need to enter your old password on the form there too) if it's illegit.

[videoh]

Swede is legit.

[asarian]

Swede is legit.

Puts my mind at ease. :) Thanks.

[groucho86]

Hi everyone,
Just opened up an issue on fmtconv's github (https://github.com/EleonoreMizo/fmtconv/issues/12), 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.

import vapoursynth as vs
import muvsfunc
core = vs.get_core()

input_path = 'source_sgamut

c = core.imwri.Read(input_path,float_output=True)
c = core.fmtc.transfer (clip=c, transs='linear', transd='slog3')
c.set_output()

Test material is here:
https://github.com/EleonoreMizo/fmtconv/files/3691493/linear_to_slog3_tb.zip

Includes:
source_sgamut3cine_linear.exr <-- source file
resolve_delinearized.tif <-- expected result
vs_delinearized.png <-- fmtconv result

[age]

Yes it looks so

import vapoursynth as vs
import muvsfunc
core = vs.get_core()

input_path = 'source_sgamut

c = core.imwri.Read(input_path,float_output=True)
#c = core.std.Expr(clips=[c], expr=" x 0.9 *")
c = core.std.Expr(clips=[c], expr=" x 0.01125000 >= x 0.01 + 0.19 / log 10 log / 261.5 * 420 + 1023 / 171.2102946929 95 - x * 0.01125000 95 + / 1023 / ?")
c.set_output()


Not sure if the resolve result is right either, maybe there is need to scaling from linear to reflection multiply by 0.9

https://github.com/videovillage/Lattice-Issues/issues/17

https://pro.sony/s3/cms-static-content/uploadfile/06/1237494271406.pdf

[groucho86]

Thanks age! Your expr matches well to the DCTL I am using in Resolve. The 0.9 does not seem relevant in this case.

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.

[Cary Knoop]

Hi everyone,
Just opened up an issue on fmtconv's github (https://github.com/EleonoreMizo/fmtconv/issues/12), 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 (https://github.com/EleonoreMizo/fmtconv/files/3691493/linear_to_slog3_tb.zip).

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]

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]

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 (http://forum.doom9.org/showthread.php?t=166504).
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]

I just fixed this issue. The clipping was caused by an inappropriate lookup table selection. There is a new release, check fmtconv r21 (http://forum.doom9.org/showthread.php?t=166504).

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? :thanks:

[Pat357]

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]

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]

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]

Fixed now.

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

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

[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 (http://forum.doom9.org/showthread.php?t=166504):
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]

Here it is. fmtconv r22 (http://forum.doom9.org/showthread.php?t=166504)
Thank you!
Can I ask why spline64 and spline taps=4 doesn't produce the same result?

[cretindesalpes]

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 (https://forum.doom9.org/showthread.php?t=147117) for details), while the spline + taps are natural cubic splines, as implemented by Wilbert in SplineResize 0.2 (http://wilbertdijkhof.com/).

[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/fmtconv/files/3964030/fmtc.patch.txt , the building works ok, but I'm not sure my patch doesn't mess up anything.....

[cretindesalpes]

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. :D 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)