Trying to understand lossless encoding

[Incorrigible]

Hello everyone.

I am hoping someone on this forum can help me understand something.

I Google'd my way to the following page:

https://media.xiph.org/svt/2022/

The pdf on that page talks about how they made the sample videos and one thing surprised me:

The first and in many ways most future proof group of exports in this suite are the archival versions
utilizing the Academy Color Encoding System (ACES). These exports verifiably embody the closest
thing to a mathematically lossless conversion of the captured RAW-data into stored media files

I was also looking through some of the sample encodes they have and noticed that for about 5 seconds of footage their JPEG2000 12-bit lossless encodes where over 60GB.

Clearly the stuff I have been encoding with ut and huffy and ffv1 can't be lossless.

I decided to test it so I downloaded the 185GB y4m version of Tears of Steel and encoded it with 14-bit RGB FFV1 and after calculating PSNR, sure enough, it wasn't infinite for all frames, as one would expect with mathematically lossless.

I did the same with SSIM and that wasn't equal to 1 for all frames either.

This means it's not mathematically lossless.

I figured I would try some other codecs, such as ProRes proxy, MJPEG YUV444 and MPEG4, both full and limited color range:

Tears of Steel Limited.avi
PSNR y:45.733855 u:46.832657 v:47.099598 average:46.106505 min:42.903631 max:53.655666
SSIM Y:0.982232 (17.503609) U:0.983038 (17.705344) V:0.985055 (18.255040) All:0.982837 (17.654041)

Tears of Steel Full.avi
PSNR y:27.467785 u:42.101563 v:42.572047 average:29.158396 min:25.087026 max:34.879856
SSIM Y:0.818023 (7.399823) U:0.983917 (17.936251) V:0.985723 (18.453600) All:0.873622 (8.983272)

Tears of Steel MJPEG Limited
PSNR y:28.857199 u:43.680935 v:43.244515 average:30.543465 min:26.202366 max:36.213328
SSIM Y:0.942936 (12.436368) U:0.987297 (18.960896) V:0.988926 (19.557066) All:0.957994 (13.766933)

Tears of Steel MJPEG Full
PSNR y:45.023105 u:47.162610 v:47.245520 average:45.635849 min:41.415354 max:50.343175
SSIM Y:0.982031 (17.454877) U:0.988912 (19.551313) V:0.990470 (20.209193) All:0.984585 (18.120461)

ToS ProRes Proxy Limited.mov
PSNR y:48.097219 u:49.247396 v:49.344114 average:48.461103 min:43.643947 max:53.187278
SSIM Y:0.989858 (19.938616) U:0.990854 (20.387573) V:0.991952 (20.943136) All:0.990373 (20.164970)

ToS ProRes Proxy Full.mov
PSNR y:27.601424 u:42.199640 v:43.176727 average:29.295123 min:25.126152 max:34.963441
SSIM Y:0.835177 (7.829823) U:0.990750 (20.338760) V:0.991789 (20.856299) All:0.887208 (9.477217)

I am trying to understand why lossless like ffv1. huffy and ut are not capable of really lossless encodes and why with these lossy codecs in some cases a limited color range produced higher values and in some cases full color range produced higher values.

Does anyone understand this?

[LigH.de]

I guess the key phrase may be:

12 bit (as in 12 bit log, read as 16 bit linear)

Lossless encoding of 16 bit value ranges is a pretty hard job. Must be the reason why this JPEG2000 uses a maximum of 12 bit precision sliding over the 16 bit range (logarithmic interpretation).

[poisondeathray]

Clearly the stuff I have been encoding with ut and huffy and ffv1 can't be lossless.

They can be lossless if done correctly

It depends on the pixel format of the source and encode

I decided to test it so I downloaded the 185GB y4m version of Tears of Steel and encoded it with 14-bit RGB FFV1 and after calculating PSNR, sure enough, it wasn't infinite for all frames, as one would expect with mathematically lossless.

Integer RGB encoding, from a Y4M source is not lossless because of that RGB conversion step

I am trying to understand why lossless like ffv1. huffy and ut are not capable of really lossless encodes

Yes they are, if done correctly, with the correct pixel format

The conversions in between that you or the codec are performing are introducing lossy steps

[betwixt]

I read this argument as "If I take a 100K file and zip it, the resulting file is only 50K long, so it can't be lossless". It is clearly wrong to assume the file size is related to the recoverable quality of the video. There are lossless video compressors just as there are lossless data file compressors, when in storage it is irrelevant what the contents are.

Think of it this way: if a screen requires say 2Mb to store all of its pixels and all the pixels were different you would have to use every storage location to hold those different values, now consider what would happen if all the screen was black (or any other uniform color). Without compression you would still need all the 2Mb of storage but all the locations would hold the same value, compressed the file may contain an instruction "use this value but repeat it for all the pixels in the picture". Now the size is reduced because all it needs to hold is the color information itself and the number of times it is to be repeated, maybe 20 bytes in total. It would still be lossless, the result of the 2Mb and the 20 byte would show identical images when played back.

Of course compression like that (=MJPEG) is rarely used because it is still relatively inefficient but the principle is still used. Pixel areas can still be stored singly with a 'number of times to repeat' to save space and the addition of temporal compression gives even better size saving. MPG and its variants not only look for repeated pixels along scan lines, they look for changes frame by frame, relying on the basic fact that scenes rarely last for only one frame. This is why large amounts of silicon memory is needed and why there is a time delay encoding and decoding mpeg formats, they need to store a 'backlog' of frames to see where changes have occurred and to space replicate them in future frames for playback. Lossy algorithms also use perceptive modelling to hide minor changes that are probably un-noticeable of course and that is where the different variations of lossy encoding come into play, each with their own pros and cons.

Brian.

[Incorrigible]

I read this argument as "If I take a 100K file and zip it, the resulting file is only 50K long, so it can't be lossless".

Not even close to what I said, I was very clear, I encoded using a supposedly lossless codec and checked the results using PSNR and SSIM and found that the results were not actually lossless.

@poisondeathray - Thank you, I think I understand my mistake regarding lossless, just to be clear, if the source is YUV422 and I want lossless then the pixel format of ut/huffy/ffv1 needs to also be set to YUV422, if it's anything else then can't be mathematically lossless, correct?

Does it matter if it's mathematically lossless or not for color grading?

If I want to convert the Meridian 12-bit RGB HDR variant to mathematically lossless using ffmpeg, how would I do it?

Any idea why some of the test encodes I posted the PSNR/SSIM results fir above give higher values for Limited range vs Full range with some codecs and the opposite for others?

Thanks to everyone for their replies.