Enconding in 444 YV24 from RGB source Avisynth.

[bxyhxyh]

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?

[feisty2]

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"

[pandy]

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.

[feisty2]

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

[bxyhxyh]

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.

[feisty2]

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

[vivan]

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".

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.

[feisty2]

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)

[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?

[vivan]

Originally Posted by feisty2

simple, lossless without further rounding/truncating (no lsb/error will be generated)

This is not a definition.

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.

[feisty2]

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)

[Khanattila]

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.

[feisty2]

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

[Khanattila]

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.

[pandy]

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

[Khanattila]

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.

[feisty2]

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

[vivan]

First,

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.

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.

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.

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.

[feisty2]

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

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

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

[bxyhxyh]

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?