VirtualDub2 Lossless jpgs

[Jay123210599]

Believe it or not, VirtualDub2 can make lossless jpeg files. If you don't believe me, check this out.

[Attachment 76229 - Click to enlarge]

[Attachment 76230 - Click to enlarge]

But there's one problem. As I mentioned before, it is VERY slow when making image sequences. If there a faster way to do this (with smaller file sizes, if possible)?

[poisondeathray]

visually they are close, but it's not lossless . You can zoom in and see differences

You can do a difference or test PSNR to confirm - the jpeg is lossy

For vdub2 , if you have idle/slack resources such as CPU, drive I/O, memory - you can run multiple concurrent instances of vdub2 to process faster

[Jay123210599]

visually they are close, but it's not lossless . You can zoom in and see differences

You can do a difference or test PSNR to confirm - the jpeg is lossy

For vdub2 , if you have idle/slack resources such as CPU, drive I/O, memory - you can run multiple concurrent instances of vdub2 to process faster

How do I do that? Is it possible to do this with ffmpeg?

[poisondeathray]

visually they are close, but it's not lossless . You can zoom in and see differences

You can do a difference or test PSNR to confirm - the jpeg is lossy

For vdub2 , if you have idle/slack resources such as CPU, drive I/O, memory - you can run multiple concurrent instances of vdub2 to process faster

How do I do that? Is it possible to do this with ffmpeg?

If you zoom in you can see the jpeg artifacts pretty easily - you can do that with any image editor.

You can use tabs in avspmod and see the differences more easily by swapping and/or zooming in . I prefer avspmod, because you can check multiple versions of videos and they will all be aligned when move to a different frame

If you're having difficulty seeing the jpeg artifacts and differences , I can post an apng demo of some cropped section zoomed in


For ffmpeg PSNR , "infinity" is lossless . You're getting average:46.184289 . That's fairly high . In the 45-50dB is considered "visually lossless" for most people . If you have to zoom in to see differences - that's a clue that the image quality is quite good

Because your testing against an 8bit RGB png (that is considered your "original" now, not the original YUV video), the jpeg must be converted to the same pixel format, so a format=rgb24 filter must be included in the filter chain . jpeg is stored as YUV (in this case YUV444, unsubsampled, because it's a high quailty jpeg) . The settb stuff is to normalize the timebase if you had used different video containers e.g. MKV vs. MP4 - it's not necessarily for single image formats, but I left it in there for reference

ffmpeg -i 00214.jpeg -i 00214.png -lavfi  "[0:v]format=rgb24,settb=1/AVTB,setpts=PTS-STARTPTS[main];[1:v]settb=1/AVTB,setpts=PTS-STARTPTS[ref];[main][ref]psnr" -f null -

[Parsed_psnr_5 @ 0000002977a5a680] PSNR r:45.891986 g:48.824066 b:44.767135 average:46.184289 min:46.184289 max:46.184289

[jagabo]

visually they are close, but it's not lossless . You can zoom in and see differences

Yes. The difference * 32:


[Attachment 76231 - Click to enlarge]

Identical images would have been a totally flat grey.

[Jay123210599]

visually they are close, but it's not lossless . You can zoom in and see differences

Yes. The difference * 32:


[Attachment 76231 - Click to enlarge]

Identical images would have been a totally flat grey.

I meant making the same visual lossless results with VirtualDub2 using ffmpeg.

[poisondeathray]

I meant making the same visual lossless results with VirtualDub2 using ffmpeg.

The instructions for ffmpeg jpeg were given in the other thread

https://forum.videohelp.com/threads/413075-Smallest-PNG-File-Size-Part-2#post2719900

It won't be exactly the same - The jpeg encoder in ffmpeg is different than vdub2's . ffmpeg jpeg encoder produces smoother results, fewer classical sharp jpeg artifacts - so the filesize will be smaller and the PSNR will tend be higher.

[Parsed_psnr_5 @ 000000d06efeee40] PSNR r:47.120112 g:48.574327 b:46.408351 average:47.277041 min:47.277041 max:47.277041

In this case the average PSNR is >1db higher for the ffmpeg jpeg

Not necessarily "better", because lossy encoding is subjective. PSNR is not very useful for subjective quality measurements. It's really only good for trends and determining whether or not something is lossless

But the vdub jpeg is 2.7x the size of the ffmpeg jpeg @q1. I'd argue the quality is not massively different between them without zooming in, but the filesize difference is significant. The main reason for the filesize difference are the "sharp" jpeg artifacts in the vdub jpeg - sharp edges require more bitrate than smooth


If you're having difficulty seeing the vdub and ffmpeg jpeg artifacts, I can post a demo illustrating them

[Jay123210599]

I meant making the same visual lossless results with VirtualDub2 using ffmpeg.

The instructions for ffmpeg jpeg were given in the other thread

https://forum.videohelp.com/threads/413075-Smallest-PNG-File-Size-Part-2#post2719900

It won't be exactly the same - The jpeg encoder in ffmpeg is different than vdub2's . ffmpeg jpeg encoder produces smoother results, fewer classical sharp jpeg artifacts - so the filesize will be smaller and the PSNR will tend be higher.

[Parsed_psnr_5 @ 000000d06efeee40] PSNR r:47.120112 g:48.574327 b:46.408351 average:47.277041 min:47.277041 max:47.277041

In this case the average PSNR is >1db higher for the ffmpeg jpeg

Not necessarily "better", because lossy encoding is subjective. PSNR is not very useful for subjective quality measurements. It's really only good for trends and determining whether or not something is lossless

But the vdub jpeg is 2.7x the size of the ffmpeg jpeg @q1. I'd argue the quality is not massively different between them without zooming in, but the filesize difference is significant. The main reason for the filesize difference are the "sharp" jpeg artifacts in the vdub jpeg - sharp edges require more bitrate than smooth


If you're having difficulty seeing the vdub and ffmpeg jpeg artifacts, I can post a demo illustrating them

But you can clearly see the difference.

[Attachment 76234 - Click to enlarge]

[Attachment 76235 - Click to enlarge]

[poisondeathray]

That color difference is a wrong color marix error for YUV / RGB. A 709 vs 601 mismamatch. Not a jpeg error

[Jay123210599]

That color difference is a wrong color marix error for YUV / RGB. A 709 vs 601 mismamatch. Not a jpeg error

How do I fix the colors so that it will be visually lossless and match the input video?

[poisondeathray]

That color difference is a wrong color marix error for YUV / RGB. A 709 vs 601 mismamatch. Not a jpeg error

How do I fix the colors so that it will be visually lossless and match the input video?

Is this for ffmpeg jpeg sequence ?

What is the input? Direct video ? If so what format is your video ? mediainfo (view=>text) copy paste back here is sufficient

There are many "gotchas" in ffmpeg land - likely video was flagged 709 . But "jpeg" spec is Rec601 full range .

[_Al_]

jpg vs. png difference:
crop of those two images from the first post (width=64, height=36, left=928, top=544)

[Jay123210599]

That color difference is a wrong color marix error for YUV / RGB. A 709 vs 601 mismamatch. Not a jpeg error

How do I fix the colors so that it will be visually lossless and match the input video?

Is this for ffmpeg jpeg sequence ?

What is the input? Direct video ? If so what format is your video ? mediainfo (view=>text) copy paste back here is sufficient

There are many "gotchas" in ffmpeg land - likely video was flagged 709 . But "jpeg" spec is Rec601 full range .

Yes. Here you go.

[poisondeathray]

Color space : YUV
Chroma subsampling : 4:2:0
Color range : Limited
Matrix coefficients : BT.709

Because input is limited range YUV, 709 , and the desired jpeg pixel format is full range YUV, 601, you must convert the input format to the output format

You could argue that ffmpeg should be doing this automatically, but....

Because your source is 4:2:0, there usually is no reason to use jpeg 4:4:4 - you'd just be upsampling the chroma and increasing the filesize for nothing (if you were using some exotic scaling, perhaps machine learning filters, you might make a case for it)

add this to the commandline . "170m" is analogous for "601" matrix. The actual numerical values are the same

-vf zscale=min=709:m=170m:rin=limited:r=full,format=yuvj420p

[Jay123210599]

Color space : YUV
Chroma subsampling : 4:2:0
Color range : Limited
Matrix coefficients : BT.709

Because input is limited range YUV, 709 , and the desired jpeg pixel format is full range YUV, 601, you must convert the input format to the output format

You could argue that ffmpeg should be doing this automatically, but....

Because your source is 4:2:0, there usually is no reason to use jpeg 4:4:4 - you'd just be upsampling the chroma and increasing the filesize for nothing (if you were using some exotic scaling, perhaps machine learning filters, you might make a case for it)

add this to the commandline . "170m" is analogous for "601" matrix. The actual numerical values are the same

-vf zscale=min=709:m=170m:rin=limited:r=full,format=yuvj420p

For the jpeg sequence?

Edit: It worked!

[Attachment 76240 - Click to enlarge]

[Attachment 76241 - Click to enlarge]

By the way, how do I find stuff like "-vf zscale=min=709:m=170m:rin=limited:r=full,format=yu vj420p" if I need to?

[poisondeathray]

For the jpeg sequence?

Yes, for ffmpeg exporting jpeg sequence for that video specified in mediainfo report in post #13

It should look something like this

ffmpeg -i input.mkv -vf zscale=min=709:m=170m:rin=limited:r=full,format=yuvj420p -qmin 1 -qmax 1 -q:v 1 -start_number 0 output_%06d.jpeg

By the way, how do I find stuff like "-vf zscale=min=709:m=170m:rin=limited:r=full,format=yu vj420p" if I need to?

It's in the documentation , but you actually learn from trying things out, examining the result

https://ffmpeg.org/ffmpeg-filters.html#zscale-1

[Jay123210599]

For the jpeg sequence?

Yes, for ffmpeg exporting jpeg sequence for that video specified in mediainfo report in post #13

It should look something like this

ffmpeg -i input.mkv -vf zscale=min=709:m=170m:rin=limited:r=full,format=yuvj420p -qmin 1 -qmax 1 -q:v 1 -start_number 0 output_%06d.jpeg

Also, what does "-start_number 0", and is it really necessary?

[poisondeathray]

Also, what does "-start_number 0", and is it really necessary?

It starts numbering at 0 instead of 1 for the exported sequence . By convention frame numbering starts at zero in most programs . If you look at vdub2, avidemux, avisynth, vapoursynth, NLE's like premiere pro, vegas, davinci resolve etc... they all start at frame "zero" . Same with mkvmerge (for mkv) - if you look at the timestamp documentation, the first frame is zero, not one.

This is not necessary you can start at "1" if you want. But if you import a sequence that starts at "1" you have to note the deviation between programs or you might be 1 frame off, or it might cause other issues

eg
output_000000.png
output_000001.png
.
.


instead of
output_000001.png
output_000002.png
.
.

[Jay123210599]

Also, what does "-start_number 0", and is it really necessary?

It starts numbering at 0 instead of 1 for the exported sequence . By convention frame numbering starts at zero in most programs . If you look at vdub2, avidemux, NLE's like premiere pro, vegas, davinci resolve etc... they all start at frame "zero" . If you import a sequence that starts at "1" you have to note the deviation between programs or you will be 1 frame off

This is not necessary you can start at "1" if you want

eg
output_000000.png
output_000001.png
.
.

Another thing, where does min=709:m=170m and r=full, as well as 709 and 601 came from? Is the p for progressive, right?

[poisondeathray]

Another thing, where does min=709:m=170m and r=full, as well as 709 and 601 came from?

Yes, I explained it above .

for zscale arguments "min" is matrix in . "m" is matrix out . Since you are going from 709 to 601 (again 170m is analogous)

"rin" is range in , "r" is range out. Limited range to full range

Is the p for progressive, right?

Which "p" ?

"p" in zscale is for primaries out

"p" for ffmpeg pixel format is "planar" , e.g. the "p" in yuvj420p stands for "planar" . The "j" denotes full range. The 420 means 4:2:0 chroma subsampling

[Jay123210599]

Another thing, where does min=709:m=170m and r=full, as well as 709 and 601 came from?

Yes, I explained it above .

for zscale arguments "min" is matrix in . "m" is matrix out . Since you are going from 709 to 601 (again 170m is analogous)

"rin" is range in , "r" is range out. Limited range to full range

Is the p for progressive, right?

Which "p" ?

"p" in zscale is for primaries out

"p" for ffmpeg pixel format is "planar" , e.g. the "p" in yuvj420p stands for "planar" . The "j" denotes full range. The 420 means 4:2:0 chroma subsampling

I get the 709 parts, but how "170m" is analogous for "601" matrix? How do I find the pixel format of my videos? Why is 601 the full range, and what does it mean? What happens if I remove the j?

Also, ffmpeg sets the m and r to be the same as the input, so should I not include them or what?

[poisondeathray]

I get the 709 parts, but how "170m" is analogous for "601" matrix?

It's in the ITU h.265 document Table E.5 Kr=0.299, Kb=0.114 . Functionally the values are the same for SMPTE 170M (2004), Rec. ITU-R BT.601

How do I find the pixel format of my videos?

mediainfo; or ffmpeg -i input.ext will show what ffmpeg "thinks" the matrix/transfer/primaries and pixel format are in the console

Why is 601 the full range, and what does it mean?

601 full range is specified in either the jpeg spec in ITU-T Rec T.81, and/or jpeg file interchange format document. It specifies "
YCbCr CCIR 601-256 levels" - which is 601 full range . Because you are using jpeg, you need to use the correct specs (ideally ffmpeg should have done this automatically)

601 is the matrix. It's part of the information required for YUV<=>RGB conversions . Table E5 in the ITU h.265 document lists some of the commonly used matrices

Full range means 0 to 255 code levels are used (=256 levels) for each channel (YCbCr is the correct name, everyone uses "YUV" as short form). Reference Black to white is 0-255 for each channel. "Limited range" means 16-235 is black to white for Y, 16-240 for CbCr (or UV) for 8bit values. 10bit values for full range would be 0-1023

What happens if I remove the j?

You can try it out and report back what happens

Also, ffmpeg sets the m and r to be the same as the input, so should I not include them or what?

If the default input values are the same as the wanted input, you can leave them out, because they are already what you want

If there are different than the wanted input, then you specify the new value to override what it should be.

It's the same for every ffmpeg parameter - you only have to change values that differ from the default or what is being read

Again, ffmpeg -i input.ext will show what ffmpeg "thinks" the input matrix/transfer/primaries/range and pixel format are in the console

[Jay123210599]

I get the 709 parts, but how "170m" is analogous for "601" matrix?

It's in the ITU h.265 document Table E.5 Kr=0.299, Kb=0.114 . Functionally the values are the same for SMPTE 170M (2004), Rec. ITU-R BT.601

How do I find the pixel format of my videos?

mediainfo; or ffmpeg -i input.ext will show what ffmpeg "thinks" the matrix/transfer/primaries and pixel format are in the console

Why is 601 the full range, and what does it mean?

601 full range is specified in either the jpeg spec in ITU-T Rec T.81, and/or jpeg file interchange format document. It specifies "
YCbCr CCIR 601-256 levels" - which is 601 full range . Because you are using jpeg, you need to use the correct specs (ideally ffmpeg should have done this automatically)

601 is the matrix. It's part of the information required for YUV<=>RGB conversions . Table E5 in the ITU h.265 document lists some of the commonly used matrices

Full range means 0 to 255 code levels are used (=256 levels) for each channel (YCbCr is the correct name, everyone uses "YUV" as short form). Reference Black to white is 0-255 for each channel. "Limited range" means 16-235 is black to white for Y, 16-240 for CbCr (or UV) for 8bit values. 10bit values for full range would be 0-1023

What happens if I remove the j?

You can try it out and report back what happens

Also, ffmpeg sets the m and r to be the same as the input, so should I not include them or what?

If the default input values are the same as the wanted input, you can leave them out, because they are already what you want

If there are different than the wanted input, then you specify the new value to override what it should be.

It's the same for every ffmpeg parameter - you only have to change values that differ from the default or what is being read

Again, ffmpeg -i input.ext will show what ffmpeg "thinks" the input matrix/transfer/primaries/range and pixel format are in the console

Okay, what lossless formats other than avif or heif support YUV (4:2:0, 4:2:2, and 4:4:4)? How do I convert a video into lossless avif files?

[poisondeathray]

Okay, what lossless formats other than avif or heif support YUV (4:2:0, 4:2:2, and 4:4:4)? How do I convert a video into lossless avif files?

TIFF does, but there are potential compatibility issues for YUV variants. Most programs expect RGB TIFF

avif or heif/heic have potential compatibility issues as well, because they are newer .

ffmpeg or libavif (avifenc) can encode avif, just use google for help and examples.
https://github.com/AOMediaCodec/libavif

you can use libheif or some derivative for heif .
https://github.com/strukturag/libheif

There might be some GUI's for those, not sure I don't use them often because of compatibility issues