3 ms·

QOI is confusing simple with primitive. It's worsening compression only due to trauma of using dependencies in C. I strongly disagree with characterization tha

by pornel 4y ago

QOI is confusing simple with primitive. It's worsening compression only due to trauma of using dependencies in C. I strongly disagree with characterization that JPEG is overcomplicated, especially in a controlled situation where you only need to support files you encode yourself (as is the case with QOI), and not edge cases like Adobe's CMYK extension. JPEG's design is brilliant for the level of compression it's capable of. libjpeg API is crufty, and C dependencies are a pain, but you can use other implementations and languages.

wolletd 4y ago
I'm working at a small company that does computer vision and image processing stuff, doing a lot with embedded systems. At some point, I was asked to write code to save images on live systems to be downloaded and used for... CV stuff. Also, the images had to be (although weakly) encrypted for IP reasons. The issue being that those cameras run at 200fps when there's anything of interest and use their compute to do image processing. The flash memory used also isn't made for this kind of write speed. All that is to say: JPEG is insanely efficient. It takes a moment to compress the image, but only encrypting 10% of the data saves a lot more and the flash memory can keep up way longer than with raw images. I had to generate some difference images though to convince some CV and management people that we don't need raw images. If our analysis results would depend on a dozen pixels not being off 1-2 gray values, it's broken. There's more noise in every single image than JPEG-induced errors.
- brucethemoose2 4y ago
  > 200 fps TBH that sounds like a job for a video codec.
SkeuomorphicBee 4y ago
JPEG's design is brilliant, that is very true, but it also complicated. It uses a lot of CPU cycles to calculate the FFTs of the signal, and that is where the simplicity of QOK shines, by operating on the signal itself (instead of expensively transforming it to frequency space) it can be order(s) of magnitude faster. The discussion is not about the quality of the API, but the amount of work an actual machine will have to do to compress/decompress.
- pornel 4y ago
  DCT is relatively expensive compared to just RLE, but keep in mind that JPEG has been standardized in early 1990s when 33Mhz CPUs were fast. Today a few multiplications are nothing for CPUs. We have fast SIMD implementations. Nowadays Huffman is the bottleneck and could have been improved with tANS coding.

by pornel 4y ago

wolletd 4y ago

I'm working at a small company that does computer vision and image processing stuff, doing a lot with embedded systems. At some point, I was asked to write code to save images on live systems to be downloaded and used for... CV stuff. Also, the images had to be (although weakly) encrypted for IP reasons. The issue being that those cameras run at 200fps when there's anything of interest and use their compute to do image processing. The flash memory used also isn't made for this kind of write speed. All that is to say: JPEG is insanely efficient. It takes a moment to compress the image, but only encrypting 10% of the data saves a lot more and the flash memory can keep up way longer than with raw images. I had to generate some difference images though to convince some CV and management people that we don't need raw images. If our analysis results would depend on a dozen pixels not being off 1-2 gray values, it's broken. There's more noise in every single image than JPEG-induced errors.

brucethemoose2 4y ago
> 200 fps TBH that sounds like a job for a video codec.

SkeuomorphicBee 4y ago

JPEG's design is brilliant, that is very true, but it also complicated. It uses a lot of CPU cycles to calculate the FFTs of the signal, and that is where the simplicity of QOK shines, by operating on the signal itself (instead of expensively transforming it to frequency space) it can be order(s) of magnitude faster. The discussion is not about the quality of the API, but the amount of work an actual machine will have to do to compress/decompress.

pornel 4y ago
DCT is relatively expensive compared to just RLE, but keep in mind that JPEG has been standardized in early 1990s when 33Mhz CPUs were fast. Today a few multiplications are nothing for CPUs. We have fast SIMD implementations. Nowadays Huffman is the bottleneck and could have been improved with tANS coding.