Welcome to Doom9's Forum, THE inplace 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. 
5th October 2015, 08:20  #21  Link 
Registered User
Join Date: Dec 2011
Posts: 354

I'm not a video professional, or not even amateur video fan. I'm just a guy who do some rips.
I'm not knowledgeable about video stuffs like you guys. But I just wanted to say this. About this arguments, being mathematically lossless really matters in real life practice? For example this video https://www.youtube.com/watch?v=kIq5CZlg8Rg Yeah, example itself in this video is bullshit. But this is the what we call simplify or "precision" right? (Simplifying and precision is different things in math world, I know. But still you got a point.) In real life, physicists do math by simplifying, to get close enough if not exact value and to save a time (or you could just say it "not to waste your precious time on not really worth calculate stuffs"). Video engineering or computer engineering is "physics thing" right? Yeah if there are methods to calculate exact value, that is a good thing. But I ask again, on this thread and real life practice videos, is that really matters? Last edited by bxyhxyh; 5th October 2015 at 08:50. Reason: typo 
5th October 2015, 10:36  #23  Link  
Registered User
Join Date: Mar 2006
Posts: 1,049

Quote:
Why those signals are common in YCbCr world?  they are used to measure video circuits. 

5th October 2015, 10:38  #24  Link 
I'm Siri
Join Date: Oct 2012
Location: void
Posts: 2,633

and ycbcr actually acts more appropriately as a YUV colorspace, it separates luminance and chrominance precisely but it's just not lossless (under finite precision)
ycgco is just lossless for lossless, like it's just designed to be lossless, not separating luminance and chrominance precisely like ycbcr 
5th October 2015, 10:38  #25  Link  
Registered User
Join Date: Dec 2011
Posts: 354

Quote:
You guys are defining "lossless" in your own ways. Yours is of course true. But Vivan's is also true. I maybe got wrong. Correct me if I'm wrong. I got this from Vivan's statements. Think that original value was 0.123. It have changed to 0.123456 with some algorithm. But If machine only display 4 digit value, then 0.123456 is equal to 0.123. First value 0.123 and last one also 0.123. Lossless! Similar for ycgco. It is Vivan's point right? Then I agree this. Last edited by bxyhxyh; 5th October 2015 at 10:44. 

5th October 2015, 11:08  #27  Link  
/人 ◕ ‿‿ ◕ 人\
Join Date: May 2011
Location: Russia
Posts: 643

Quote:
But we're talking about RGB>YCbCr>RGB transform, not YCbCr>RGB>YCbCr. RGB fits into YCbCr completely, meaning that there's correspondence for every possible value. YCbCr does not. 

5th October 2015, 11:23  #28  Link  
I'm Siri
Join Date: Oct 2012
Location: void
Posts: 2,633

Quote:
like: YCgCo is lossless (it has no lsb) YCbCr (infinite precision) is lossless (it has no lsb, infinite precision is free from any sort of rounding/truncating) YCbCr (finite precision) is lossy (it does have lsb/errors, and lossy without further/the final rounding) 

5th October 2015, 11:42  #29  Link 
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,555

So far we a have a whole thread of people pedantically arguing about terminology and no one even trying to help with sephirotic's problem, which is that YV24 is being subsampled to YV12 and then resampled back to YV24 at some point along the chain, and has nothing to do with true or perceptually lossless at all. Could you guys TRY to stay even remotely on topic, or start a new thread debating your perception of terms?

5th October 2015, 11:50  #30  Link  
/人 ◕ ‿‿ ◕ 人\
Join Date: May 2011
Location: Russia
Posts: 643

Quote:
Quote:
His problem was a wrong colormatrix. He thought that difference he is seeing is due to subsampling, but it was not the case. And it was solved by using avisynth's convert function. 

5th October 2015, 12:09  #31  Link 
I'm Siri
Join Date: Oct 2012
Location: void
Posts: 2,633

suppose:
1. the precision of the input signal (a discrete function f (x)), is a constant value "p0" 2. define "round (f (x), px)" as rounding the values from the discrete function f (x) to precision "px" 3. define "new_higher_precision (f (x), px)" as increasing the precision of the values from f (x) to "px" by adding zeros as the LSB 4. the actual processing part is called g (x), and it works at the precision "p1" (p1 > p0) 5. the reverse process of g (x) is called h (x), and it works at precision "p1" as well if: h (g (new_higher_precision (f (x), p1))) = f (x) call it lossless else: lossy, even if round (h (g (new_higher_precision (f (x), p1))), p0) = f (x) Last edited by feisty2; 5th October 2015 at 12:16. 
5th October 2015, 12:12  #32  Link 
Registered User
Join Date: Nov 2014
Posts: 440

I admit that at one point I had trouble to understand.
From the mathematical point of view all conversions YUV <> RGB (and many others) are reversible. The only problem is implementation. The computer has a finite precision, thus it introduces errors. The only thing you can do is to make this error negligible as possible. In programs of mathematical calculation all the floatingpoint numbers are are converted into fractions if possible. If not, like Pi, are replaced with special symbols and converted into a numbers only at the end and only if required. No management program video has similar capabilities. The human eye has a finite precision, so implement RGB or YUV as six plans of double (384bit for pixel) it's useless.
__________________
github.com 
5th October 2015, 14:08  #33  Link  
I'm Siri
Join Date: Oct 2012
Location: void
Posts: 2,633

Quote:
how come stuff like fractions, pi, e.. were never supported at the hardware level thru all these years, they are just typical and super common stuff used like, everyday 

5th October 2015, 14:10  #34  Link 
Registered User
Join Date: Nov 2014
Posts: 440

Example, Pink colour sRGB(255, 203, 219).
In unsignednormalized is (255 / 255, 203 / 255, 219 / 255). Convert to Y'PbPr (ITUR BT.601). Take only Y' for this example. Kr = 0.299 = 299 / 1000; Kg = 1  0.114  0.299 = 0.587 = 587 / 1000; Kb = 0.114 = 144 / 1000; Y' = Kr * R + Kg * G + Kb * B = = (299 / 1000) * (255 / 255) + (587 / 1000) * (203 / 255) + (144 / 1000) * (219 / 255) = = (299 / 1000) + (119161 / 255000) + (1314 / 10625) = = 113471 / 127500 In unsignedint8 is 226.942 > 226 ERROR! In unsignedint9 is 454.773968627451 > 454 ERROR! In unsignedint10 is 910.4379058823529 > 910 ERROR! In unsignedint16 is 58324.094 > 58324 ERROR! In unsignedint24 is 14931195.006 > 14931195 ERROR! In unsignedint32 is 3822386148.478 > 3822386148 ERROR! The only real thing that changes is the level of accuracy.
__________________
github.com 
5th October 2015, 14:17  #36  Link  
Registered User
Join Date: Nov 2014
Posts: 440

Quote:
Before you simplify everything as much as possible then calculate the result. In any case exist quadrupleprecision floatingpoint format (128bits) for those who need a lot of precision.
__________________
github.com 

5th October 2015, 14:26  #37  Link 
I'm Siri
Join Date: Oct 2012
Location: void
Posts: 2,633

I think fractions should really be added as a basic data type like floats, like, a 32bits unsigned fraction would have 16bits as the numerator and other 16bits as the denominator and it would own its own "+  * /"... just like floats

5th October 2015, 14:51  #38  Link  
/人 ◕ ‿‿ ◕ 人\
Join Date: May 2011
Location: Russia
Posts: 643

First,
Quote:
Second, left and right parts of your comparison have different precision. They are different. You have to match precision and adding false precision in hopes that another part has same false precision is obviously not correct. Third, make rounding part of the transform and any transform will be lossless by your own definition. Look at my YCbCrToRGB as an example. It even rounds without using "round" function. Do you know what YCgCo was created for? To be lossless for RGB>YCgCo conversion while using as few bits as possible. Fewer being 2, 1 for each chroma channels. Quote:
Guess what you'll need to do if you want to use YCgCo for what it was designed for. Quote:
If you perform calculations with precision higher* than the precision of your data  then you're not losing any data. There's no point in calculating 10 + 20 with 256bit precision just because you can if you're not even sure if first number is actually 10 or 7 or 13. *That precision could be calculated, and this is the one of the first things you do when you start doing physics lab in school (when you're starting to apply math to the real world). That stuff is actually hard, so it's not surprising that no one bothers with it. Just throw more precision, and hope that it helps. Yes, I'm sure that we're discussing RGB > YCbCr > RGB and not YCbCr <> RGB because there's nothing to discuss about the latter  you said it all. Last edited by vivan; 5th October 2015 at 14:56. 

5th October 2015, 15:05  #39  Link  
I'm Siri
Join Date: Oct 2012
Location: void
Posts: 2,633

Quote:
Quote:
Quote:
you can't round it to a lower precision if "it works at precision 'p1' " and in case you gonna troll around "precision" again like your first and second question lemme do a little correction here if: h (g (new_higher_precision (f (x), p1))) = new_higher_precision (f (x), p1) call it lossless Last edited by feisty2; 5th October 2015 at 15:22. 

5th October 2015, 15:49  #40  Link  
Registered User
Join Date: Dec 2011
Posts: 354

Quote:
EDIT: One thing I can't understand is that what's the point of debating on two things that does exactly same thing? Last edited by bxyhxyh; 5th October 2015 at 16:48. 

Tags 
444, avisynth, color subsampling, x264, yv24 
Thread Tools  Search this Thread 
Display Modes  

