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. |
7th July 2016, 19:03 | #2041 | Link |
AVS+ Dev
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 19:09. |
7th July 2016, 19:19 | #2042 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Quote:
|
|
7th July 2016, 19:27 | #2043 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
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. |
7th July 2016, 21:02 | #2044 | Link | |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
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 22:13. |
|
8th July 2016, 09:33 | #2045 | Link |
Registered User
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
|
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.
|
8th July 2016, 10:14 | #2047 | Link |
I'm Siri
Join Date: Oct 2012
Location: void
Posts: 2,633
|
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
|
8th July 2016, 11:49 | #2048 | Link | |
Registered User
Join Date: Nov 2013
Posts: 28
|
Quote:
|
|
8th July 2016, 11:55 | #2049 | Link | ||
Registered User
Join Date: Mar 2014
Posts: 308
|
Quote:
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:
__________________
Say no to AviSynth 2.5.8 and DirectShowSource! Last edited by colours; 8th July 2016 at 11:59. |
||
8th July 2016, 12:01 | #2050 | Link | |
Registered User
Join Date: Mar 2009
Posts: 3,650
|
Quote:
http://forum.doom9.org/showthread.ph...57#post1772657 http://forum.doom9.org/showthread.ph...44#post1772944 |
|
8th July 2016, 12:29 | #2051 | Link | |
Registered User
Join Date: Nov 2013
Posts: 28
|
Quote:
I would recommend ultim to publish these builds as "test builds" also on official page: http://avs-plus.net/ |
|
8th July 2016, 12:37 | #2052 | Link | |
Registered User
Join Date: Mar 2009
Posts: 3,650
|
Quote:
|
|
8th July 2016, 12:53 | #2053 | Link | |||
I'm Siri
Join Date: Oct 2012
Location: void
Posts: 2,633
|
Quote:
Quote:
Quote:
|
|||
8th July 2016, 13:33 | #2054 | Link |
I'm Siri
Join Date: Oct 2012
Location: void
Posts: 2,633
|
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
|
8th July 2016, 16:26 | #2055 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
New internal filters ported to 16 bit/float
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
Overlay and Mask filters
Geometric deformation filters
Pixel restoration filters
Debug filters (most of it)
Last edited by pinterf; 8th July 2016 at 22:13. Reason: 16/32 bit ready BlankClip added + Tweak |
8th July 2016, 21:12 | #2056 | Link | |||
Registered User
Join Date: Mar 2014
Posts: 308
|
Quote:
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:
Quote:
__________________
Say no to AviSynth 2.5.8 and DirectShowSource! Last edited by colours; 9th July 2016 at 08:30. Reason: >typo |
|||
8th July 2016, 21:33 | #2057 | Link | |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
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?
__________________
See My Avisynth Stuff |
|
8th July 2016, 22:16 | #2059 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
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. |
8th July 2016, 22:21 | #2060 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Quote:
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 |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|