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.

 Doom9's Forum Enconding in 444 YV24 from RGB source Avisynth.
 Register FAQ Calendar Search Today's Posts Mark Forums Read

 5th October 2015, 09:20 #21  |  Link bxyhxyh Registered User   Join Date: Dec 2011 Posts: 349 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 09:50. Reason: typo
5th October 2015, 11:13   #22  |  Link
feisty2
I'm Siri

Join Date: Oct 2012
Location: Los Angeles, California
Posts: 2,134
Quote:
 Originally Posted by bxyhxyh But I ask again, on this thread and real life practice videos, is that really matters?
actually no, like, 99% of the video filters are lossy, and yet all of us are still using them, all these posts happened cuz the OP directly asked for "lossless"
__________________
If I got new ideas, will post here: https://github.com/IFeelBloated

5th October 2015, 11:36   #23  |  Link
pandy
Registered User

Join Date: Mar 2006
Posts: 1,044
Quote:
 Originally Posted by Motenai Yoda Yet but it's lossless like, as float precision is enough to get same values for 8bit RGB -> (16bit RGB) -> >9bit YUV -> (16bit RGB) -> 8bit RGB. as IIRC you need about 9.6bit YUV to have all 8bit RGB values, ergo 10 or more bit.
Nope - try to represent common case No Y value (Y=0) and chroma (Cb, Cr) value - such color can't be represented in RGB space at all (unless you accept "negative light").
Why those signals are common in YCbCr world? - they are used to measure video circuits.

 5th October 2015, 11:38 #24  |  Link feisty2 I'm Siri     Join Date: Oct 2012 Location: Los Angeles, California Posts: 2,134 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 __________________ If I got new ideas, will post here: https://github.com/IFeelBloated
5th October 2015, 11:38   #25  |  Link
bxyhxyh
Registered User

Join Date: Dec 2011
Posts: 349
Quote:
 Originally Posted by feisty2 all these posts happened cuz the OP directly asked for "lossless"
Then I'll go into this discussion with one more post.

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 11:44.

 5th October 2015, 12:04 #26  |  Link feisty2 I'm Siri     Join Date: Oct 2012 Location: Los Angeles, California Posts: 2,134 think it as YCgCo has a strong and useful lossless nature YCbCr has a weaker and not so useful lossless nature punch line: YCbCr was never designed to be lossless like YCgCo __________________ If I got new ideas, will post here: https://github.com/IFeelBloated
5th October 2015, 12:08   #27  |  Link
vivan
/人 ◕ ‿‿ ◕ 人\

Join Date: May 2011
Location: Russia
Posts: 649
Quote:
 Originally Posted by bxyhxyh You guys are defining "lossless" in your own ways. Yours is of course true. But Vivan's is also true.
He never told his definition of a lossless transform. Basically it is "lossless transform is not a lossless transform if I don't like it".

Quote:
 Originally Posted by pandy Nope - try to represent common case No Y value (Y=0) and chroma (Cb, Cr) value - such color can't be represented in RGB space at all (unless you accept "negative light").
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, 12:23   #28  |  Link
feisty2
I'm Siri

Join Date: Oct 2012
Location: Los Angeles, California
Posts: 2,134
Quote:
 Originally Posted by vivan He never told his definition of a lossless transform. Basically it is "lossless transform is not a lossless transform if I don't like it".
simple, lossless without further rounding/truncating (no lsb/error will be generated)

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)
__________________
If I got new ideas, will post here: https://github.com/IFeelBloated

 5th October 2015, 12:42 #29  |  Link foxyshadis ангел смерти     Join Date: Nov 2004 Location: Lost Posts: 9,420 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? __________________ There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order.
5th October 2015, 12:50   #30  |  Link
vivan
/人 ◕ ‿‿ ◕ 人\

Join Date: May 2011
Location: Russia
Posts: 649
Quote:
 Originally Posted by feisty2 simple, lossless without further rounding/truncating (no lsb/error will be generated)
This is not a definition.

Quote:
 Originally Posted by foxyshadis 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?
He never confirmed that this is actually what happens.
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, 13:09   #31  |  Link
feisty2
I'm Siri

Join Date: Oct 2012
Location: Los Angeles, California
Posts: 2,134
Quote:
 Originally Posted by vivan This is not a definition.
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)
__________________
If I got new ideas, will post here: https://github.com/IFeelBloated

Last edited by feisty2; 5th October 2015 at 13:16.

 5th October 2015, 13:12 #32  |  Link Khanattila Registered User     Join Date: Nov 2014 Posts: 432 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 floating-point 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 (384-bit for pixel) it's useless. __________________ github.com
5th October 2015, 15:08   #33  |  Link
feisty2
I'm Siri

Join Date: Oct 2012
Location: Los Angeles, California
Posts: 2,134
Quote:
 Originally Posted by Khanattila In programs of mathematical calculation all the floating-point 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 (384-bit for pixel) it's useless.
just out of curiosity, computer was initially designed and made to do scientific calculations decades ago, something more like what we call "calculator" nowadays
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
__________________
If I got new ideas, will post here: https://github.com/IFeelBloated

 5th October 2015, 15:10 #34  |  Link Khanattila Registered User     Join Date: Nov 2014 Posts: 432 Example, Pink colour sRGB(255, 203, 219). In unsigned-normalized is (255 / 255, 203 / 255, 219 / 255). Convert to Y'PbPr (ITU-R 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 unsigned-int8 is 226.942 --> 226 ERROR! In unsigned-int9 is 454.773968627451 --> 454 ERROR! In unsigned-int10 is 910.4379058823529 --> 910 ERROR! In unsigned-int16 is 58324.094 -> 58324 ERROR! In unsigned-int24 is 14931195.006 --> 14931195 ERROR! In unsigned-int32 is 3822386148.478 --> 3822386148 ERROR! The only real thing that changes is the level of accuracy. __________________ github.com
5th October 2015, 15:17   #35  |  Link
pandy
Registered User

Join Date: Mar 2006
Posts: 1,044
Quote:
 Originally Posted by vivan 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.
Are You sure? - YCbCr <--> RGB for me is something else than RGB --> YCbCr --> RGB

5th October 2015, 15:17   #36  |  Link
Khanattila
Registered User

Join Date: Nov 2014
Posts: 432
Quote:
 Originally Posted by feisty2 just out of curiosity, computer was initially designed and made to do scientific calculations decades ago, something more like what we call "calculator" nowadays 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
Because they use letters instead of numbers.
Before you simplify everything as much as possible then calculate the result.

In any case exist quadruple-precision floating-point format (128-bits) for those who need a lot of precision.
__________________
github.com

5th October 2015, 15:26   #37  |  Link
feisty2
I'm Siri

Join Date: Oct 2012
Location: Los Angeles, California
Posts: 2,134
Quote:
 Originally Posted by Khanattila Because they use letters instead of numbers. Before you simplify everything as much as possible then calculate the result. In any case exist quadruple-precision floating-point format (128-bits) for those who need a lot of precision.
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
__________________
If I got new ideas, will post here: https://github.com/IFeelBloated

5th October 2015, 15:51   #38  |  Link
vivan
/人 ◕ ‿‿ ◕ 人\

Join Date: May 2011
Location: Russia
Posts: 649
First,
Quote:
 5. the reverse process of g (x) is called h (x), and it works at precision "p1" as well
And why is the reverse process instead of returning original value adds something to it?
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:
 It is possible to losslessly transform from RGB to YCoCg when using 2 more bits for YCoCg representation than for RGB. E.g., it is possible to losslessly transform a pixel from a 30-bit RGB frame into a pixel in a 32-bit YCoCg 4:4:4 frame and back. This assumes that each R, G, and B component will have 10 bits of information which Y will have 10 bits and Co and Cg will each have 11 bits.
Now if you look at the conversion itself you'll see halves and even quarters. In luma, even. And in inverse transform chroma is part of the calculations, while having higher precision.
Guess what you'll need to do if you want to use YCgCo for what it was designed for.

Quote:
 Originally Posted by Khanattila The computer has a finite precision, thus it introduces errors. The only thing you can do is to make this error negligible as possible.
Input data also has limited precision.
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 256-bit 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.

Quote:
 Originally Posted by pandy Are You sure? - YCbCr <--> RGB for me is something else than RGB --> YCbCr --> RGB
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 15:56.

5th October 2015, 16:05   #39  |  Link
feisty2
I'm Siri

Join Date: Oct 2012
Location: Los Angeles, California
Posts: 2,134
Quote:
 And why is the reverse process instead of returning original value adds something to it?
0.123000 = 0.123, so it's nothing, don't tell me 0.123000 != 0.123, and back to the point, h (x) is the reverse function to g (x), and g (x) has a precision of p1 not p0, you tell me why

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.
0.123000... (you can have as many "0"s as you like, even infinite 0s) = 0.123 mathematically, end of the story

Quote:
 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.
"5. the reverse process of g (x) is called h (x), and it works at precision "p1" as well"
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
__________________
If I got new ideas, will post here: https://github.com/IFeelBloated

Last edited by feisty2; 5th October 2015 at 16:22.

5th October 2015, 16:49   #40  |  Link
bxyhxyh
Registered User

Join Date: Dec 2011
Posts: 349
Quote:
 Originally Posted by feisty2 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
Don't computers already work this way?

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 17:48.

 Tags 444, avisynth, color subsampling, x264, yv24