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.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 5th October 2015, 08:20   #21  |  Link
bxyhxyh
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
bxyhxyh is offline   Reply With Quote
Old 5th October 2015, 10:13   #22  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
Quote:
Originally Posted by bxyhxyh View Post
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"
feisty2 is offline   Reply With Quote
Old 5th October 2015, 10:36   #23  |  Link
pandy
Registered User
 
Join Date: Mar 2006
Posts: 1,049
Quote:
Originally Posted by Motenai Yoda View Post
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.
pandy is offline   Reply With Quote
Old 5th October 2015, 10:38   #24  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
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
feisty2 is offline   Reply With Quote
Old 5th October 2015, 10:38   #25  |  Link
bxyhxyh
Registered User
 
Join Date: Dec 2011
Posts: 354
Quote:
Originally Posted by feisty2 View Post
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 10:44.
bxyhxyh is offline   Reply With Quote
Old 5th October 2015, 11:04   #26  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
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
feisty2 is offline   Reply With Quote
Old 5th October 2015, 11:08   #27  |  Link
vivan
/人 ◕ ‿‿ ◕ 人\
 
Join Date: May 2011
Location: Russia
Posts: 643
Quote:
Originally Posted by bxyhxyh View Post
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 View Post
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.
vivan is offline   Reply With Quote
Old 5th October 2015, 11:23   #28  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
Quote:
Originally Posted by vivan View Post
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)
feisty2 is offline   Reply With Quote
Old 5th October 2015, 11:42   #29  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
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?
foxyshadis is offline   Reply With Quote
Old 5th October 2015, 11:50   #30  |  Link
vivan
/人 ◕ ‿‿ ◕ 人\
 
Join Date: May 2011
Location: Russia
Posts: 643
Quote:
Originally Posted by feisty2 View Post
simple, lossless without further rounding/truncating (no lsb/error will be generated)
This is not a definition.

Quote:
Originally Posted by foxyshadis View Post
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.
vivan is offline   Reply With Quote
Old 5th October 2015, 12:09   #31  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
Quote:
Originally Posted by vivan View Post
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)

Last edited by feisty2; 5th October 2015 at 12:16.
feisty2 is offline   Reply With Quote
Old 5th October 2015, 12:12   #32  |  Link
Khanattila
Registered User
 
Khanattila's Avatar
 
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 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
Khanattila is offline   Reply With Quote
Old 5th October 2015, 14:08   #33  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
Quote:
Originally Posted by Khanattila View Post

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
feisty2 is offline   Reply With Quote
Old 5th October 2015, 14:10   #34  |  Link
Khanattila
Registered User
 
Khanattila's Avatar
 
Join Date: Nov 2014
Posts: 440
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
Khanattila is offline   Reply With Quote
Old 5th October 2015, 14:17   #35  |  Link
pandy
Registered User
 
Join Date: Mar 2006
Posts: 1,049
Quote:
Originally Posted by vivan View Post
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
pandy is offline   Reply With Quote
Old 5th October 2015, 14:17   #36  |  Link
Khanattila
Registered User
 
Khanattila's Avatar
 
Join Date: Nov 2014
Posts: 440
Quote:
Originally Posted by feisty2 View Post
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
Khanattila is offline   Reply With Quote
Old 5th October 2015, 14:26   #37  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
Quote:
Originally Posted by Khanattila View Post
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
feisty2 is offline   Reply With Quote
Old 5th October 2015, 14:51   #38  |  Link
vivan
/人 ◕ ‿‿ ◕ 人\
 
Join Date: May 2011
Location: Russia
Posts: 643
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 View Post
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 View Post
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 14:56.
vivan is offline   Reply With Quote
Old 5th October 2015, 15:05   #39  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
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

Last edited by feisty2; 5th October 2015 at 15:22.
feisty2 is offline   Reply With Quote
Old 5th October 2015, 15:49   #40  |  Link
bxyhxyh
Registered User
 
Join Date: Dec 2011
Posts: 354
Quote:
Originally Posted by feisty2 View Post
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 16:48.
bxyhxyh is offline   Reply With Quote
Reply

Tags
444, avisynth, color subsampling, x264, yv24

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 00:51.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.