Hacker News new | past | comments | ask | show | jobs | submit
augment_me | on: Nibnib: Image compression with extreme decompression speed
Which would have been clear if numbers were provided for a JPEG implementation in the repo
orangeboats | parent
Why though? I thought it was pretty clear that you're not gonna decode JPEG pixels in 6 instructions.
schobi | root | parent | next
I understand this is fast, okay. But at what trade-off?

Sure - muuuuuch less than Jpeg, but how many would you assume for JPEG on average? How low could you go by misusing jpeg?

Typically, you would plot graphs with Bitrate / quality / speed. Maybe even with default jpeg settings and getting just a single data point for your new algorithm.

alembic_fumes | root | parent
Mandatory https://xkcd.com/2501/

As a free anecdatum, I have no idea how long image decompression meaningfully takes! As far as I'm concerned, JPEGs decompress instantly but that's likely only because I've never dealt with scenarios where processing power or bandwidth is that limited. But if I somewhen were in such a situation, seeing some numbers would likely help contextualize the differences here.

A similar scenario happened to me some years back, when I had to pick an appropriate compression algorithm for some hundreds of gigabytes of parquet files because AWS Athena was being slow. The comparison table on zstd's GitHub was immense useful and provided that level 0 to level 1 of understanding on these matters.

Experienced people still have blind spots, and I believe it's good to explain the obvious if understanding it is essential to the matter. :)