Open jmaselbas opened 2 years ago
Do you have any qoibench.c
numbers (i.e. decoder speed, encoder speed and compression ratio comparisons)?
qoibench output can be found here: https://gist.github.com/jmaselbas/6cdbfd1898524ca944c1c1bd22c5204f
# Grand total for images/
decode ms encode ms decode mpps encode mpps size kb rate
qoi_i: 2.9 8.6 160.21 53.71 445 27.1%
qoi: 0.0 6.2 0.00 74.55 463 28.2%
I spent a few hours hacking on the original qoi image format, adding a combined index+diff and Index+luma opcode. From what I've seen (from my images) the run length encoding very rarely exceed 10. From my understanding of the format the index or luma opcodes can only apply on the previously seen pixel, which is believe is good for gradient. If theses two opcode cannot be applied the only solution is to push a new pixel color with the rgb and rgba opcode. I had the feeling (biased) that combining index+diff or index+luma (applying the diff/luma opcode on a value from the indexed pixel) could result in a better compression.
That's what I've done and I've confirmed that it indeed "works" (to be taken with a grain of salt). Also this doesn't increase too much the decoding complexity.
My current implementation is stupid as it goes through all 64 pixel in the "hash" table and tries to find a pixel that's close enough. Another possibility would be to use another table of pixels with there values truncated/aligned (not sure how), with the lower bits encoded in the "diff" opcode.
edit: the branch can be found here: https://github.com/jmaselbas/qoi/tree/qoi_idiff_iluma