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 17th June 2015, 07:36   #181  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
Quote:
Originally Posted by jackoneill View Post
Convert your float clips to integer.
not doing that unless we got int32 or things even more delicate
and int16 is the most precise int type we got in vaporsynth for now, so, no.
feisty2 is offline   Reply With Quote
Old 17th June 2015, 07:46   #182  |  Link
Bloax
The speed of stupid
 
Bloax's Avatar
 
Join Date: Sep 2011
Posts: 317
What kind of sick and twisted things are you doing that require 4294967296 states of precision over 65536 states of precision on monitors that have all of 256 states of precision?
Bloax is offline   Reply With Quote
Old 17th June 2015, 07:51   #183  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
Quote:
Originally Posted by Bloax View Post
What kind of sick and twisted things are you doing that require 4294967296 states of precision over 65536 states of precision on monitors that have all of 256 states of precision?
color grading, int16 fails in some extreme cases, gotta take float32/int32 to prevent that
feisty2 is offline   Reply With Quote
Old 17th June 2015, 07:58   #184  |  Link
Bloax
The speed of stupid
 
Bloax's Avatar
 
Join Date: Sep 2011
Posts: 317
MVTools is used for color grading? o_O
Bloax is offline   Reply With Quote
Old 17th June 2015, 08:01   #185  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
Quote:
Originally Posted by Bloax View Post
MVTools is used for color grading? o_O
no, but once you convert your clip to a lower precision, for whatever purpose, precision will be lost FOR GOOD!
feisty2 is offline   Reply With Quote
Old 17th June 2015, 08:08   #186  |  Link
Bloax
The speed of stupid
 
Bloax's Avatar
 
Join Date: Sep 2011
Posts: 317
Well then clearly do the MVTools stuff first in int16 and then convert it back to a more precise format afterwards.
This might be a bit awkward, but then again it's not like we even had more than 8 bits to fuck around with 3-4 years ago.
Bloax is offline   Reply With Quote
Old 17th June 2015, 08:14   #187  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
Quote:
Originally Posted by Bloax View Post
Well then clearly do the MVTools stuff first in int16 and then convert it back to a more precise format afterwards.
This might be a bit awkward, but then again it's not like we even had more than 8 bits to fuck around with 3-4 years ago.
not tested but I'm actually worried about precision lost in the "float32-int16-float32" process might lead to some unexpected disasters.
feisty2 is offline   Reply With Quote
Old 17th June 2015, 08:18   #188  |  Link
Bloax
The speed of stupid
 
Bloax's Avatar
 
Join Date: Sep 2011
Posts: 317
"Do it first" implies doing input->int16->mvtools->float32->etc, unless that can't be done either for arcane reasons.
Bloax is offline   Reply With Quote
Old 17th June 2015, 08:41   #189  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
maybe not related to mvtools, but the following shows errors introduced in the "float32-int16-float32" process will actually affect the final result even if it's just 8bits
Code:
import vapoursynth as vs
core = vs.get_core()
clp = whatever
clp = core.std.ShufflePlanes(clp, planes=0, colorfamily=vs.GRAY)
clp = core.fmtc.bitdepth(clp, fulls=False, fulld=True, bits=32, flt=True, dmode=1)
clp = core.fmtc.transfer(clp, transs="470bg", transd="linear", fulls=True, fulld=True)
clp1 = core.fmtc.bitdepth(clp, fulls=True, fulld=True, bits=16, flt=False, dmode=1).fmtc.transfer(transs="linear", transd="srgb", fulls=True, fulld=True).fmtc.bitdepth(fulls=True, fulld=True, bits=8, flt=False, dmode=3)
clp2 = core.fmtc.transfer(clp, transs="linear", transd="srgb", fulls=True, fulld=True).fmtc.bitdepth(fulls=True, fulld=True, bits=8, flt=False, dmode=3)
dif = core.std.MakeDiff(clp1,clp2).std.Expr ("x 128 - 100 * 128 +")
dif.set_output ()
feisty2 is offline   Reply With Quote
Old 17th June 2015, 12:08   #190  |  Link
Nevilne
Registered User
 
Join Date: Aug 2010
Posts: 134
Not sure if you understand just how much precision 16bit int has, but you can just add [diff of float32->int16 and float32->int16->mvtools] to [float32], to keep non-mvtooled float32 pixels.
Nevilne is offline   Reply With Quote
Old 17th June 2015, 12:20   #191  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
Quote:
Originally Posted by Nevilne View Post
Not sure if you understand just how much precision 16bit int has, but you can just add [diff of float32->int16 and float32->int16->mvtools] to [float32], to keep non-mvtooled float32 pixels.
I'm reading CPP tutorials actually, gonna face this son of a gun sooner or later, so why not now
edit: new colorspaces could be defined by filters according to vs doc, so I'm thinking about double or int64 if I'm gonna write filters in cpp

Last edited by feisty2; 17th June 2015 at 12:29.
feisty2 is offline   Reply With Quote
Old 17th June 2015, 13:09   #192  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
Quote:
Originally Posted by feisty2 View Post
I'm reading CPP tutorials actually, gonna face this son of a gun sooner or later, so why not now
edit: new colorspaces could be defined by filters according to vs doc, so I'm thinking about double or int64 if I'm gonna write filters in cpp
Not supported because both are pointless. If floats aren't accurate enough for you then you're much more likely to be using an algorithm not suitable for the task than actually miss the few extra bits a double gives you.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is offline   Reply With Quote
Old 17th June 2015, 14:00   #193  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
Quote:
Originally Posted by Myrsloik View Post
Not supported because both are pointless. If floats aren't accurate enough for you then you're much more likely to be using an algorithm not suitable for the task than actually miss the few extra bits a double gives you.
okay then, no double or long long, it's just, I was screwed over by rounding errors some time before, and got allergic to it ever since

Last edited by feisty2; 17th June 2015 at 20:13.
feisty2 is offline   Reply With Quote
Old 17th June 2015, 14:37   #194  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Quote:
Originally Posted by Nevilne View Post
Not sure if you understand just how much precision 16bit int has, but you can just add [diff of float32->int16 and float32->int16->mvtools] to [float32], to keep non-mvtooled float32 pixels.
Tacking old LSB on top of filtered pixels is roughly equivalent to AddGrain(). Don't do that unless you just need a little randomness, in which case AddGrain will do you better.

Floating point is about working with WTW and BTB, not precision, and you'll generally want to grade it before you filter it so that you don't run into anomalies in areas you can't see, and don't accidentally filter away your important details. If 12- to 16-bit is enough for Camera Raw, 16-bit is enough for video grading.
foxyshadis is offline   Reply With Quote
Old 17th June 2015, 14:39   #195  |  Link
cretindesalpes
͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿
 
cretindesalpes's Avatar
 
Join Date: Feb 2009
Location: No support in PM
Posts: 712
Quote:
Originally Posted by feisty2 View Post
maybe not related to mvtools, but the following shows errors introduced in the "float32-int16-float32" process will actually affect the final result even if it's just 8bits
Of course. The “errors” you see are differences between dithering patterns. Clips with extremely small differences will always exhibit these artefacts once dithered, especially with error-diffusion algorithms (*). The only way to accurately check errors is to upconvert the clip of the lowest bitdepth then subtract them and amplify the difference.

(*) For example in 1-D and 1 bit, a value of 0.500 will dither as 10101010… and a value of 0.501 will dither as 11010101… resulting in a 0+1-1+1-1+1-1+1… difference.
__________________
dither 1.28.1 for AviSynth | avstp 1.0.4 for AviSynth development | fmtconv r30 for Vapoursynth & Avs+ | trimx264opt segmented encoding

Last edited by cretindesalpes; 17th June 2015 at 14:45.
cretindesalpes is offline   Reply With Quote
Old 17th June 2015, 15:35   #196  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
upconvert? as bitdepth upconvert or resolution upconvert?
Code:
import vapoursynth as vs
core = vs.get_core()
clp = whatever
clp = core.std.ShufflePlanes(clp, planes=0, colorfamily=vs.GRAY)
clp = core.fmtc.bitdepth(clp, fulls=False, fulld=True, bits=32, flt=True, dmode=1)
clp = core.fmtc.transfer(clp, transs="470bg", transd="linear", fulls=True, fulld=True)
clp1 = core.fmtc.bitdepth(clp, fulls=True, fulld=True, bits=16, flt=False, dmode=1).fmtc.transfer(transs="linear", transd="srgb", fulls=True, fulld=True).fmtc.bitdepth(fulls=True, fulld=True, bits=8, flt=False, dmode=3).fmtc.resample (clp.width*2,clp.height*2,fulls=True, fulld=True)
clp2 = core.fmtc.transfer(clp, transs="linear", transd="srgb", fulls=True, fulld=True).fmtc.bitdepth(fulls=True, fulld=True, bits=8, flt=False, dmode=3).fmtc.resample (clp.width*2,clp.height*2,fulls=True, fulld=True)
dif = core.std.MakeDiff(clp1,clp2).std.Expr ("x 32768 - 100 * 32768 +")
dif.set_output ()

import vapoursynth as vs
core = vs.get_core()
clp = whatever
clp = core.std.ShufflePlanes(clp, planes=0, colorfamily=vs.GRAY)
clp = core.fmtc.bitdepth(clp, fulls=False, fulld=True, bits=32, flt=True, dmode=1)
clp = core.fmtc.transfer(clp, transs="470bg", transd="linear", fulls=True, fulld=True)
clp1 = core.fmtc.bitdepth(clp, fulls=True, fulld=True, bits=16, flt=False, dmode=1).fmtc.transfer(transs="linear", transd="srgb", fulls=True, fulld=True).fmtc.bitdepth(fulls=True, fulld=True, bits=8, flt=False, dmode=3).fmtc.bitdepth(fulls=True, fulld=True, bits=32, flt=True, dmode=1)
clp2 = core.fmtc.transfer(clp, transs="linear", transd="srgb", fulls=True, fulld=True).fmtc.bitdepth(fulls=True, fulld=True, bits=8, flt=False, dmode=3).fmtc.bitdepth(fulls=True, fulld=True, bits=32, flt=True, dmode=1)
dif = core.std.MakeDiff(clp1,clp2).std.Expr ("x 0.5 - 100 * 0.5 +")
dif.set_output ()
anyways I tried both and differences are still there
feisty2 is offline   Reply With Quote
Old 17th June 2015, 17:06   #197  |  Link
cretindesalpes
͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿
 
cretindesalpes's Avatar
 
Join Date: Feb 2009
Location: No support in PM
Posts: 712
bitdepth upconvert. If you’re processing something in float, convert everything to float to compare.

Code:
clp = core.std.ShufflePlanes(clp, planes=0, colorfamily=vs.GRAY)
clp = core.fmtc.bitdepth(clp, fulls=False, fulld=True, bits=32, flt=True)
clp = core.fmtc.transfer(clp, transs="470bg", transd="linear", fulls=True, fulld=True)

clp1 = core.fmtc.bitdepth(clp, fulls=True, fulld=True, bits=16, flt=False, dmode=1)
clp1 = core.fmtc.transfer(clp1, transs="linear", transd="srgb", fulls=True, fulld=True)
clp1 = core.fmtc.bitdepth(clp1, fulls=True, fulld=True, bits=32, flt=True)

clp2 = core.fmtc.transfer(clp, transs="linear", transd="srgb", fulls=True, fulld=True)

dif = core.std.MakeDiff(clp1,clp2).std.Expr ("x 0.5 - 100 * 0.5 +")
dif = core.fmtc.bitdepth(dif, fulls=True, fulld=True, bits=8, flt=False)
dif.set_output ()
And the difference will be even tinier if you use dmode 3 instead of dmode 1.
__________________
dither 1.28.1 for AviSynth | avstp 1.0.4 for AviSynth development | fmtconv r30 for Vapoursynth & Avs+ | trimx264opt segmented encoding
cretindesalpes is offline   Reply With Quote
Old 17th June 2015, 17:07   #198  |  Link
Reel.Deel
Registered User
 
Join Date: Mar 2012
Location: Texas
Posts: 1,664
@feisty2
Not sure what's the obsession with 32-bit float but didn't you say your sources are usually 8-bit heavily compressed Katy Perry (or other pop) music videos? I highly doubt that processing in 32-bit float will magically make the output substantially better. I doubt the highly minute differences will be visible when playing in real-time. Also, do you have an appropriate 10-bit+ panel and workflow? If not then this discussion is moot.

I process my Canon DSLR raw photos in Lightroom (32-bit), output to 16-bit to do post processing in an external HDR software, I export to16-bit again and import into Lightroom for final grading. It would be nice to have a complete 32-bit float workflow but my current workflow is more than adequate to achieve very good results. I don't think 32-bit float will improve the results marginally.

*sorry for any grammar errors, not very efficient on my phone.
Reel.Deel is offline   Reply With Quote
Old 17th June 2015, 17:56   #199  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
1.Got that obsession from 3dsmax, I was playing with exposures of the objects and noticed 16bits actually produced some bandings when switching the exposure from an extreme to the opposite extreme, and float32 works fine without bandings
2.music videos, well, first, I like music videos, but more importantly, they are short so easy to test filters and demonstrate and they are lossily compressed so kinda like gets you easier to judge how filters work in extreme cases, but I do process other vids, mostly things I shot for fun
3.I got a color corrected monitor but it's not 10bpc, but like I said in 1., you don't really need 10bpc screen when you can already tell that shit happens and visible even at 8bpc screen
4.since we don't have infinite precision here to do all the intermediate steps, rounding errors will accumulate and might cause some serious shit, so gotta pick the data type closest to "infinite precision"
5.I think float32 would be better for linear light

Last edited by feisty2; 17th June 2015 at 18:07.
feisty2 is offline   Reply With Quote
Old 18th June 2015, 06:48   #200  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
holy lord, I'm staring at the "mvtools" source code and it's gonna be... painful to add native float point support to it, practically gotta rewrite the whole thing, so I'm thinking of an alternative, we keep int stuff here, but pick uint32 instead of uint16, and vs got no support for Gray32, so convert uint32 to single at the final step, guess gotta remove some asm here cuz they won't work on uint32
feisty2 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:36.


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