Skip to content
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

Experiments with luma232, luma686 and gray tags #33

Open
wbd73 opened this issue Jan 2, 2022 · 3 comments
Open

Experiments with luma232, luma686 and gray tags #33

wbd73 opened this issue Jan 2, 2022 · 3 comments

Comments

@wbd73
Copy link

wbd73 commented Jan 2, 2022

I attached my own idea for a balanced list of tags.

Some things I noticed while experimenting ...

  • A separate gray tag helps with grayscale images like B/W photos.
  • For a luma232, it improves things a bit to make the range of the red and blue diffs (-2 .. 1 or -1 .. 2) dependent of the sign bit of the green diff.
  • Luma686 seems to be able to cover a lot of pixels.

I tried not to overdo it with the amount of tags and tried to get a decent amount of compression.

Grand total for images: 420 kb (attached code) vs 463 kb (qoi)
Grand total for images-lance: 1760 kb (attached code) vs 2109 kb (qoi)

Timings on my computer seem to be very inconsistent for some reason.
Maybe someone else can check if interested.
qoi2.h.txt

@chocolate42
Copy link

Luma686 is a good idea, I've been experimenting with Diff686 which seems strictly worse so Luma686 has been a drop-in replacement. LUMA232 depending on sign sounds neat, how small was the improvement and did you try applying the logic to other luma ops?

If you're benchmarking on a laptop you probably need to stop using the mouse and keyboard while it runs. Sounds silly but UI gets priority for responsiveness and a laptop is working with tighter resources so it's very noticeable. Cooling may be an issue. The default resolution of one decimal place also exaggerates variability so you might want to edit qoibench.c to use three decimal places.

@wbd73
Copy link
Author

wbd73 commented Jan 3, 2022

I was indeed doing the benchmark on a laptop powered by battery.
I did a new benchmark with the laptop connected to the power supply and not touching it while the benchmark was running.
The timings are consistent now.

The difference between LUMA232 with or without taking in account the sign is not very big and it is a bit slower.
In the results below the qoi2a version is without looking at the sign.
For the other luma tags it wasn't really helping.

# Grand total for images
        decode ms   encode ms   decode mpps   encode mpps   size kb    rate
qoi:          2.6         3.0        177.46        155.06       463   28.2%
qoi2:         2.7         3.6        171.95        130.31       420   25.6%
qoi2a:        2.5         3.3        183.13        142.22       423   25.8%


# Grand total for images-lance
        decode ms   encode ms   decode mpps   encode mpps   size kb    rate
qoi:         17.2        15.1        236.14        268.34      2109   13.6%
qoi2:        17.5        18.0        231.44        225.38      1760   11.3%
qoi2a:       16.4        17.2        248.03        236.29      1770   11.4%

@chocolate42
Copy link

3 KB saved on average doesn't sound a lot, but after reaping whatever low hanging fruit we can that 3 KB will look pretty tasty.

chocolate42 pushed a commit to chocolate42/qoipond that referenced this issue Jan 6, 2022
 in addition to the existing OP_LUMA1_232. Rerun qoipcrunch-list generation with the new op. Reduce rgba opstring count from 511 to 23, reduce rgb opstring count from 30 to 23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants