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. |
21st August 2019, 12:32 | #4821 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
|
Quote:
Full Range 0-255 / Limited TV Range: 16-235 10bit: Full Range 0-1023 / Limited TV Range: 64-940 12bit: Full Range 0-4080 / Limited TV Range: 256-3760 14bit: Full Range 0-16320 / Limited TV Range: 1024-15040 16bit: Full Range 0-65280 / Limited TV Range: 4096-60160 32bit float: Full Range 0.0-0.99609375 / Limited TV Range: 0.0625-0.91796875 This simulates clipping a 32bit signal: Code:
ColorBars(848, 480, pixel_type="YV12") ConvertBits(32, truerange=true) Limiter(min_luma=0.0625, max_luma=0.91796875) Wrongly clipping 8bit values from a 32bit float clip: Code:
ColorBars(848, 480, pixel_type="YV12") ConvertBits(32, truerange=true) Limiter(min_luma=16, max_luma=235) I personally work with 16bit precision which I think it's enough when my output is gonna be dithered down to 8bit for SD, HD and FULL HD footages, 10bit for UHD broadcast footages and 12bit for UHD Masterfiles. So far I haven't used 32bit precision in a real world scenario, but still, it's kinda cool to have such an high bit depth. Last edited by FranceBB; 22nd August 2019 at 22:30. |
|
21st August 2019, 13:52 | #4822 | Link | |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,309
|
Quote:
Is this only YUV, or is it also RGB (mostly for 16bits for the last one). I didn't expect remaining gap between theorical max for full range.
__________________
My github. Last edited by jpsdr; 21st August 2019 at 13:56. |
|
21st August 2019, 14:51 | #4823 | Link | |
Formerly davidh*****
Join Date: Jan 2004
Posts: 2,493
|
Quote:
10-bit wasn't on the list but I assume it's 0-1020. It's possibly a way to make all up-conversions consistent/transitive (and fast), but I wonder if down-conversions are more complicated. By a simple bit-shift, only one value in 16-bit would map to 255 in 8-bit (62580), whereas 256 values (0-255) would map to 0. |
|
21st August 2019, 15:16 | #4824 | Link | |||
Eurobeat Fan
Join Date: Sep 2014
Posts: 108
|
Quote:
Quote:
However, the question is: do filters actually expect pixel values to be in that range? ConvertBits, for instance, seems not to: Quote:
Code:
BlankClip(height=240).ConvertToPlanarRGB() Expr(String(255.0/256.0), format="RGBPS") # 255d StackVertical( Expr("x 256 *", format="RGBP8").ConvertToRGB32().RGBAdjust(analyze=true).Subtitle("'D notation'-compliant conversion"), \ ConvertToRGB32().RGBAdjust(analyze=true).Subtitle("Default conversion") ) Code:
BlankClip(pixel_type="YV24") Expr("0.0", format="YUV444PS") ColorYUV(levels="PC->TV") # Bug in ColorYUV? Picture turns green ColorYUV(analyze=true) # OK: luma is 0.6250 == 16/256 Expr("1.0", format="YUV444PS") ColorYUV(levels="PC->TV") ColorYUV(analyze=true) # Confusing: luma is 0.91796875 == 235/256, but input expected to be 1.0 rather than 255/256 Expr(String(235.0/256.0), format="YUV444PS") ColorYUV(levels="TV->PC") ColorYUV(analyze=true) # Same as before: 235/256 translates into 1.0 instead of 255/256 BlankClip(color_yuv=$108080, pixel_type="YV24") # Plain black in limited range ConvertBits(32) ColorYUV(analyze=true) # Inconsistent: 16d represented as 16/255 == 0.062745... (periodic number) In addition, RGBAdjust and Compare are unable to analyze floating-point pixel types, which makes it more difficult to see what's going on. Last edited by magiblot; 21st August 2019 at 15:57. |
|||
21st August 2019, 16:31 | #4826 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
My natural inclination when using up shift would be to fill the 'nullified' least signifcant bits in destination number with the most significant bits from source number.
Code:
eg 8->10 bit, 7654321076 src bit indexes 9876543210 dst bit indexes or eg 8->16 7654321076543210 fedcba9876543210 # hexified EDIT: I think Knuth, TAOCP, Vol 1, Fundamental Algorithms, would suggest same for fast accurate upscale using shift only. [I left my copy on a train many years ago].
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? Last edited by StainlessS; 21st August 2019 at 17:04. |
21st August 2019, 17:39 | #4827 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,346
|
Why is this horizontal line shifted ? (You can see it if you return a vs. b)
YV24 (and using ConvertToYUV444) works as expected, so is it some chroma resizing issue in 32bit? I tried different chromainplacement/chromaoutplacement settings as well r2772 MT x64 ; or is it already fixed in one of the beta releases ? Code:
a=colorbars(pixel_type="YV12").trim(0,-1) a ConvertBits(32) ConvertToPlanarRGB(matrix="rec601", chromaresample="point") ConvertToYUV420(matrix="rec601", chromaresample="point") ConvertBits(8) b=last interleave(a,b) |
21st August 2019, 17:49 | #4828 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Dont know but,
Code:
a=colorbars(pixel_type="YV12") a ConvertBits(32) ConvertToPlanarRGB(matrix="rec601", chromaresample="point") ConvertToYUV420(matrix="rec601", chromaresample="point") ConvertBits(8) b=last #a #b b.subtract(a).stackHorizontal(a) # EDITED ver$ r2900 EDIT: changed order from a.subtract(b) to b.subract(a) and reposted image. So, eg where subtracted is yellow, then output is more yellow than input. EDIT: Added in blue, b.subtract(a).stackHorizontal(a) Dont know if as expected or not.
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? Last edited by StainlessS; 21st August 2019 at 18:29. |
21st August 2019, 19:15 | #4829 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,346
|
It's supposed to be lossless ; it is with vapoursynth 32bit float "expected" range is 0-1 , but negative values , and values than 1 should are kept. They are in other programs too. That's one of the main reasons for using float. It's commonly used with raw processing, and high end effects/compositing You can read off the values in vapoursynth editor for different bit depths , and for float (<0 , >1 ), but I cannot "read" values in avspmod besides 8bit, I don't know what avs+ is doing I think this issue has something to do with chroma resampling, because if you do colorbars(pixel_type="YV24"), and ConvertToYUV444 after the RGB step, it works as expected (equivalent) If you do 8bit or 16bit (instead of 32), you got not equivalent (as expected) . Float is required for the lossless round trip, but if it was a problem with float processing in general then the YV24 should have errors too |
21st August 2019, 22:02 | #4830 | Link | |
Formerly davidh*****
Join Date: Jan 2004
Posts: 2,493
|
Quote:
Code:
10111111 -> 1011111110111111 10111111 -> 101111111011 -> 1011111110111011 |
|
21st August 2019, 23:46 | #4831 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Taken to extreme,
1 bit to 16 bit Code:
1 1111111111111111 # same as before but with the repeated downshift of most signiicant bits (recurring stuff). Shift only 1 # 1=max poss 1000000000000000 # half max poss
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? Last edited by StainlessS; 22nd August 2019 at 00:08. |
22nd August 2019, 10:04 | #4832 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,309
|
@FranceBB
Is there any spec (REC-BT, ...) where these full range data are described/explained ? And especialy if they also report to RGB. Because i'm almost sure (but maybe i'm wrong...), and mine included, the avs filters use for full range max value (2^nBits)-1 and not 255 << (nBits-8) (with exception of 10 bits). Seems a new value for the range parameter of my filter may be needed.
__________________
My github. Last edited by jpsdr; 23rd August 2019 at 10:01. |
23rd August 2019, 10:02 | #4834 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,309
|
It says that full range is (2^nBits)-1 and not 255 << (nBits-8), so, it's different from what FranceBB says.
But it's what T-REC-H.265-201802-S!!PDF-E says in page 409.
__________________
My github. Last edited by jpsdr; 23rd August 2019 at 10:15. |
23rd August 2019, 23:43 | #4835 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,823
|
I noticed an oddity in the way negative zero variables are converted to string when they're float. The variables in the script are never negative, but I want them to display that way, unless they're zero. The upshot is....
This displays as 0 subtitle(string(float(-0), "%.0f")) While this displays as -0 subtitle(string(-float(0), "%.0f")) As does this xxx = float(0) subtitle(string(-xxx, "%.0f")) And this xxx = -float(0) subtitle(string(xxx, "%.0f")) But not for a double negative. xxx = -float(0) subtitle(string(-xxx, "%.0f")) Avisynth 2.6 doesn't display the negative sign for any of them. Cheers. |
25th August 2019, 14:07 | #4836 | Link | |
Banana User
Join Date: Sep 2008
Posts: 985
|
Continuation from this post.
This script is 71 times faster in AVS v2.6 vs AVS+ : Quote:
|
|
25th August 2019, 17:29 | #4837 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? Last edited by StainlessS; 26th August 2019 at 08:06. |
26th August 2019, 03:09 | #4838 | Link |
Registered User
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
|
This might be a very odd and niche feature request, but here goes...
In ConditionalReader, the OFFSET command offsets all lines below it a fixed number of frames, but it can be overwritten by another OFFSET command. My request is to add a new command, something like ADDOFFSET (or if you can think of a better name), where it doesn't overwrite previous offsets, but adds its offset to the previous one. For example: Code:
# This is for frame 0, obviously 0 value0 OFFSET 2 # This is for frame 3: 1 + offset 2 1 value1 # This adds 4 to the previous offset of 2 ADDOFFSET 4 # So this is now for frame 8: 2 + offsets 2+4 2 value2 # And this will overwrite the previous offset(s), as before OFFSET 10 # So this is for frame 13: 3 + offset 10 3 value3 edit: Or maybe you could call it by Code:
OFFSET+=4 # and of course also OFFSET-=4 # while maybe even adding the possibility to write OFFSET=2 And for the motivation of this... say you have a long list of values for sequential frames, but then you need to add gaps here and there. With the current implementation of OFFSET, you can't change one gap without having to also change every OFFSET after it, and you can't directly read what the gap is without having to subtract the previous OFFSET. Last edited by ajp_anton; 26th August 2019 at 03:29. |
26th August 2019, 03:49 | #4840 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Quote:
Code:
BlankClip(length=1000000000) return Last EDIT: and with mostly loop()s Code:
#clip=LSMashvideoSource("1941 Flint Michigan Parade [Low, 360p].mp4") clip=BlankClip(length=3000) clp = clip.ConvertToRGB24 a = clp.Trim(20,-30) + clp.Trim(2000,-30) #a = a+a+a+a+a+a+a+a+a+a # *10 #a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20 #a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20 #a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20 #a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20, = * 1600000 ::: 1600000 * 60 = 96,000,000 a=a.loop(1600000,0,59) return a #.info # 96,000,000 frames ### Max possible frames = $7FFFFFFF, ~= 2,000,000,000 EDIT: Avs+ a bit faster if no ConvertToRGB24 [EDIT: Avs 2.6 std takes about 2:45.00 for same script, unlike previous, quite a bit longer than avs+] Code:
#clip=LSMashvideoSource("1941 Flint Michigan Parade [Low, 360p].mp4") clip=BlankClip(length=3000).Killaudio #clp = clip.ConvertToRGB24 clp=clip a = clp.Trim(20,-30) + clp.Trim(2000,-30) #a = a+a+a+a+a+a+a+a+a+a # *10 #a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20 #a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20 #a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20 #a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20, = * 1600000 ::: 1600000 * 60 = 96,000,000 a=a.loop(1600000,0,59) return a #.info # 96,000,000 frames ### Max possible frames = $7FFFFFFF, ~= 2,000,000,000
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? Last edited by StainlessS; 26th August 2019 at 05:06. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|