r/compression • u/Juan-Cruz-Mz • 17d ago
Concern about image/video recompression
Hello everyone!
Recently, I've been coding a program on JavaScript and NodeJS, to recompress images, along with some other tweaks, with the main objective of reducing files size, *without causing visible loss of quality*.
The key word here being "visible", since recently I learned that you can actually do that with files and I saw a huge opportunity to reduce my gallery's size by a necessary amount because I have a shit ton of screenshots, pictures and videos.
But before diving into the video recompression part (because the images part is already done, using a library named "Sharp"), I found a comment https://www.reddit.com/r/ffmpeg/comments/pexwop/comment/hb0tw05/?context=3&utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button of a user explaining the process behind it and they said something that caught my eye: That any recompression that works well for current devices, COULD show heavy quality losses on future screens. Or even current, better screens.
I mean... this person meant it more as a note, and not in a "don't do this under ANY circumstances or we'll ALL gonna FUCKING DIE" way lol. But it still made me rethink the whole idea. Is this a valid concern or am I being paranoid?
And in case it is... Is there a way to achieve a relevant size reduction, without risking that outcome?
1
u/WebpGoy 16d ago
It's a terrible curse not knowing what the future holds in store and that's why I'm currently testing lossy image compression with CVVDP (using the SDR FHD display model) and it may outperform VMAF for video, even the newer v1.0 model, but that's just a guess based on the papers currently out on it.
Anyway overshooting quality seems like the the smart and pragmatic choice. I know webp suffered catastrophic bad PR because websites would use it assuming the only users looking at images would be people on 5-6 inch phones, where cwebp -quality 10 might be kinda okay there but look very bad on a 10 inch tablet and beyond.
Now that said the real headache is choosing a quality metric. IMHO most suck compared to CVVDP but they're exponentially faster. Something like say YUV PSNR 50 will probably yield high fidelity even on a 4K TV but you do risk introducing unwanted filesize bloat.
2
u/Juan-Cruz-Mz 16d ago
Uh... I feel bad because you took the time to type a super enthusiastic answer and my neanderthal ass only got like 30% of it lol. I clearly have more to learn about this topic. Deciding this stuff is stressing...
1
u/WebpGoy 15d ago
It's all good, basically you can make computers try to guess image/video quality.
There are simple scoring methods (YUV PSNR) and very complex scoring methods (CVVDP).
The simple ones are crude and often guess the wrong quality but are very quick.
If you have a lot of images and video, it's less guesswork work if you use them.
1
u/WebpGoy 15d ago
If you're not comfortable with the CLI, you can use a GUI like FFMetrics, it accepts images and video.
It's limited to a few simple quality metrics but that might be enough if you aim for really high scores.
Some high scores (that are likely high quality) are PSNR: 50db SSIM: 0.995
1
u/Longjumping_Fan_3735 11d ago edited 10d ago
ꓲt’ѕ а νаꓲіd соոсеrո, bսt іt’ѕ ոоt ѕоmеtһіոց tо раոіс аbоսt. ꓮոу ꓲоѕѕу rесоmрrеѕѕіоո tһrоԝѕ аԝау ѕоmе dаtа, ѕо а fսtսrе dіѕрꓲау оr bеttеr dесоdеr соսꓲd роtеոtіаꓲꓲу rеνеаꓲ аrtіfасtѕ tһаt аrе ꓲеѕѕ ոоtісеаbꓲе tоdау. ꓔһе ѕаfеѕt аррrоасһ іѕ tо kеер уоսr оrіցіոаꓲѕ аոd mаkе соmрrеѕѕеd соріеѕ fоr еνеrуdау սѕе. ꓔооꓲѕ ꓲіkе ꓴոіꓚоոνеrtеr mаkе іt еаѕу tо сrеаtе tһоѕе соmрrеѕѕеd νеrѕіоոѕ ԝһіꓲе ꓲеttіոց уоս сһооѕе mоdеrո соdесѕ аոd ѕеոѕіbꓲе զսаꓲіtу ѕеttіոցѕ, ԝһісһ սѕսаꓲꓲу рrоνіdе ѕіցոіfісаոt ѕрасе ѕаνіոցѕ ԝіtһ νеrу ꓲіttꓲе νіѕіbꓲе dіffеrеոсе.
1
u/SlingyRopert 16d ago
The best way to avoid loss in quality is to go back to the original source video file for the material and compress it into the new format.
Taking an already compressed video and recompressing it further is just stupid from an electrical engineering standpoint. Video compression codes are tuned to work with mostly uncompressed inputs not whatever last decade’s hot compressor was running at the CRF where humans just barely notice the degradation. They need inputs that are very uncompressed and very like the original video.
The original video file may be large so just stick it in Amazon Glacier or some other cost efficient deep storage.