Enconding in 444 YV24 from RGB source Avisynth.

[sephirotic]

I color graded a m2ts episode from a BD I own on Premiere CS6. Only truly lossless export Option I had was mov with animation codec (RLE).
Now, I wanted to convert to a lossless x264 file (qp0 preset slow) with 4:4:4 subsampling.

I'm truly lost as how to effectively generate a qp0 x264 file with the less possible loss in color acurancy. I understand that a 100% lossless RGB->YV24 conversion isn't possible, but all the attempts I made so far seem to give me a file that was converted to 4:2:0 at some point.

Initially I tried inputing the file directly on x264.exe CLI, but I didn't figure out how to make the mov file acceptable by x264 (and even if it is). --input-fmt uses lav filter, right? Should it be configured as default spliter on windows for this parameter to work? My default filter is ffdshow.
Then I heard Avisynt version 2.60 now accepts YV24 output format, but I'm not sure, the regular version do or just some beta build?
Anyway, I just added ConvertToYV24 on avs script and encoded with megui with the following settings:

program --preset slower --qp 0 --b-pyramid none --no-weightb --qpmax 51 --merange 24 --psy-rd 0.00:0 --no-dct-decimate --no-fast-pskip --output-csp i444 --output "output" "input"

I manually added the output-csp i444 line. This generated me a true 444 output file but the colors seems just like 420. I suspect avisynth is indeed outputting 420.

I further tought about exporting a TIF image sequence from Premiere and trying to feed it into x264.exe directly but I have no idea how to do that.

After a lot of reading around Doom's9 and other websites, I also saw people saying that I should specify the input color space for encoding on x264. Original m2ts was Rec.709 limited range, the RGB conversion on Premiere seemed to be fully lossless as the output mov files looks identical to the original 4:2:0 m2ts file. So should I just specify Rec 709 anyway?

I'm not even sure this should be in the avisynth section or x264 section.
Thanks a lot.

[feisty2]

"I understand that a 100% lossless RGB->YV24 conversion isn't possible"
nah nah nah, see "YCgCo (http://en.wikipedia.org/wiki/YCgCo)"

--output-csp i444 --input-csp i444 --profile high444

[sephirotic]

"I understand that a 100% lossless RGB->YV24 conversion isn't possible"
nah nah nah, see "YCgCo (http://en.wikipedia.org/wiki/YCgCo)"

--output-csp i444 --input-csp i444 --profile high444

I have researched about YCgCo and it seems that it is only compatible with Madvr, with is not good enough for me.

I discovered why Avisynth wasn't converting properly, even tough the input was RGB, I still should have specified the matrix: ConvertToYV24 (matrix="rec709")
By just adding the parameter I managed to get 100% lossless result.
Thanks for the quick reply, tough.

[feisty2]

By just adding the parameter I managed to get 100% lossless result.
YCbCr (601, 709, 2020..) <---> RGB IS NOT mathematically lossless under finite precision

[vivan]

sephirotic,
Color being different is a different issue.
For RGB->YCbCr conversion x264 uses BT.601 matrix, which is wrong for HD video.
By default avisynth's ConvertTo uses it too, but it can and should be specified ("Rec709" is the correct one if you want tv-range video).

Do you really need 4:4:4 YCbCr? x264 supports RGB encoding which is a bit less effective but way more convenient (and is actually lossless).

nah nah nah, see "YCgCo (http://en.wikipedia.org/wiki/YCgCo)"Don't forget to add that it also requires 9 bit precision for chroma to be lossless. Which means 10 bit encoder, Dither tools and 16 bit output from avisynth.

YCbCr (601, 709, 2020..) <---> RGB IS NOT mathematically lossless under finite precisionOf course it's lossless, under higher but still finite precision.

[Jamaika]

I color graded a m2ts episode from a BD I own on Premiere CS6. Only truly lossless export Option I had was mov with animation codec (RLE).
Now, I wanted to convert to a lossless x264 file (qp0 preset slow) with 4:4:4 subsampling.
At the very beginning you need to be aware that m2ts input material was compressed YUV BT709, that you have lost some information.
Then you added effects and wanted to make the movie lossless at x264.
I further tought about exporting a TIF image sequence from Premiere and trying to feed it into x264.exe directly but I have no idea how to do that.
I don't know what you created TIFF images MOV. You can download a free plugin VP9 (sRGB, i444 undef).
Chroma sampling 4:4:4 (YUV i444) will be converted to 8bit sRGB monitor. ):
BT2020 is for depth 10bit files and currently isn't recognized by most programs only TV.
sRGB isn't recognized by most programs.

[feisty2]

Of course it's lossless, under higher but still finite precision.

http://i.imgur.com/3giU9VX.png

there's something called "Infinite decimal", which is a mathematic concept even known to kids from elementary school.
and iirc, floats can do "finite decimals", not fractions
edit: typo

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

[feisty2]

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.

the YCbCr -- RGB stuff will make infinite decimals, and the infinite decimal gets truncated to some finite decimal and then converted to an even lower precision and BY CHANCE it's "lossless" at such low precision, that's not "mathematically" lossless, that's coincidence
and YCgCo is free from all this at the mathematic level, no infinite decimal will be produced long as the input is not infinite decimal, and that's "mathematically" lossless

[vivan]

there's something called "Infinite decimal", which is a mathematic concept even known to kids from elementary school.
and iirc, floats can do "finite decimals", not fractions
edit: typothere's also something called "precision". I know, they don't teach it to kids so it's totally ok not to know about it.

the YCbCr -- RGB stuff will make infinite decimals, and the infinite decimal gets truncated to some finite decimal and then converted to an even lower precision and BY CHANCE it's "lossless" at such low precision, that's not "mathematically" lossless, that's coincidenceYeah, sure, 100% chance is really just a coincidence.

void RGBtoYCbCr (unsigned char* RGB, unsigned short* YCbCr) {
YCbCr[0] = (unsigned short)(( 16.0 + 0.257 * RGB[0] + 0.504 * RGB[1] + 0.098 * RGB[2]) * 257.0 + 0.5);
YCbCr[1] = (unsigned short)((128.0 - 0.148 * RGB[0] - 0.291 * RGB[1] + 0.439 * RGB[2]) * 257.0 + 0.5);
YCbCr[2] = (unsigned short)((128.0 + 0.439 * RGB[0] - 0.368 * RGB[1] - 0.071 * RGB[2]) * 257.0 + 0.5);
}

void YCbCrToRGB (unsigned short* _YCbCr, unsigned char* RGB) {
double YCbCr[3] = {_YCbCr[0] / 257.0 - 16.0, _YCbCr[1] / 257.0 - 128.0, _YCbCr[2] / 257.0 - 128.0};
RGB[0] = (unsigned char)(1.164 * YCbCr[0] + 0.000 * YCbCr[1] + 1.596 * YCbCr[2] + 0.5);
RGB[1] = (unsigned char)(1.164 * YCbCr[0] - 0.392 * YCbCr[1] - 0.813 * YCbCr[2] + 0.5);
RGB[2] = (unsigned char)(1.164 * YCbCr[0] + 2.017 * YCbCr[1] + 0.000 * YCbCr[2] + 0.5);
}

int _tmain(int argc, _TCHAR* argv[]) {
for (int R = 0; R < 256; R++)
for (int G = 0; G < 256; G++)
for (int B = 0; B < 256; B++) {
unsigned char RGB[3] = {R, G, B};
unsigned char newRGB[3];
unsigned short YCbCr[3];
RGBtoYCbCr (RGB, YCbCr);
YCbCrToRGB (YCbCr, newRGB);
if (newRGB[0] != RGB[0] || newRGB[1] != RGB[1] || newRGB[2] != RGB[2]) {
printf ("%i %i %i %i %i %i\n", newRGB[0], RGB[0], newRGB[1], RGB[1], newRGB[2], RGB[2]);
}
}

return 0;
}Run it and tell me what you see (or, more precisely, don't).

[feisty2]

yeah, yeah
something is only lossless when you manually clip the extra imprecise "lsb" part (aka. error part) off, right, 0.123456 = 0.123000 when you zero the "456" lsb out and that is just mathematically lossless??
back to the point, it's lossless cuz you were rounding a short to a char, which almost never ever happens in the wild, cuz you know what? people will dither a short to a char, and boom, the lossless magic is gone with dithering, so you gonna tell everyone, just rounding 16bits YUV to 8bits RGB, don't dither? and I highly doubt if anyone will ever follow that advice
and YCgCo is ALWAYS lossless, dithering or truncating or rounding, cuz you know what, it's mathematically lossless (it has no lsb (no error), so nothing to dither)

[feisty2]

and don't even bother to write c programs to test all these
dither package + mt_makediff + mt_lut (diff, "x 128 - 20 * 128 +") are everything you need

[sephirotic]

sephirotic,
By default avisynth's ConvertTo uses it too, but it can and should be specified ("Rec709" is the correct one if you want tv-range video).

yest, that is what I've done after further digging.


Do you really need 4:4:4 YCbCr? x264 supports RGB encoding which is a bit less effective but way more convenient (and is actually lossless).

I've done a second encode with x264 rgb for keeping the master, I only needed YCBCR for the final 10 bit encode.

At the very beginning you need to be aware that m2ts input material was compressed YUV BT709, that you have lost some information.
Then you added effects and wanted to make the movie lossless at x264.

Well, Premiere interpreted the color matrix correctly so lost information was minimal.


I don't know what you created TIFF images MOV. You can download a free plugin VP9 (sRGB, i444 undef).
Chroma sampling 4:4:4 (YUV i444) will be converted to 8bit sRGB monitor. ):
BT2020 is for depth 10bit files and currently isn't recognized by most programs only TV.
sRGB isn't recognized by most programs.

sRGB would be interesting for the master, but then again, premiere doesn't export it Afaik so taht would only add another conversion and more rounding losses in the process.

Thanks for all the help, I was able to attain virtually imperceivable loss in color information just by using ConverTToYV24 (matrix="rec709")

Here a sample to anyone curious.
http://diff.pics/ssFVuuBc4Agi/1
Lossless in this case is qp0 veryslow no bframes x264 yv24 encode, but I'm in the middle of doing a RGB x264 encode right now as a V2.

[vivan]

yeah, yeah
something is only lossless when you manually clip the extra imprecise "lsb" part (aka. error part) off, right, 0.123456 = 0.123000 when you zero the "456" lsb out and that is just mathematically lossless??First, you should learn the definition of lossless. Lossless transform is a transform that can be reversed so that you will get original data. And no, "can" is not about probability - it's about conditions, which is higher precision.

Second, you should really learn something about precision. 0.123 and 0.123000 have different meaning - second implies much greater precision. What original "0.123" actually means is that value lies in the +- 0.0005 range. And this is how you're supposed to compare numbers.

I've done a second encode with x264 rgb for keeping the master, I only needed YCBCR for the final 10 bit encode.But can't you encode from your x264 rgb master?

[feisty2]

I don't wanna waste my time on this pointless argument no more

colorbars (pixel_type="rgb32")

ycgco = dither_convert_rgb_to_yuv (output="yv24",lsb=true,matrix="ycgco",tv_range=false)
ycbcr = dither_convert_rgb_to_yuv (output="yv24",lsb=true,matrix="601",tv_range=false)

rgb48ycgco = dither_convert_yuv_to_rgb (ycgco, output="rgb48y",matrix="ycgco",tv_range=false,lsb_in=true)
rgb48ycbcr = dither_convert_yuv_to_rgb (ycbcr, output="rgb48y",matrix="601",tv_range=false,lsb_in=true)

rgb48cgco = mergergb (rgb48ycgco.selectevery (3,0), rgb48ycgco.selectevery (3,1), rgb48ycgco.selectevery (3,2)).subtitle ("ycgco")
rgb48cbcr = mergergb (rgb48ycbcr.selectevery (3,0), rgb48ycbcr.selectevery (3,1), rgb48ycbcr.selectevery (3,2)).subtitle ("ycbcr")

StackHorizontal(rgb48cgco,rgb48cbcr)


http://i.imgur.com/j4I5D5b.png

just stare at the LSB part of "ycgco" and "ycbcr" real carefully and tell me what's the difference, which one is "lossless"

[feisty2]

0.123000 (ycgco) = 0.123 is lossless, cuz 0.123000=0.123 mathematically
0.123456 (ycbcr) ≈ 0.123 is NOT lossless, ≈ is still some kind of != obviously

[colours]

It's vaguely ironic to see feisty2 post about "mathematical precision" and using Dither tools to illustrate that, when Dither tools has off-by-one errors scattered throughout the full-range colour conversion functions.

Also, good job missing vivan's point. How surprising it is that you find the argument "pointless" when you just ignore what everyone else says.

[feisty2]

It's vaguely ironic to see feisty2 post about "mathematical precision" and using Dither tools to illustrate that, when Dither tools has off-by-one errors scattered throughout the full-range colour conversion functions.

there's no such thing as infinite precision for computers, I don't see any other better option to do it, anyways, I'll explain what I was saying with the following

Also, good job missing vivan's point. How surprising it is that you find the argument "pointless" when you just ignore what everyone else says.

I get that stuff vivan or you stated

suppose:
1. there was infinite precision for computers
2. all rgb-yuv444-rgb stuff was done correctly under infinite precision
3. the input value was 0.123

the output value of both "ycgco" and "ycbcr" should be 0.123000000... or 0.1229999999... both are mathematically equal to 0.123, the input value
perfect, end of the story

now the reality is, there's no infinite precision, only higher but still finite precision

say, the higher precision here is "6 significant figures"
the output of ycgco would be like, 0.123000, still mathematically equals to 0.123, cuz there're only things like /2 and /4 inside ycgco stuff, and they won't produce infinite decimals long as the input is not infinite precision

the ycbcr output might be like 0.123456, which != 0.123, cuz obviously ycbcr requires infinite precision for intermediate values to stay the zero error status, some intermediate value gets truncated to 6 significant figures and that leads to the error presented in the output value

the disagreement starts right from here

you and vivan think 0.123456 will become 0.123 if rounded down to 3-significant-figure precision and will =0.123 again so it's lossless

and I think it's cheating, the mathematically lossless method should have an output like ycgco, lossless without rounding

[Rumbah]

Well, I'd define lossless like this in this case:

I have an image in space A.
I have a transformation f from space A to space B.
I have a transformation g from space B to space A.

If for every pixel x in A: x = g(f(x)) is true then the transformation is lossless.

It does not matter if there is rounding or definite presicion involved as long as every starting pixel has the same value as a transformed and back tranformed pixel.

With this you see that the Dither color space tranformations are not lossless (because of dithering they can be off by +-1).

But indeed you can do a lossless RGB8 to YCbCr10 to RGB8 transformation as vivan has shown.

[feisty2]

Well, I'd define lossless like this in this case:

I have an image in space A.
I have a transformation f from space A to space B.
I have a transformation g from space B to space A.

If for every pixel x in A: x = g(f(x)) is true then the transformation is lossless.

It does not matter if there is rounding or definite presicion involved as long as every starting pixel has the same value as a transformed and back tranformed pixel.

With this you see that the Dither color space tranformations are not lossless (because of dithering they can be off by +-1).

But indeed you can do a lossless RGB8 to YCbCr10 to RGB8 transformation as vivan has shown.

and that "lossless" for ycbcr is just useless like flopped celebrities going to reality shows (the voice, ...) trying to regain attention

will you ever "round" or "truncate" a 16bits YUV vid to <= 14bits RGB? guess not

and the losslessness of ycgco will survive thru rounding or truncating or error diffusing, long as no random noise is applied, ycgco takes its crown by being mathematically lossless at finite precision

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

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]

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]

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]

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

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]

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]

simple, lossless without further rounding/truncating (no lsb/error will be generated)This is not a definition.

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]

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]

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]

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]

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]

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 wellAnd why is the reverse process instead of returning original value adds something to it (https://en.wikipedia.org/wiki/False_precision)?
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.

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 (http://www.owlnet.rice.edu/~labgroup/pdf/Error_analysis.htm), 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.

Are You sure? - YCbCr <--> RGB for me is something else than RGB --> YCbCr --> RGBYes, 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]

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?

[feisty2]

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


AND,
errors produced by computers due to finite precision are OBVIOUSLY "Systematic Errors" (these errors are constant, you repeat the calculation like a billion times, and the error stays the same, not something fluctuating)
and the page you linked to showed us some basic stuff of "Estimating Random Errors" (fluctuating as you repeat the experiment)

what's your point

[Khanattila]

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 on the screen?

Floating point numbers you said? Not even close.

[Khanattila]

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.

Agree, but the input can have infinite precision like natural logarithm. Euler's number is not a ratio of integers and it is not a root of any non-zero polynomial with rational coefficients. Like log (param).

EDIT. Forget it... you always think that the input is only 'param'.

[feisty2]

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 on the screen?

the topic has turned academic for a while

[feisty2]

@vivan
you and I have different perceptions of "lossless", I can live with that
but please don't drag physics stuff here, computers do mathematical calculations, not physical experiments

[Asmodian]

Agree, but the input can have infinite precision like natural logarithm. Euler's number is not a ratio of integers and it is not a root of any non-zero polynomial with rational coefficients. Like log (param).

EDIT. Forget it... you always think that the input is only 'param'.

No, in computers it cannot. Computers don't do infinite precision. The input will always have finite precision.

@vivan
you and I have different perceptions of "lossless", I can live with that
but please don't drag physics stuff here, computers do mathematical calculations, not physical experiments

Vivan's point was a mathematical one, not a physical one.

If you can only output integers there is a point where keeping track of extra precision cannot change the result at all. This point depends on the equation(s), of course, but it can be calculated with certainty. In physics/chemistry it is based on the precision of your measurements while in computers it is based on the precision of your input and output.

[feisty2]

I'd just implement the real infinite precision if I had time to be wasted on "precision calculation"
Like, ln (Pi) stays ln (Pi), not 1.144729885849400
And that's the infinite precision
And that's the real deal

[bxyhxyh]

Maybe my previous post which included word "physics" may confused people.
It is my bad for using wrong words and meaning. But that is still valid for mathematics.

Especially for this case if input and output are the same, it means that it IS mathematically lossless.

I'd just implement the real infinite precision if I had time to be wasted on "precision calculation"
Like, ln (Pi) stays ln (Pi), not 1.144729885849400
And that's the infinite precision
And that's the real deal

I think that's not possible for programming level numbers. Well for Pi example, 4*atan(1) can do that. But it will be still limited by bit precision (memory). It can't be irrational number with infinite digit.

Floating point numbers you said? Not even close.
Ah, my memory was mixed then lol. I have some vague memory of that fractal numbers are precised that way. Then it wasn't floating point numbers.

EDIT: TBH, I personally think this thread needs to be locked. Because we're arguing like "this method is more accurate because it calculates correctly" while both results the same. It is just meaningless.

[feisty2]

@bxyhxyh
It's possible
Don't convert Pi to 3.1415926.... just use "Pi" to represent the number
Like what you did in math

[bxyhxyh]

@bxyhxyh
It's possible
Don't convert Pi to 3.1415926.... just use "Pi" to represent the number
Like what you did in math

Well even if you save some math numbers as representations in CPU, memory or whatever place, It will end up being rational numbers, when you use it in REAL calculation.
You can use any kind of trick to make it accurate as possible. But in the end the calculation still will be limited by bits.

Maybe for some cases even precise calculation might end up being more accurate. Who knows.