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

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 6th July 2016, 20:52   #2021  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by Wilbert View Post
Question: what happens when doing for example ConvertToYV12(available options) on a 16/32 bit YUV source? Is that implemented already?
ConvertToYV12/16/24 operates only on 8 bit.

But within bitdepth ConvertTo420 inherited the same functionality as ConvertToYV12. Of course, no 16/32 bit RGB input (yet)
pinterf is offline  
Old 6th July 2016, 21:00   #2022  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Basic bitdepth converters are ready and pull requested.
ConvertTo8bit, ConvertTo16bit, ConvertToFloat

No dithering or whatever, plain c, float conversions accept a scale parameter, which is defaulting to 1.0 (0..1.0)

Code:
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("lsmashvideosource", 3)
lsmashvideosource("13HoursCUT.mp4", format="YUV420P8")
x=last # 8 bit source test cases
x = x.ConvertToFloat() # 8-32
x = x.ConvertTo16bit() # 32-16
x = x.ConvertToFloat() # 16-32
x = x.ConvertTo16bit() # 32-16
x = x.ConvertTo8bit()  # 16-8
x = x.ConvertTo16bit() # 8-16

x = x.Crop(0, 140, 0, -140)
x = x.Spline64Resize(900,500)
c8_420 = x.ConvertToYUV420(chromaresample="spline64", chromaOutPlacement = "mpeg2") #chromaInPlacement = "mpeg2",
c8_422 = x.ConvertToYUV422(chromaresample="bilinear") # chromaInPlacement = "mpeg2" 
c8_444 = x.ConvertToYUV444()
c8_420_b = c8_444.ConvertToYUV420(chromaresample="point", chromaOutPlacement = "dv")

c8_420 = c8_420.ConvertToYUV444(chromaInPlacement = "mpeg1")
c8_422 = c8_422.ConvertToYUV444()
c8_444 = c8_444.ConvertToYUV444()
c8_420_b = c8_420_b.ConvertToYUV444()
StackHorizontal(StackVertical(c8_420,c8_420_b),StackVertical(c8_422,c8_444))
ConvertTo8bit()
Prefetch(8)
btw, it turned out that Float resizers don't look healty
pinterf is offline  
Old 6th July 2016, 21:03   #2023  |  Link
jackoneill
unsigned int
 
jackoneill's Avatar
 
Join Date: Oct 2012
Location: 🇪🇺
Posts: 760
Quote:
Originally Posted by Wilbert View Post
feature requests:

1) ConvertToYUV400 (same naming as ConvertYUV444, instead of ConvertToY16/32),
One would expect a format called "YUV4XX" to have three planes. Will this have three planes or will it surprise users by having just one plane?
__________________
Buy me a "coffee" and/or hire me to write code!
jackoneill is offline  
Old 6th July 2016, 21:12   #2024  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
@Ultim, Pinterf,

Sounds great. Once high bit-depth planar RGB is also supported, it's possible to load and save high bit-depth images using DevIL (sadly DevIL supports only interleaved and not planar RGB formats).
I implemented such a thing a long time ago: https://sourceforge.net/p/avisynth2/patches/6/ At least i got it working

@jackoneill, i see what you mean. I thought it would be a good idea to have a consistent naming of those conversions. I guess better would be ConvertToY400.

Last edited by Wilbert; 6th July 2016 at 21:17.
Wilbert is offline  
Old 6th July 2016, 21:32   #2025  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Dah... my two cents: let's just stick to ConvertToY().
__________________
AviSynth+
ultim is offline  
Old 6th July 2016, 22:54   #2026  |  Link
Chikuzen
typo lover
 
Chikuzen's Avatar
 
Join Date: May 2009
Posts: 595
https://github.com/AviSynth/AviSynth...nvert.cpp#L742

I wouldn't like these conversions

on 8bit to 16bit
dstp0[x] = srcp0[x] << 8;

on 16bit to 8bit
dstp[x] = min((srcp0[x] >> 8) + ((srcp0[x] & 0x00FF) >> 7), 255);

on float to integer
dstp0[x] = static_cast<pixel_t>(srcp0[x] * factor + 0.5f);

I think these are general way.
- on high precision to low precision, rounding is better than truncation because less error.
- bit shift and saturate is easier to optimize than multiplication and division.
__________________
my repositories

Last edited by Chikuzen; 7th July 2016 at 02:28.
Chikuzen is offline  
Old 7th July 2016, 01:33   #2027  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,559
Quote:
Originally Posted by Groucho2004 View Post
Why do you post this here? Trying to get your post count up? You already announced it in your own thread.
Is this now becoming a permanent thing that you fill almost every thread on this forum with your random ramblings?
I will try my best to not take these attacks personal and to reduce the opportunities for verbal violence
MysteryX is offline  
Old 7th July 2016, 05:10   #2028  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by Chikuzen View Post
https://github.com/AviSynth/AviSynth...nvert.cpp#L742

I wouldn't like these conversions

on 8bit to 16bit
dstp0[x] = srcp0[x] << 8;

on 16bit to 8bit
dstp[x] = min((srcp0[x] >> 8) + ((srcp0[x] & 0x00FF) >> 7), 255);

on float to integer
dstp0[x] = static_cast<pixel_t>(srcp0[x] * factor + 0.5f);

I think these are general way.
- on high precision to low precision, rounding is better than truncation because less error.
- bit shift and saturate is easier to optimize than multiplication and division.
Both of your 16bit <-> 8bit conversions are very wrong.

When going from 8 to 16, you need to map the whole range of 0..225 to 0..65535. In your suggestion, you are simply multiplying by 256. 255x256 is 65280 instead of 65535. You actually need to scale by 257 instead of 256 for correct results, and pinterf is doing it correctly (257=65535/255).

When going down from 16 to 8, you need the reverse: x*255/65535. Unlike when going up, here it is sufficient to just shift by 8 bits for exact reults, because if your input is not a power of 2, your result will be like an integer-truncated division by 256.

Both these conversions from pinterf are correct. There is however an optimization potential he did not make use of when converting up to 16bit. The same upscaling can be done using only simple bit-arithmetic which often takes less machine cycles. If x is an 8-bit number, you can do (x << 8) | x to arrive at the 16-bit range, and this will also give exact results.

You are right about the float->int conversion though, adding 0.5f before the cast would minimize truncation errors.
__________________
AviSynth+
ultim is offline  
Old 7th July 2016, 07:01   #2029  |  Link
vivan
/人 ◕ ‿‿ ◕ 人\
 
Join Date: May 2011
Location: Russia
Posts: 643
Quote:
Originally Posted by ultim View Post
Both of your 16bit <-> 8bit conversions are very wrong.

When going from 8 to 16, you need to map the whole range of 0..255 to 0..65535.
It's not the only correct conversion. Actually standarts (BT.709/BT.2020) define another conversion, which uses 2^(n-8) as scaling factor. And so does msdn.

Data is interpreted as having integer (higher 8 bits) and fractional (lower 8 bits) components. And this makes 16.0 and 235.0 (240.0) black and peak values regardless of the bitdepth.

I rememeber when ffmpeg first implemented high bit depth support is also used x >> 8 || x conversion, but it was then corrected.

Last edited by vivan; 7th July 2016 at 07:07.
vivan is offline  
Old 7th July 2016, 07:53   #2030  |  Link
Chikuzen
typo lover
 
Chikuzen's Avatar
 
Join Date: May 2009
Posts: 595
Quote:
Originally Posted by vivan View Post
Actually standarts (BT.709/BT.2020) define another conversion, which uses 2^(n-8) as scaling factor. And so does msdn.
I remembered that msdn page, too.
pinterf is correct about down scale to 8bit.
__________________
my repositories
Chikuzen is offline  
Old 7th July 2016, 08:44   #2031  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by pinterf View Post
btw, it turned out that Float resizers don't look healty
They are healthy now.
pinterf is offline  
Old 7th July 2016, 08:46   #2032  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by vivan View Post
Data is interpreted as having integer (higher 8 bits) and fractional (lower 8 bits) components. And this makes 16.0 and 235.0 (240.0) black and peak values regardless of the bitdepth.
This is important.
pinterf is offline  
Old 7th July 2016, 08:52   #2033  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by ultim View Post
When going down from 16 to 8, you need the reverse: x*255/65535. Unlike when going up, here it is sufficient to just shift by 8 bits for exact reults, because if your input is not a power of 2, your result will be like an integer-truncated division by 256.
This is not exact

65404*255/65535 = 254.49 -> rounds to 254

65404>>8 = 255
__________________
VirtualDub2
shekh is offline  
Old 7th July 2016, 11:44   #2034  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by shekh View Post
This is not exact

65404*255/65535 = 254.49 -> rounds to 254

65404>>8 = 255
"because if your input is not a power of 2, your result will be like an integer-truncated division by 256" ... and not by 257, which is why it is nonsense what I wrote here. You are right, sorry, I don't know what I was thinking.
__________________
AviSynth+
ultim is offline  
Old 7th July 2016, 11:59   #2035  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by vivan View Post
It's not the only correct conversion. Actually standarts (BT.709/BT.2020) define another conversion, which uses 2^(n-8) as scaling factor. And so does msdn.

Data is interpreted as having integer (higher 8 bits) and fractional (lower 8 bits) components. And this makes 16.0 and 235.0 (240.0) black and peak values regardless of the bitdepth.

I rememeber when ffmpeg first implemented high bit depth support is also used x >> 8 || x conversion, but it was then corrected.
Ok, I didn't know that the scaling factor here is defined explicitly as 2^n. The boundaries 16-235/240 just come from TV-levels though.
__________________
AviSynth+
ultim is offline  
Old 7th July 2016, 12:11   #2036  |  Link
Chikuzen
typo lover
 
Chikuzen's Avatar
 
Join Date: May 2009
Posts: 595
btw, I modified RawSource26 to support HDB formats.

Binary

note that this plugin will not work on avs2.6.
__________________
my repositories
Chikuzen is offline  
Old 7th July 2016, 13:10   #2037  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Then maybe it should be called RawSourcePlus instead...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline  
Old 7th July 2016, 17:15   #2038  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
1.) TemporalSoften 16bit/float ready.
Parameter ranges for thresholds and scenechange are unchanged 0-255. They are scaled internally to have the same effect on all bitdepth.
2.) 8->16 bit conversion reverted to p << 8. Let's not reinvent the wheel.
pinterf is offline  
Old 7th July 2016, 18:16   #2039  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
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:
__________________
AviSynth+

Last edited by ultim; 7th July 2016 at 18:19.
ultim is offline  
Old 7th July 2016, 18:42   #2040  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
Quote:
Originally Posted by MysteryX View Post
Quote:
Originally Posted by Groucho2004
Why do you post this here? Trying to get your post count up? You already announced it in your own thread.
Is this now becoming a permanent thing that you fill almost every thread on this forum with your random ramblings?
Quote:
Originally Posted by MysteryX View Post
I will try my best to not take these attacks personal and to reduce the opportunities for verbal violence
Groucho2004 is right. #2018 has nothing to do with AviSynth+ development. See #1875 for another example of a useless post. I suggest you remove those posts and respect the forum rules a little bit.
Wilbert is offline  
Closed Thread

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 19:33.


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