fmtconv: resize, bitdepth and colorspace conversions

[adsun701]

Hi there,
When I was testing if fmtconv could make transforms from 709 content to ciexyz content, I may have encountered a possible bug.
I either get a segmentation fault or completely black output when converting 709 primaries to ciexyz primaries.

import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(path=r'/usr/local/lib/vapoursynth/libimwri.so')
clip = core.ffms2.Source(r'/home/andy/Sample.mkv')
clip = core.std.Trim(clip, 2300, 2300)
clip = core.fmtc.bitdepth(clip, bits=32, dmode=6)
clip = core.fmtc.matrix(clip, mats='709', matd='RGB', col_fam=vs.RGB, bits=32)
clip = core.fmtc.transfer(clip, transs='709', transd='linear', bits=32)
clip = core.fmtc.primaries(clip, prims='709', primd='ciexyz')
clip = core.fmtc.transfer(clip, transs='linear', transd='2084', cont=1000/10000, bits=32)
clip = core.imwrif.Write(clip, 'EXR', 'image%04d.exr', firstnum=0)
clip.set_output()

Is this a bug? If so, I would appreciate that it be fixed. If not, then what am I doing wrong?

[m3sh]

Any plans to add HLG transfer function support in an upcoming release? By my reading of the documentation, I can't see anything referencing ARIB-STD-B67 (Hybrid Log Gamma, HLG) EOTF.

Would love to have it, Technicolor guys gave me an asset in HLG and I'm hoping to use fmtconv to do the conversion to HDR10 to feed into my currently limited STB client - the broadcom chipset doesn't support HLG afaik.

[Cary Knoop]

Any plans to add HLG transfer function support in an upcoming release? By my reading of the documentation, I can't see anything referencing ARIB-STD-B67 (Hybrid Log Gamma, HLG) EOTF.

Would love to have it, Technicolor guys gave me an asset in HLG and I'm hoping to use fmtconv to do the conversion to HDR10 to feed into my currently limited STB client - the broadcom chipset doesn't support HLG afaik.
I wonder if this, as a workaround for now, can be achieved by using Lut2 function mode.

[Myrsloik]

Any plans to add HLG transfer function support in an upcoming release? By my reading of the documentation, I can't see anything referencing ARIB-STD-B67 (Hybrid Log Gamma, HLG) EOTF.

Would love to have it, Technicolor guys gave me an asset in HLG and I'm hoping to use fmtconv to do the conversion to HDR10 to feed into my currently limited STB client - the broadcom chipset doesn't support HLG afaik.

See the documentation for the internal VS resizer. It can actually do a lot of things...

[m3sh]

See the documentation for the internal VS resizer. It can actually do a lot of things...

Ahh yes... took a look at this though and while I'm still using R32 (and probably need to upgrade to VS R36) just want to be sure that upgrading will address the fact that R32 doesn't seem to like the "transfer_s" parameter...? Right now I can't get it working due to specifying the transfer output function as a string, seeing as I don't know the enumerated value for st2084.

[Myrsloik]

It wasn't implemented back then

[m3sh]

Of course... I am a sad (and lazy) panda. Thanks, I'll get 36 installed and try again.

[Cary Knoop]

Hi there,
When I was testing if fmtconv could make transforms from 709 content to ciexyz content, I may have encountered a possible bug.
I either get a segmentation fault or completely black output when converting 709 primaries to ciexyz primaries.

import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(path=r'/usr/local/lib/vapoursynth/libimwri.so')
clip = core.ffms2.Source(r'/home/andy/Sample.mkv')
clip = core.std.Trim(clip, 2300, 2300)
clip = core.fmtc.bitdepth(clip, bits=32, dmode=6)
clip = core.fmtc.matrix(clip, mats='709', matd='RGB', col_fam=vs.RGB, bits=32)
clip = core.fmtc.transfer(clip, transs='709', transd='linear', bits=32)
clip = core.fmtc.primaries(clip, prims='709', primd='ciexyz')
clip = core.fmtc.transfer(clip, transs='linear', transd='2084', cont=1000/10000, bits=32)
clip = core.imwrif.Write(clip, 'EXR', 'image%04d.exr', firstnum=0)
clip.set_output()

Is this a bug? If so, I would appreciate that it be fixed. If not, then what am I doing wrong?
It is my understanding you need to convert the clip to 4:4:4 first, I assume the mkv file is 4:2:0 but perhaps that assumption is wrong.

Also when I use the bits parameter in transfer() from '709' to 'linear' I get: matrix: output bitdepth not supported.

[adsun701]

Thanks for your help!

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!

[adsun701]

Also, could SMPTE ST 2085 matrix conversion and ICtCp matrix conversion be implemented? They are supported in the latest version of HEVC, and used for HDR content. SMPTE ST 2085 is used with CIEXYZ primaries, while ICtCp can be used with any primaries.

Thanks!

[TheFluff]

The VS builtin resizer (zimg (https://github.com/sekrit-twc/zimg)) has support for ICtCp being worked on (https://github.com/sekrit-twc/zimg/issues/69) as of right now. You should probably consider porting existing code to zimg as well; it's pretty much just flat out better than fmtconv, and it's in active development (unlike fmtconv which hasn't had any activity at all in the last year). It also has more contributors and users than fmtconv since it's a general-purpose C/C++ library and not tied to a filtering framework like VS or Avisynth. It's available in ffmpeg via libavfilter's vf_zscale, for example.

I don't think there are any features fmtconv has that the internal resizer (that is zimg) lacks, anymore. If there are, submit a feature request. http://www.vapoursynth.com/doc/functions/resize.html

[Selur]

I don't think there are any features fmtconv has that the internal resizer (that is zimg) lacks, anymore. If there are, submit a feature request. http://www.vapoursynth.com/doc/functions/resize.html
May be I'm just overlooked it, but I didn't find anything in the documentation about:

How to handle interlaced content? (In fmtconv there is interlaced&interlacedd. Do the resizers automatically handle and keep the interlacing state the source is in?)
Whether there are more resizers available than Bilinear/Bicubic/Point/Lanczos/Spline16/Spline36 through zimg? (fmtconv has point/box/bilinear/cubic/bicubic/lanczos/blackman/blackmanminlobe/spline16/spline36/spline64/spline/gauss/sinc )

[TheFluff]

How to handle interlaced content? (In fmtconv there is interlaced&interlacedd. Do the resizers automatically handle and keep the interlacing state the source is in?)

It's handled automatically, yes, assuming that the _Field or _FieldBased frame props are set correctly. Unlike Avisynth, VS (and zimg) understands that an interlaced clip that you call separatefields() on does not magically become progressive, so if you feed a field-separated clip to the internal resizer, resize it horizontally and then weave it again it'll still be handled correctly (there won't be any jumping up and down).

Whether there are more resizers available than Bilinear/Bicubic/Point/Lanczos/Spline16/Spline36 through zimg? (fmtconv has point/box/bilinear/cubic/bicubic/lanczos/blackman/blackmanminlobe/spline16/spline36/spline64/spline/gauss/sinc )
No. None of the extra ones are all that useful anyway.

[WolframRhodium]

It's handled automatically, yes, assuming that the _Field or _FieldBased frame props are set correctly. Unlike Avisynth, VS (and zimg) understands that an interlaced clip that you call separatefields() on does not magically become progressive, so if you feed a field-separated clip to the internal resizer, resize it horizontally and then weave it again it'll still be handled correctly (there won't be any jumping up and down).


No. None of the extra ones are all that useful anyway.

However, as an example, some people has been widely using gauss for years, and this phenomenon will continue. How can you come down to your conclusion?

[TheFluff]

However, as an example, some people has been widely using gauss for years, and this phenomenon will continue. How can you come down to your conclusion?

The Gauss resizer isn't even a resampler at all, mathematically speaking. As far as I can recall I don't think people really use it all that much for actually resizing things; they use it to blur things. Use something else for that.

Blackman is a bad windowed sinc; use lanczos instead.

[feisty2]

It's handled automatically, yes, assuming that the _Field or _FieldBased frame props are set correctly. Unlike Avisynth, VS (and zimg) understands that an interlaced clip that you call separatefields() on does not magically become progressive, so if you feed a field-separated clip to the internal resizer, resize it horizontally and then weave it again it'll still be handled correctly (there won't be any jumping up and down).


No. None of the extra ones are all that useful anyway.

gaussresize is more useful than you think, it could be used as a non-ringing convolution filter, and it's far more powerful than std.convolution, cuz:
a. it works with any radius (using the "taps" parameter)
b. it does not require you to manually calculate the coefficient matrix, you could simply control the filtering strength using the "p" parameter.

[WolframRhodium]

The Gauss resizer isn't even a resampler at all, mathematically speaking. As far as I can recall I don't think people really use it all that much for actually resizing things; they use it to blur things. Use something else for that.

Blackman is a bad windowed sinc; use lanczos instead.

The combination of lanczos and gauss in upsampling is popular. But zimg doesn't have gauss, that's a problem.

Another example is feisty2's Vine/Plum.

[TheFluff]

gaussresize is more useful than you think, it could be used as a non-ringing convolution filter, and it's far more powerful than std.convolution, cuz:
a. it works with any radius (using the "taps" parameter)
b. it does not require you to manually calculate the coefficient matrix, you could simply control the filtering strength using the "p" parameter.

Isn't that exactly what I said? Write an actual Gaussian convolution filter if that's what you want, instead of shoehorning it into a resampler-that-isn't.

[feisty2]

Isn't that exactly what I said? Write an actual Gaussian convolution filter if that's what you want, instead of shoehorning it into a resampler-that-isn't.

gaussresize is already highly optimized as a part of the resample function in fmtc, I could write a Gaussian filter any day of the week but I'm NOT a professional programmer, so that's gonna be a lot worse (performance-wise) than the existing gaussresize approach anyways, and I'm definitely not wasting my time just to mess with stupid things like that.

[WolframRhodium]

Isn't that exactly what I said? Write an actual Gaussian convolution filter if that's what you want, instead of shoehorning it into a resampler-that-isn't.

What's more, fmtconv contains various dithering mode and custom resample kernel, but what about zimg?

[TheFluff]

What's more, fmtconv contains various dithering mode and custom resample kernel, but what about zimg?

Dithering: Bayer pattern, random noise (magnitude 0.5) and Floyd-Steinberg are supported. Do you have any particularly convincing arguments as to why anything else is vastly superior? Having more options just for the sake of having more options is Avisynth mentality.

Custom convolution kernels: what is the actual practical use case for this? Is there any reason you can't just use a separate convolution filter?

I mean, yeah you can do a ton of interesting shit with a highly customizeable general-purpose FIR filter, but customization and flexibility is kinda hard to combine with ease of use, optimization and maintainability. If you want a filter that can do anything, it probably won't be very well suited to being a fast and reliable image resizer for real world inputs. The reason I'm trying to convince people to switch to zimg is that for 95% of the most common use cases it does what fmtconv does but is faster and easier to use. I know I told you to submit feature requests, but please keep them within the scope of what is reasonable to have in standard image resizer. For exotic stuff, write exotic filters.

[feisty2]

Having more (not significantly worse, like x86 is worse than x64, xp is wore than win10, so I never compiled x86 binaries or obsolete xp binaries for my plugins) options is always better, simply because people could ignore opinions they don't need, and anyone gets to choose what's useful to him/her (which is also why I love c++ and dislike java :))

[WolframRhodium]

Dithering: Bayer pattern, random noise (magnitude 0.5) and Floyd-Steinberg are supported. Do you have any particularly convincing arguments as to why anything else is vastly superior? Having more options just for the sake of having more options is Avisynth mentality.

Custom convolution kernels: what is the actual practical use case for this? Is there any reason you can't just use a separate convolution filter?

dithering: “Filter Lite”. See madvr's thread for why someone love it

kernel: https://forum.doom9.org/showthread.php?t=166080

[TheFluff]

Having more (not significantly worse, like x86 is worse than x64, xp is wore than win10, so I never compiled x86 binaries or obsolete xp binaries for my plugins) options is always better, simply because people could ignore opinions they don't need, and anyone gets to choose what's useful to him/her (which is also why I love c++ and dislike java :))

You're wrong, and very predictably so. You will probably understand this when you have more experience, and I'm probably telling you this completely in vain because I think it's hard to actually internalize this before you've actually experienced it. I was wrong in exactly the same way when I was younger and I don't think anyone could have convinced me to understand that, back then.

More code (and hence more combinations of possible code paths) isn't free, it's bought with the most expensive resource of all - developer attention. More code paths means more tests and more maintenance. More complex code with more paths through it becomes harder to reason about, understand and predict. With more code, it becomes harder to change your mind, refactor and redesign.

You and I - and all other programmers - are much dumber than we'd like to think we are. Things need to be kept simple in order for us to be able to reasonably keep working with them.

[TheFluff]

dithering: “Filter Lite”. See madvr's thread for why someone love it

kernel: https://forum.doom9.org/showthread.php?t=166080

I'm sure a lot of madvr users love a lot of things but I care exceedingly little about them. Adding more dithering options is a pain in the butt and has basically no visible effect on output bitdepths >= 8. I myself sure as heck can't see any meaningful difference between madvr's different error diffusion modes with 8-bit output, and I definitely can't say which one looks better. If you want dithering because you want things to look nice on your shitty 6-bit monitor, then perhaps you should in fact dither on playback instead of trying to encode it into your (probably lossily compressed) video? Especially when dither pattern preferences are so subjective. Filter lite is also supposed to be faster but zimg's Floyd-Steinberg implementation is already really optimized so who cares.

Custom kernels is in a similar spot. Yes you can get marginally improved results in some ways on certain (mostly small) images, but almost nobody uses it and there are tradeoffs with every kernel. If you care about this kind of custom tweaking a standard resizer probably isn't right for you.

If you want fmtconv for its customizeability, you can keep using it! It's fine! It's just that for the vast majority of common use cases (like most of the ones posted in this thread) zimg does the same thing faster and with a bit less effort. That's all I'm saying.

[junh1024]

I'll just leave this here:

Functionality is an ASSET.
Code is a LIABILITY.

(tldr so having the LEAST code that does the MOST stuff is desireable)

[juhok]

Now on FreeBSD Ports! :) https://www.freshports.org/graphics/vapoursynth-fmtconv/

[MonoS]

What is the correct way to downscale in linear light (gamma corrected) an HDR stream?
I tried to come up with a script, but i'm not so confident it is correct as i already screwed up multiple times in this regards :D

[fadedmaple]

Hi,I find a problem.When i use fmtc like this ,it will tell me "transfer: unsupported color family."

src16 = core.fmtc.bitdepth(src,bits=16)
UV = core.fmtc.resample(src16,1920, 1080, kernel="Spline36")
gray = core.std.ShufflePlanes(src16, 0, colorfamily=vs.YUV)
gray = core.fmtc.transfer(gray, transs="2020", transd="linear")
gray = core.fmtc.resample(gray, 1920, 1080, kernel="Spline36")
gray = core.fmtc.transfer(gray, transs="linear",transd="2020")
src = core.std.ShufflePlanes([gray,UV], [0,1,2],vs.YUV)


It works only when the colorfamily specified it with GARY 。
I am a noob in this , can explain why?THX

gray = core.std.ShufflePlanes(src16, 0, colorfamily=vs.GRAY)

[sneaker_ger]

See fmtconv doc.
As input, the function accepts only RGB and grayscale colorspaces.

[fadedmaple]

See fmtconv doc.

Thanks for you repley.
Maybe my expression is wrong,What is the difference between Y plane and GRAY?

[asarian]

Speaking of resizing, if I want to downsize an UHD Blu-ray, would this be the best way to go about it?

core.std.LoadPlugin("DGDecodeNV.dll")
video = core.dgdecodenv.DGSource("i:/jobs/test.dgi", fulldepth=False)
vid = core.fmtc.resample (clip=vid, w=1920, h=1080)

Or does core.fmtc.resample need a special parameter, optimized for reduction?

[Wolfberry]

The default kernel of fmtconv is bicubic with b=c=1/3 a.k.a. "Mitchell-Netravali" which should be enough for normal use.

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.

Try muvsfunc's SSIM_downsample (https://github.com/WolframRhodium/muvsfunc/blob/master/muvsfunc.py#L3507) if you are not satisfied with the results of plain bicubic.

[asarian]

The default kernel of fmtconv is bicubic with b=c=1/3 a.k.a. "Mitchell-Netravali" which should be enough for normal use.

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.

Try muvsfunc's SSIM_downsample (https://github.com/WolframRhodium/muvsfunc/blob/master/muvsfunc.py#L3507) if you are not satisfied with the results of plain bicubic.


Cool. Thx. :)

[asarian]

The default kernel of fmtconv is bicubic with b=c=1/3 a.k.a. "Mitchell-Netravali" which should be enough for normal use.

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.



Seems my fmtconv.dll is dated March 2016. So, thx for the new binary. :) N.B. Is it safe to replace all my old binaries (.dll's) with yours? (For VS R45).

[asarian]

Hmm, someone please explain this to me. I'm using:

import muvsfunc as muf
...
vid = muf.SSIM_downsample (clip=vid, w=1920, h=1080, use_fmtc=False)

It throws the following error, though:


encoded 1 frames, 12.82 fps, 238.61 kb/s
Error: fwrite() call failed when writing frame: 0, plane: 0, errno: 32
Output 9 frames in 2.06 seconds (4.38 fps)
Core freed but 24883200 bytes still allocated in framebuffers

[Wolfberry]

It should be safe if you want and can use my dlls (may require AVX2 and additional dependencies), if not, there are always official ones.
For you second question, errno 32 means broken pipe. Try using only source filters and see if the error persists. (Post your full script might help as well)

[asarian]

It should be safe if you want and can use my dlls (may require AVX2 and additional dependencies), if not, there are always official ones.
For you second question, errno 32 means broken pipe. Try using only source filters and see if the error persists. (Post your full script might help as well)


Pretty much happens with just this single input line:

vid = muf.SSIM_downsample (clip=vid, w=1920, h=1080, use_fmtc=False)


Couldn't really tell whether it's "clip=vid" or just "vid", or that w and h are to be set with an appended '=x' or that they are just the values. But I tried all combinations, to no avail.

Also, I didn't see any dependency missing. Putting 'import muvsfunc as muf' should suffice, right?

[asarian]

Ok, can anyone show me a script snippet of a working muf.SSIM_downsample then, please? Really love to try out this new and smooth reduction method. Thx.

[poisondeathray]

Ok, can anyone show me a script snippet of a working muf.SSIM_downsample then, please? Really love to try out this new and smooth reduction method. Thx.

Did you get an error message ?

I got an error messge complaining that didn't have nnedi3_resample.py , so I needed to download it and put it into site-packages , then it worked


import muvsfunc as muvs
clip = whateversource
clip = muvs.SSIM_downsample(clip, w=1920, h=1080)
clip.set_output()


use_fmtc=False by default if you look at muvsfunc

[asarian]

Did you get an error message ?

No error messages; just the x264 process that reports a broken pipe on the first frame it processes:

encoded 1 frames, 12.82 fps, 238.61 kb/s
Error: fwrite() call failed when writing frame: 0, plane: 0, errno: 32
Output 9 frames in 2.06 seconds (4.38 fps)
Core freed but 24883200 bytes still allocated in framebuffers


I got an error messge complaining that didn't have nnedi3_resample.py , so I needed to download it and put it into site-packages , then it worked

I got nnedi3_resample.py in site-packages (and nnedi3_weights.bin in the plugins64 directory), as per usual.

use_fmtc=False by default if you look at muvsfunc


I saw that, yeah; but it was not caused the breakage. :)

[poisondeathray]

No error messages; just the x264 process that reports a broken pipe on the first frame it processes:

encoded 1 frames, 12.82 fps, 238.61 kb/s
Error: fwrite() call failed when writing frame: 0, plane: 0, errno: 32
Output 9 frames in 2.06 seconds (4.38 fps)
Core freed but 24883200 bytes still allocated in framebuffers





1) Did you convert it to the final pixel format in the script? eg. YUV420P8 if encoding 8bit 4:2:0 etc... YUV420P10 if 10bit 4:2:0 . Or whatever you're doing

2) Are you using correct matching vspipe with your vapoursynth version ?

Post commandline if neither of those is the cause

[asarian]

1) Did you convert it to the final pixel format in the script? eg. YUV420P8 if encoding 8bit 4:2:0 etc... YUV420P10 if 10bit 4:2:0 . Or whatever you're doing

I'm just trying to downsize it to a regular Blu-ray format, 8-bit, compressed with x264.

I use dgdecodenv, which, if I understood it correctly, will output the UHD input as 8-bit YV12 by default.

2) Are you using correct matching vspipe with your vapoursynth version ?

Yes, matching vspipe is being used. The whole new setup works flawlessly (already done 2 discs with it), but it's just this SSIM_downsample that won't budge for me.

[poisondeathray]

You have to convert it back to the final pixel format. That filter converts up to float

[asarian]

You have to convert it back to the final pixel format. That filter converts up to float

Ah, that would explain it. :) Thx! :goodpost:

[asarian]

1) Did you convert it to the final pixel format in the script? eg. YUV420P8 if encoding 8bit 4:2:0 etc... YUV420P10 if 10bit 4:2:0 . Or whatever you're doing


Bloody h*ell! Looks like I got the colorspace messed up, after all: flaccid colors (https://1drv.ms/u/s!AhSxhQ9g_mrMlBx7PAVJJhq8lNRd)

The bottom image is the result of extracting the HEVC stream with TsMuxer (as eac3to can't extract to .mkv for HEVC yet), so prior to me re-encoding it. The colors are all flaccid, and not vibrant at all. :(

Is there any way I could change the header of the encoded file somehow, and set a different colorspace? Or am I too late already?

And perhaps more importantly, as TsMuxer apparently screws up the stream, and eac3to can't do it, what is the best way to extract the HEVC stream properly? (to feed to the VS input filters).

[asarian]

^^ Ok, I did some comparison:

stream comparison (https://1drv.ms/u/s!AhSxhQ9g_mrMlB5wxbZgx_9ewbV3)

The pane on the right is from the resultant tsMuxer stream, the one of the right of the original Blu-ray m2ts. Far as I can see, they're identical! No bit-depth is lost, no colorspace conversion took place, etc. Yet playing/encoding the stream muxed by tsMuxer yields all these flaccid colors. :(

[asarian]

Hmm, after the initial shock, I think the UHD 'Oblivion' disc is simply encoded with flatter colors. :) (Which is possible, of course) I can't see another reason. I got 2 other UHD discs so far (I intend to make Pan @ Scan HD versions, from UHD, for some of my fave movies), and they look about the same, color-wise (demuxed) as their original. So, no weirdness was going on, after all. Maybe I should get my money back on the Oblivion UHD. :) (Or make the colors a bit more vibrant myself).

[poisondeathray]

Hmm, after the initial shock, I think the UHD 'Oblivion' disc is simply encoded with flatter colors. :) (Which is possible, of course) I can't see another reason. I got 2 other UHD discs so far (I intend to make Pan @ Scan HD versions, from UHD, for some of my fave movies), and they look about the same, color-wise (demuxed) as their original. So, no weirdness was going on, after all. Maybe I should get my money back on the Oblivion UHD. :) (Or make the colors a bit more vibrant myself).

You probably have to tonemap it . It's HDR10 release, correct?


https://www.blu-ray.com/movies/Oblivion-4K-Blu-ray/156371/


HDR: HDR10
Universal's 2160p, HDR-enabled presentation...


One option is DGHDRtoSDR , another is vapoursynth tonemap

[videoh]

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