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 > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 7th July 2016, 20:03   #2041  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
forget it i found it
EDIT: ok, looks promising. might be interesting for us too to just use this.
__________________
AviSynth+

Last edited by ultim; 7th July 2016 at 20:09.
ultim is offline   Reply With Quote
Old 7th July 2016, 20:19   #2042  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,256
Quote:
Originally Posted by ultim View Post
Ok so I got home, and since I know that at least for RGB 16-bit images pixels are scaled to 65535, I wanted to make sure that this 256-factor for YUV is not just some shit from MS. I fired up the bt709 spec, and it's true. While I haven't found a direct mention of how to scale to larger bitdepths (it doesn't define 16bit at all, only 10), it still implies simple power-of-two factors simply from the allowed data ranges in 8- and 10-bits. So I guess we should switch to this scale too. EDIT: Oh, I see pinterf already changed it. Good work :thumbs up:
Changed after reading this one, which mentiones 12 bit rec 2020 with the exact black and white levels
pinterf is offline   Reply With Quote
Old 7th July 2016, 20:27   #2043  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,256
Wilbert, it was then you, who put those planar RGB constants in avisynth.h? The current development unfortunately phase lacks the high bit depth RGB.

When I uncommented and renamed the YUV planar constants in the header three weeks ago, I was thinking what to do with the RGB 48 bit, but wasn't familiar at all with that planar RGB, so the option remained in silence.
pinterf is offline   Reply With Quote
Old 7th July 2016, 22:02   #2044  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,335
Quote:
Originally Posted by pinterf View Post
Wilbert, it was then you, who put those planar RGB constants in avisynth.h? The current development unfortunately phase lacks the high bit depth RGB.

When I uncommented and renamed the YUV planar constants in the header three weeks ago, I was thinking what to do with the RGB 48 bit, but wasn't familiar at all with that planar RGB, so the option remained in silence.
Ianb added them in avisynth.h. I just uncommented them and added the necessary stuff in order to be able to open and write 16-bit images with DevIL. It was fun to do that, but lost interest and didn't bother to clean it up.

Btw, regarding the functions ConvertTo8Bits(), etc ...
What about replacing them with a single one:
ConvertToBitDepth(bit-depth=8/16/float, dither=none/random/ordered/...)
Then you can add several dither methods later. I only implemented random dithering at that time (because that was a fast method).

Last edited by Wilbert; 8th July 2016 at 23:13.
Wilbert is offline   Reply With Quote
Old 8th July 2016, 10:33   #2045  |  Link
ajp_anton
Registered User
 
ajp_anton's Avatar
 
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 782
What about dithering to 10 bits, but still using 16 bits to preserve those two extra bits beyond 8? Like when encoding 10 bits with x264. I think dithering should be a separate function where you can set the target bitdepth to dither to (which can then be any integer below the current bitdepth), and the "convert to some bitdepth" should just round/truncate.
ajp_anton is offline   Reply With Quote
Old 8th July 2016, 10:59   #2046  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: Los Angeles, California
Posts: 2,134
actually I think it's a bit more complicated than that..
so, uint8_t->uint16_t

tv range should be
y = x * 256

full range should be
x -> y
0 -> 0
128 -> 32768
255 -> 65535
and obviously not a linear conversion
__________________
If I got new ideas, will post here: https://github.com/IFeelBloated
feisty2 is offline   Reply With Quote
Old 8th July 2016, 11:14   #2047  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: Los Angeles, California
Posts: 2,134
and "128 -> 32768" is a must in full range case cuz pure black is [0, 128, 128] at uint8_t and [0, 32768, 32768] at uint16_t, and simple * 257 makes [0, 128, 128] go [0, 32896, 32896] and that's not pure black no more so incorrect conversion
__________________
If I got new ideas, will post here: https://github.com/IFeelBloated
feisty2 is offline   Reply With Quote
Old 8th July 2016, 12:49   #2048  |  Link
asteri
Registered User
 
Join Date: Nov 2013
Posts: 28
Quote:
Originally Posted by Groucho2004 View Post
Here. This installer does not include the VC runtimes. If you need them, use the ones from ultim's dl location. I highly recommend to use ricktendo's All In One runtime installer, very compact and all versions you'll ever need included.
r2022? I thought latest version is r1858 MT-pfmod. I became lost in number of releases and their versions. Can you explain what your r2022 has against 1858 MT-pfmod ?
asteri is offline   Reply With Quote
Old 8th July 2016, 12:55   #2049  |  Link
colours
Registered User
 
colours's Avatar
 
Join Date: Mar 2014
Posts: 312
Quote:
Originally Posted by feisty2 View Post
full range should be
x -> y
0 -> 0
128 -> 32768
255 -> 65535
and obviously not a linear conversion

and "128 -> 32768" is a must in full range case cuz pure black is [0, 128, 128] at uint8_t and [0, 32768, 32768] at uint16_t, and simple * 257 makes [0, 128, 128] go [0, 32896, 32896] and that's not pure black no more so incorrect conversion
… No? Where the hell do you even get these funny ideas?

The midpoint is 127.5 for full-range 8-bit video, and multiplying by 257 just gives you 32767.5, which is the midpoint for full-range 16-bit video.

It is a known problem that this convention for full-range YCbCr fails to accurately represent any pure grey colour, which is why there's another convention where the nominal minimum is 0 and the nominal maximum is 2^n, which in turn runs into the problem of failing to accurately represent pure red (#FF0000) and pure blue (#0000FF).

Neither of these conventions is nonlinear, but what you're proposing is.

Quote:
that's not pure black no more
Also, please type English.
__________________
Say no to AviSynth 2.5.8 and DirectShowSource!

Last edited by colours; 8th July 2016 at 12:59.
colours is offline   Reply With Quote
Old 8th July 2016, 13:01   #2050  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,226
Quote:
Originally Posted by asteri View Post
r2022? I thought latest version is r1858 MT-pfmod. I became lost in number of releases and their versions. Can you explain what your r2022 has against 1858 MT-pfmod ?
Please learn how to read previous pages of forum.

http://forum.doom9.org/showthread.ph...57#post1772657
http://forum.doom9.org/showthread.ph...44#post1772944
ryrynz is offline   Reply With Quote
Old 8th July 2016, 13:29   #2051  |  Link
asteri
Registered User
 
Join Date: Nov 2013
Posts: 28
Quote:
Originally Posted by ryrynz View Post
Thank you!
I would recommend ultim to publish these builds as "test builds" also on official page: http://avs-plus.net/
asteri is offline   Reply With Quote
Old 8th July 2016, 13:37   #2052  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,226
Quote:
Originally Posted by asteri View Post
Thank you!
I would recommend ultim to publish these builds as "test builds" also on official page: http://avs-plus.net/
I don't think that will happen. The most recent changes break some previously compatible plugins plus there has been a lot of code committed recently. A proper build will be posted when ready.
ryrynz is offline   Reply With Quote
Old 8th July 2016, 13:53   #2053  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: Los Angeles, California
Posts: 2,134
Quote:
Originally Posted by colours View Post

The midpoint is 127.5 for full-range 8-bit video, and multiplying by 257 just gives you 32767.5, which is the midpoint for full-range 16-bit video.
127.5 agreed, theoretically (0+255)/2=127.5, and 127.5 is not an integer.

Quote:
It is a known problem that this convention for full-range YCbCr fails to accurately represent any pure grey colour, which is why there's another convention where the nominal minimum is 0 and the nominal maximum is 2^n, which in turn runs into the problem of failing to accurately represent pure red (#FF0000) and pure blue (#0000FF).
agreed, and instead of assuming representing any pure gray color is impossible, I think it makes sense to round 127.5 to 128 and gray colors will be representable, and I will hold on to my point before you link me a doc that explains how full range YCbCr works in detail, got noda last time I googled about full range YUV

Quote:
Also, please type English.
I'm 19 not 91 and I'm good with the language I'm typing, and I will roll with it, you don't like it? suck it, bite me! bi-o-tch
__________________
If I got new ideas, will post here: https://github.com/IFeelBloated
feisty2 is offline   Reply With Quote
Old 8th July 2016, 14:33   #2054  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: Los Angeles, California
Posts: 2,134
oh, and btw, just say if 127.5 is exactly how standards defined it, and gray colors are not representable, pure black will be rounded to its closest color [0, 128, 128] at uint8_t and [0, 32768, 32768] at uint16_t, your way, * 257, it's gonna be [0, 32896, 32896], my way, [0, 32768, 32768], and obviously the error between 32768 and 32767.5 << the error between 32896 and 32767.5
__________________
If I got new ideas, will post here: https://github.com/IFeelBloated
feisty2 is offline   Reply With Quote
Old 8th July 2016, 17:26   #2055  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,256
New internal filters ported to 16 bit/float
  • AddBorders
  • LetterBox
  • HorizontalReduceBy2
  • VerticalReduceBy2
  • ReduceBy2 (= Horiz + Vert)
  • BlankClip/Blackness (->FadeXXX )
  • Tweak (todo: sat=0 + Float source = little greenish),
    new param: bool realcalc, always true for 16/float: no integer lookup table arithmetic, pure double

Took a list from here and made a summary of YUV related functions that have NO 16/32 bit version.

Color conversion and adjustment filters
  • ColorYUV
  • Invert
  • Levels
  • Limiter
  • MergeARGB / MergeRGB

Overlay and Mask filters
  • MaskHS
  • Overlay
  • Subtract

Geometric deformation filters
  • SkewRows

Pixel restoration filters
  • Blur / Sharpen

Debug filters (most of it)
  • ColorBars / ColorBarsHD
  • Compare
  • Histogram
  • Info
  • ShowFrameNumber / ShowSMPTE / ShowTime
  • Subtitle

Last edited by pinterf; 8th July 2016 at 23:13. Reason: 16/32 bit ready BlankClip added + Tweak
pinterf is offline   Reply With Quote
Old 8th July 2016, 22:12   #2056  |  Link
colours
Registered User
 
colours's Avatar
 
Join Date: Mar 2014
Posts: 312
Quote:
Originally Posted by feisty2 View Post
oh, and btw, just say if 127.5 is exactly how standards defined it
The only standard I know of defining what to do with full-range YCbCr is JFIF, and it has a nominal luma range of 0 to 255 and a nominal chroma range of 0.5 to 255.5. (libjpeg-turbo implements this. Z also assumes this convention, as does Dither_convert_rgb_to_yuv/yuv_to_rgb. I think swscale also does this, but the source code is a nightmare to read so I'm not 100% sure.)

AVS (and by extension, AVS+) uses a different convention for the Convert* filters, where the nominal luma range is 0 to 255 and the nominal chroma range is 1 to 255.

The "correct" convention is obviously 0 to 255 for both luma and chroma, but for whatever reason that's not what we ended up with. Apart from JFIF (which, you know, defines only what to do for JFIF files), no standard in common use defines what the nominal levels for full-range YCbCr should be; BT.601, BT.709, etc. only define the nominal levels for TV-range YCbCr.

Edit: Since vivan mentioned H.264, I went and checked that, and it defines a nominal chroma range of 0.5 to 2^n−0.5 in Annex E. (I assume HEVC says the same thing.) But really, my original point was that these all map RGB values to YCbCr values linearly; the exact endpoints to use for the range is something we can decide after we get rid of the strange idea of mapping 0 to 0, 128 to 32768, and 255 to 65535.

Quote:
pure black will be rounded to its closest color [0, 128, 128] at uint8_t
In case you're bad at arithmetic, 127.5 is equally close to both 127 and 128.

Quote:
and obviously the error between 32768 and 32767.5 << the error between 32896 and 32767.5
Also, dithering exists and anyone who cares about colour accuracy is already using it when converting between colourspaces with limited precision.
__________________
Say no to AviSynth 2.5.8 and DirectShowSource!

Last edited by colours; 9th July 2016 at 09:30. Reason: >typo
colours is offline   Reply With Quote
Old 8th July 2016, 22:33   #2057  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 1,293
Quote:
Originally Posted by pinterf View Post
New internal filters ported to 16 bit/float
  • AddBorders
  • LetterBox
  • HorizontalReduceBy2
  • VerticalReduceBy2
  • ReduceBy2 (= Horiz + Vert)
  • BlankClip/Blackness (->FadeXXX )

Took a list from here and made a summary of YUV related functions that have NO 16/32 bit version.

Color conversion and adjustment filters
  • ColorYUV
  • Invert
  • Levels
  • Limiter
  • MergeARGB / MergeRGB
  • Tweak

Overlay and Mask filters
  • MaskHS
  • Overlay
  • Subtract

Geometric deformation filters
  • SkewRows

Pixel restoration filters
  • Blur / Sharpen

Debug filters (most of it)
  • ColorBars / ColorBarsHD
  • Compare
  • Histogram
  • Info
  • ShowFrameNumber / ShowSMPTE / ShowTime
  • Subtitle
Compare has a bug in Y8 http://forum.doom9.org/showthread.ph...37#post1773137

what about UToY8(clip clip) and VToY8(clip clip)?

UToY and VToY was already there

so for 16 bit/float will have a new UToYx and VToYx or UToYUV400 and VToYUV400 to output in HBD?
__________________
My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 8th July 2016, 22:57   #2058  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 1,034
Any modernization to SMDegrain with newer 16 bit filters would be glad
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 8th July 2016, 23:16   #2059  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,256
Edited the summary above with:
Tweak (todo: sat=0 + Float source = little greenish),
new param: bool realcalc, always true for 16/float: no integer lookup table arithmetic, pure double

And now one week holiday mode ON.
Probably I will read the forum but my internet will be limited.
pinterf is offline   Reply With Quote
Old 8th July 2016, 23:21   #2060  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,256
Quote:
Originally Posted by real.finder View Post
Compare has a bug in Y8 http://forum.doom9.org/showthread.ph...37#post1773137

what about UToY8(clip clip) and VToY8(clip clip)?

UToY and VToY was already there

so for 16 bit/float will have a new UToYx and VToYx or UToYUV400 and VToYUV400 to output in HBD?
Unfortunately UtoY and VToY is reserved already, and works with 16/32 bit. They do not truncate to a Y8/Y16/Y32 clip.

So UtoY8 and VToY8 is silently working like UtoY16/32 and VtoY16/32. The result clip is greyscale one.
I did not like the names like UtoLumaOnly, etc... so it remained with the Y8 ending, until someone finds a proper name for it and everybody agrees with it
pinterf 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 03:36.


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