Closed kodonnell closed 2 years ago
chocolate42
commented
2 years ago It's probably better to do simple lossy by discarding the low bits of each value with shifts, but you crack on with experimenting as you please.
It won't be added to the QOI spec, that's finalised. Here is where ideas for new features are being discussed, good ideas might make it into some future format: https://github.com/nigeltao/qoi2-bikeshed/issues
kodonnell
commented
2 years ago FYI results here - you can skip to the second table with JPEG comparisons. Assuming I didn't do anything silly, it's pretty compelling - you can get "similar" compression ratios to JPEG but a whole lot faster. (It depends on the JPEG quality setting, and how much you downscale for "lossy QOI".) That feels like at least mentioning in the readme, as it's somewhat unique to QOI (e.g. doing this with PNG wouldn't make sense as it's not as fast). But maybe it's just me = )
It's probably better to do simple lossy by discarding the low bits of each value with shifts
I thought that originally too, but wanted to do it without changing the format or this implementation, hence the scaling. But after thinking about it just then, I realised I could - I'll just shift the image before encoding it. Unfortunately, when dropping the last 3 bits (which gives similar SSIM to what I was looking at for the above method and JPEG) it's 4-5x slower and 2.5x worse compression than the above method. (Some of the encoding time could be memory layout stuff in numpy, but still not compelling.) But that's probably a discussion for that bikeshed repo ... and I guess doesn't ultimately change that it's potentially worth highlighting in the readme that QOI can easily be used as-is for lossy compression, and with compelling reason.
@phoboslab - can you close this if you disagree? I don't mind whatever you decide, but might as well close it if you disagree.
dumblob
commented
2 years ago and I guess doesn't ultimately change that it's potentially worth highlighting in the readme that QOI can easily be used as-is for lossy compression, and with compelling reason.
This is actually true for any lossless format. But yes, people do not know about it - e.g. pngquant.org has really good visual results (but it's extremely slow e.g. for use in smartphones for cameras).
kodonnell
commented
2 years ago This is actually true for any lossless format. But yes, people do not know about it - e.g. pngquant.org has really good visual results (but it's extremely slow e.g. for use in smartphones for cameras).
True, but that's why I made the comment around why QOI is somewhat uniquely suitable to being able to do this usefully (unlike e.g. PNG).
I'm not sure if this has been covered yet, but I think it's worth highlighting in the readme that it's very easy for a user to make QOI lossy for 'free'. That is, on encode, scale the image down by X, then encode with QOI, and on decode, decode with QOI then scale up by X. I'd be really interested to see a detailed comparison with JPEG (in terms of visual quality and size etc.), but for now my suspicion is this will be pretty compelling. For example, with X=2 I'm guessing we'd be around 4x smaller, and faster by 4x (less sampling speed which should ?? be minimal if we use simple algorithms). I'm guessing that'd put us around JPEG in terms of compression ratio, but oodles faster (as QOI is already a fair bit faster), and similar quality. I can have a play with this if there's interest - with the python implementation I have it should be pretty quick, once I get some reference images.
Anyway - for now I'm advocating putting something in the readme and publicising it, preferably after a little validation. Whether we incorporate it into the specification (basically just putting the value of X in a header, and maybe the sampling method?) and exactly how we'd do the sampling is probably a discussion that can happen after we've proven the idea.