New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reduce generation loss #3563
base: main
Are you sure you want to change the base?
Reduce generation loss #3563
Conversation
Seems sensible enough to me, but I'll leave it to @jyrkialakuijala. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm looking at this at a more fundamental level (Gaborish inaccuracies and other generation loss induction -- experimentally I found that mostly they are in enc_group.cc in quantization adjustments, and I don't yet understand why they induce generation loss)
While I study the more fundamental reasons, it is ok to get this merged as this already helps with the symptoms
8ee8cad
to
6a5ed38
Compare
Rebased since there were merge conflicts, didn't change anything but needs re-approval. |
Are there some tests that are newly failing? |
6a5ed38
to
af57fa8
Compare
Fixed tests, I think. |
af57fa8
to
92860a5
Compare
92860a5
to
48ec2d3
Compare
At very high quality / low distance settings, some of the default encoder choices are doing more harm than good, especially w.r.t. generation loss. In particular:
The rationale for these changes is as follows: at very low distances, it is more likely that additional editing/processing will still be done, i.e. we are in an authoring workflow, not a web delivery scenario. Therefore generation loss is a critical issue that needs to be addressed.
Single generation
Before:
benchmark_xl v0.10.2 22a9c10 [NEON]
12 total threads, 637 tasks, 12 threads, 0 inner threads
After:
benchmark_xl v0.10.2 2b193d2 [NEON]
12 total threads, 637 tasks, 12 threads, 0 inner threads
Overall (at these very low distances) this gives a nice improvement in bpp*pnorm. It does introduce a discontinuity at d0.5, since Gaborish gets enabled at d>0.5, which causes the first generation of d0.51 to be slightly better quality than the first generation of d0.5.
Multi-generation
Testing with 10 intermediate generations, the generation loss issue becomes clear:
Before:
benchmark_xl v0.10.2 22a9c10 [NEON]
12 total threads, 637 tasks, 12 threads, 0 inner threads
Generation loss testing with 10 intermediate generations
After:
benchmark_xl v0.10.2 2b193d2 [NEON]
12 total threads, 637 tasks, 12 threads, 0 inner threads
Generation loss testing with 10 intermediate generations
After 10 generations, d0.3 went from pnorm 0.23 to pnorm 0.86 before this PR — significantly worse than first-generation d1.
After this PR, d0.3 now goes from pnorm 0.25 to pnorm 0.38 — still about as good as first-generation d0.5.
Encode/decode speed was not measured accurately but obviously skipping gaborish will make both somewhat faster (at d <= 0.5).
These changes make it substantially more feasible to use very high quality lossy jxl (e.g. d0.1 or d0.2) as an alternative for lossless in an authoring workflow. Of course only lossless is fully safe w.r.t. generation loss, but if the number of re-encodes is reasonable (e.g. less than 10), d0.2 will now be just as good, in practice.