The QOI (Quite OK Image) format is a new lossless image compression format that claims similar compression ratios as PNG with faster encoding and decoding.
The QOI specification is very simple and easy to implement. As an exercise, I have written a Racket implementation. I have tested it against the official example images but I have not run any benchmarks yet.
The official implementation in C uses 8-bit arithmetic operations, bit shifts and bitwise logical operations. In my Racket implementation, I have used multiplications and additions instead of arithmetic-shift and bitwise-ior. I find it more readable this way but it is a matter of taste, and I have no idea how it affects performance.
At the moment, it can only perform conversions between raw RGBA image files and QOI.
While working on the encoder, I have tried to use read-bitmap to read PNG files, but I have found that it always applies gamma correction and does not give access to the original pixel values.
Do you know any other image manipulation library that could allow reading PNGs without any additional processing?
Is this a case where macros could be swapped in to use "8-bit arithmetic operations, bit shifts and bitwise logical operations” to make the program look like it’s using "multiplications and additions” but it’s actually using low-level ops? You could even test the two against each other.
After writing my post, I wondered whether my choice of operations was actually more "readable". My code uses functions with shorter names but maybe we lose the intent of these operations. I was considering wrapping some operations in macros or functions with clearer names.
Maybe this library may help you getting access to the raw data: png-image: Library to view and modify PNG chunks. But it is a bit more lowlevel, ideally there was a way to get raw rgba data without processing.
I agree that png-image is too low-level for my purpose.
What I need is a quick way to read PNG files to test my own library in the same conditions as the reference QOI implementation.
In all PNG-loading modes, gamma correction is applied when the file provides a gamma value, otherwise gamma correction is not applied. The current display’s gamma factor is determined by the SCREEN_GAMMA environment variable if it is defined. If the preference and environment variable are both undefined, a platform-specific default is used.
So making sure the file doesn't have a gamma value and setting SCREEN_GAMMA environment variable to 1.0 might work?
The way I read the first sentence, if the file doesn't have a gamma value then it shouldn't do any gamma correction. So maybe there is some image editing tool that allows you to remove that / check whether the image has a gamma value set?
Here is another idea, find out the gamma value set in the image and set SCREEN_GAMMA to the same value, then correction should also become a no-op if it is working correctly, but the previous things might be easier.