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. |
6th July 2016, 20:52 | #2021 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Quote:
But within bitdepth ConvertTo420 inherited the same functionality as ConvertToYV12. Of course, no 16/32 bit RGB input (yet) |
|
6th July 2016, 21:00 | #2022 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
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) |
6th July 2016, 21:03 | #2023 | Link |
unsigned int
Join Date: Oct 2012
Location: 🇪🇺
Posts: 760
|
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! |
6th July 2016, 21:12 | #2024 | Link |
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. |
6th July 2016, 22:54 | #2026 | Link |
typo lover
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. |
7th July 2016, 05:10 | #2028 | Link | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
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+ |
|
7th July 2016, 07:01 | #2029 | Link | |
/人 ◕ ‿‿ ◕ 人\
Join Date: May 2011
Location: Russia
Posts: 643
|
Quote:
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. |
|
7th July 2016, 07:53 | #2030 | Link | |
typo lover
Join Date: May 2009
Posts: 595
|
Quote:
pinterf is correct about down scale to 8bit.
__________________
my repositories |
|
7th July 2016, 08:52 | #2033 | Link | |
Registered User
Join Date: Mar 2015
Posts: 775
|
Quote:
65404*255/65535 = 254.49 -> rounds to 254 65404>>8 = 255
__________________
VirtualDub2 |
|
7th July 2016, 11:44 | #2034 | Link |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
"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+ |
7th July 2016, 11:59 | #2035 | Link | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
__________________
AviSynth+ |
|
7th July 2016, 12:11 | #2036 | Link |
typo lover
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 |
7th July 2016, 17:15 | #2038 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
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. |
7th July 2016, 18:16 | #2039 | Link |
AVS+ Dev
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. |
7th July 2016, 18:42 | #2040 | Link | ||
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
Quote:
|
||
Thread Tools | Search this Thread |
Display Modes | |
|
|