Increase lossiness of chroma based on luminance #315
Conversation
Chroma differences are more perceptible in brighter pixels. Hence increasing lossiness of chroma planes when the luminance is lower yields better compression (with imperceptible loss in quality).
| if (p==0) return 128 + A/2; | ||
|
|
||
| // opposite logic for Y (higher Y => lower loss) | ||
| return 128 + A/2 - Y/2; |
There was a problem hiding this comment.
Doesn't this do the opposite of what the comment says? Higher Y means lower return value, which means more loss...
|
Adding more loss to chroma is certainly a good idea, but it needs testing (comparing e.g. DSSIM curves on a small corpus of images). Note that the definition of YCoCg implies that at extreme values of Y (low or high), the range of CoCg is more limited, so applying the same absolute loss already means that you're applying more loss on the near-blacks and near-whites and less loss on the midtones (which is where the more saturated colors are). |
Yup; I will write a script to run on a small corpus. And will fix up the goof-up in this patch.
Oh..interesting! |
|
@jonsneyers |
|
I wrote my own script to compare the FLIF encoder from master with the FLIF encoder from this PR. The script and results can be seen here. I am running the script on the wikipedia corpus in the FLIF-benchmark repo. The script is still running but so far the results have been good. Decreased file sizes in all cases and very little change in DSSIM. Surprisingly, in many cases, the DSSIM value is slightly better with this PR! |
|
What kind of DSSIM are you using? Kornel's? Make sure it's one that takes chroma into account, some SSIM metrics are luma-only! |
|
I used this script to compute the DSSIM. Ouch, looks like it is luma only! Do you have a script which I can use for DSSIM? |
|
Is this the one you are referring to: https://kornel.ski/dssim? |
|
Yes, that's the one. Obviously a luma-only metric is not going to be very helpful here ;) |
|
:P I thought there is only one definition of DSSIM. BTW, that project doesn't seem very stable, looking at the issues: kornelski/dssim#29 kornelski/dssim#30 |
|
OK, here are the results with the new DSSIM tool. SummaryMax DSSIM change: 0.006 Compared to FLIF master encoded |
|
@jonsneyers I have been tuning the code for the last two days, trying to reduce DSSIM delta along with visual inspection to confirm the numbers. Hit the sweet spot today (commit 27f1062) by having a conservative divisor for all zoom levels > 1, while zoom levels 0&1 get a slightly aggressive value. Attached are the results of benchmarking the change over three folders of images (wikipedia-photos, renders-pyra, webp-gallery). Summary:
Note that even the highest DSSIM changes (0.003) are barely noticeable and are on a large base (night-scene files with -Q 8000 0 where FLIF is already emitting a file with DSSIM > 0.01). All in all, I think the changes in this PR are pretty conservative. If these are fine, I am thinking of slightly more aggressive changes, in a follow up PR, that target the -Q0 levels of lossiness. |
|
Thanks for your efforts! Looks like it is a good improvement for relatively high quality, but not for the lower qualities (-Q0 and below). I've been working on some improvements for the low-quality end, so maybe making this one conditional (only for Q>40 or so, I dunno) would help to get an overall improvement. |
|
(Forgot the attachments in previous comment. Here they are). Thanks for the feedback. I was not aware that quality can be negative! I haven't benchmarked for the negative cases, but doing a quick test on original.png with I could certainly add a conditional for Q, but out of curiosity, what values of DSSIM are you generally comfortable with? I could work towards that.
Nice! |
Ah, I see your point now. The file size improvement is larger for higher qualities, yes. But adding an arbitrary conditional for Q40 sounds very hacky, and might lead to situations where Q<40 gives much better results than Q>=40. In the interest of consistency to the user, it might be good to have a smooth degradation over the quality range. |
|
I added the scripts I use for benchmarking in the benchmark repository (FLIF-hub/benchmarks@9574629). The way I test if an optimization is good, is by comparing the DSSIM vs bpp curve before and after. It's only really better if the new curve is below the old curve, i.e. if at the same DSSIM, the bpp is lower, or equivalently, if at the same bpp, the DSSIM is better (lower). You might want to try this too, because it's hard to tell if the decrease in filesize is worth the worsening of the DSSIM just by looking at the tables you made. The scripts are a bit hacky, it assumes |
|
I have implemented something along the lines of what is in this PR in commit 9644035 |
|
I tried playing around with those scripts, but my shell and perl fu seems to be lost. I can't get meaningful results out of them. Does your commit work well for all quality levels? In which case, I won't experiment further. And if it does not, I will experiment with a separate PR. |
|
Oh, ignore my question.. I didn't read your comment well. I will try to experiment further in separate PR. |
Chroma differences are more perceptible in brighter pixels. Hence increasing lossiness
of chroma planes when the luminance is lower yields better compression (with imperceptible loss
in quality).
My quick tests show 12% to 20% reduction in file size for
-Q40and-Q20respectively. Needs testing on a larger corpus.