Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > VapourSynth

Reply
 
Thread Tools Search this Thread Display Modes
Old 18th December 2016, 19:07   #201  |  Link
adsun701
Registered User
 
Join Date: Dec 2016
Posts: 6
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.

Code:
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?
adsun701 is offline   Reply With Quote
Old 21st February 2017, 08:44   #202  |  Link
m3sh
Registered User
 
Join Date: Apr 2012
Location: Edmonton
Posts: 9
HLG transfer function support

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.
m3sh is offline   Reply With Quote
Old 21st February 2017, 09:35   #203  |  Link
Cary Knoop
Cary Knoop
 
Cary Knoop's Avatar
 
Join Date: Feb 2017
Location: Newark CA, USA
Posts: 397
Quote:
Originally Posted by m3sh View Post
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.

Last edited by Cary Knoop; 21st February 2017 at 09:47.
Cary Knoop is offline   Reply With Quote
Old 21st February 2017, 10:44   #204  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
Quote:
Originally Posted by m3sh View Post
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...
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is offline   Reply With Quote
Old 21st February 2017, 22:57   #205  |  Link
m3sh
Registered User
 
Join Date: Apr 2012
Location: Edmonton
Posts: 9
Quote:
Originally Posted by Myrsloik View Post
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.
m3sh is offline   Reply With Quote
Old 21st February 2017, 22:59   #206  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
It wasn't implemented back then
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is offline   Reply With Quote
Old 21st February 2017, 23:18   #207  |  Link
m3sh
Registered User
 
Join Date: Apr 2012
Location: Edmonton
Posts: 9
Of course... I am a sad (and lazy) panda. Thanks, I'll get 36 installed and try again.
m3sh is offline   Reply With Quote
Old 27th February 2017, 23:59   #208  |  Link
Cary Knoop
Cary Knoop
 
Cary Knoop's Avatar
 
Join Date: Feb 2017
Location: Newark CA, USA
Posts: 397
Quote:
Originally Posted by adsun701 View Post
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.

Code:
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.
Cary Knoop is offline   Reply With Quote
Old 3rd March 2017, 02:17   #209  |  Link
adsun701
Registered User
 
Join Date: Dec 2016
Posts: 6
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 is offline   Reply With Quote
Old 17th March 2017, 20:21   #210  |  Link
adsun701
Registered User
 
Join Date: Dec 2016
Posts: 6
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!
adsun701 is offline   Reply With Quote
Old 17th March 2017, 23:21   #211  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,100
The VS builtin resizer (zimg) has support for ICtCp being worked on 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

Last edited by TheFluff; 17th March 2017 at 23:31.
TheFluff is offline   Reply With Quote
Old 18th March 2017, 09:18   #212  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
Quote:
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 )
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 18th March 2017, 14:31   #213  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,100
Quote:
Originally Posted by Selur View Post
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).

Quote:
Originally Posted by Selur View Post
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.
TheFluff is offline   Reply With Quote
Old 18th March 2017, 16:28   #214  |  Link
WolframRhodium
Registered User
 
Join Date: Jan 2016
Posts: 162
Quote:
Originally Posted by TheFluff View Post
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?
WolframRhodium is offline   Reply With Quote
Old 18th March 2017, 16:37   #215  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,100
Quote:
Originally Posted by WolframRhodium View Post
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.
TheFluff is offline   Reply With Quote
Old 18th March 2017, 16:44   #216  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
Quote:
Originally Posted by TheFluff View Post
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.

Last edited by feisty2; 18th March 2017 at 16:47.
feisty2 is offline   Reply With Quote
Old 18th March 2017, 16:49   #217  |  Link
WolframRhodium
Registered User
 
Join Date: Jan 2016
Posts: 162
Quote:
Originally Posted by TheFluff View Post
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.

Last edited by WolframRhodium; 18th March 2017 at 16:52.
WolframRhodium is offline   Reply With Quote
Old 18th March 2017, 16:58   #218  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,100
Quote:
Originally Posted by feisty2 View Post
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.
TheFluff is offline   Reply With Quote
Old 18th March 2017, 17:07   #219  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
Quote:
Originally Posted by TheFluff View Post
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.
feisty2 is offline   Reply With Quote
Old 18th March 2017, 17:31   #220  |  Link
WolframRhodium
Registered User
 
Join Date: Jan 2016
Posts: 162
Quote:
Originally Posted by TheFluff View Post
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?
WolframRhodium is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 16:11.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.