Lossless encoding with 8-bit RGB source

[Japhsoncross]

I have some 8bit RGB clips, and i want to have lossless h.264 copy of them so i could save some hdd space.
i first start to use RGB x264 lossless encoding, and it's great. but i found only ffdshow decoder can correctly show the picture. other decoder will treat the encoded clip as YCbCr, and make the picture looks strange.
i started to use high bit depth ycbcr lossless encoding with 16bit output avs, but i checked the encoded clip, it's not 100% accurate as the RGB source, when it's been decoded back.

then i wrote a application to see how many bits are required for ycbcr to have 100% accuracy when it's converted back to rgb for all 16.7M colors.

i> 8bit-rgb --> 64bit-ycbcr -truncate-> 8bit-ycbcr --> 64bit-rgb -rounding-> 8bit-rgb
0.975% (163621) of 16.7M colors are accurately preserved.

ii> 8bit-rgb --> 64bit-ycbcr -truncate-> 9bit-ycbcr --> 64bit-rgb -rounding-> 8bit-rgb
7.62% (1278723) of 16.7M colors are accurately preserved.

iii> 8bit-rgb --> 64bit-ycbcr -truncate-> 10bit-ycbcr --> 64bit-rgb -rounding-> 8bit-rgb
54.93% (9215740) of 16.7M colors are accurately preserved.

iv> 8bit-rgb --> 64bit-ycbcr -truncate-> 11bit-ycbcr --> 64bit-rgb -rounding-> 8bit-rgb
100% (16777216) of 16.7M colors are accurately preserved.

i'> 8bit-rgb --> 64bit-ycbcr -rounding-> 8bit-ycbcr --> 64bit-rgb -rounding-> 8bit-rgb
16.29% (2732646) of 16.7M colors are accurately preserved.

ii'> 8bit-rgb --> 64bit-ycbcr -rounding-> 9bit-ycbcr --> 64bit-rgb -rounding-> 8bit-rgb
74.79% (12548418) of 16.7M colors are accurately preserved.

iii'> 8bit-rgb --> 64bit-ycbcr -rounding-> 10bit-ycbcr --> 64bit-rgb -rounding-> 8bit-rgb
100% (16777216) of 16.7M colors are accurately preserved.

iv'> 8bit-rgb --> 64bit-ycbcr -rounding-> 11bit-ycbcr --> 64bit-rgb -rounding-> 8bit-rgb
100% of 16.7M colors are accurately preserved.

the rounding is actually using the information from the lower bit in a different way other than dithering.
i didn't consider dithering is because i want to have an encoded clip 100% the same as the source.

the encoding procedure with x264 is like this:

8bit-rgb -avishynth-> 16bit-ycbcr -dithering-> 10bit-ycbcr -decoder-> 8bit-rgb

then i made a patch to let user choose dithering or rounding.
the decoded rgb data is identical to the source.
i'm not sure if others have better solution or idea about this.

[Japhsoncross]

But... I just forgot to check, the file size grows. It turns out to be a bad idea.

[Biggiesized]

How does your dithering algorithm work? Did you model it after an error-diffusion feedback process?

[zhongpang]

1.avishynth：8bit-rgb->16bit-YV24 -rounding-> 10bit-YV24
2.x264 encode:--input-depth 10 --qp 0 --output-csp i444
3.ffdshow decode:
4.madVR render:don't use dithering

OK,100% accurate as the RGB source

[drmpeg]

Probably not a viable solution, but you may be interested in this paper on YCgCo-R color space.

http://wftp3.itu.int/av-arch/jvt-site/2003_09_SanDiego/JVT-I014.doc

Ron

[natt]

I have some 8bit RGB clips, and i want to have lossless h.264 copy of them so i could save some hdd space.
i first start to use RGB x264 lossless encoding, and it's great. but i found only ffdshow decoder can correctly show the picture. other decoder will treat the encoded clip as YCbCr, and make the picture looks strange.


Then don't use other decoders besides ffdshow. (Aside: lav filters can also display this content correctly).

If the original source is RGB, and exact reconstruction is a requirement, a lossless codec operating directly in RGB space makes the most sense. Sure, it may be possible to do it with YCbCr or YCgCo higher bit depth if you're careful about your transformations; but why add that extra complexity? I think you'll also find that at --qp 0, compressing in the original RGB space will be smaller than in a 10 bit colorspace.

I guess I don't understand your requirements. If rgb h264 is no good because some decoders can't play it, certainly more esoteric solutions will be worse in that respect?