> New lossy image format gives 55 % less bytes than jpeg with the same butteraugli score.<p>It's the most serious attempt to date to make an open source replacement for JPEG which misses a lot of advances in data/image compression. I hope it stops the spreading of HEIF plagued by patents.
I noticed this project is missing quite a few features common to modern image codecs, such as variable transform sizes, deblocking, or intra prediction. Of course, it's a work in progress, so those things could still be to come.<p>Have you considered using Daala's lapped transforms? They work with variable block sizes and are quite effective for still images.<p>Also, was there anything that motivated doing a custom image format rather than applying Butteraugli to WebP?
At the first glance it looks like it uses all the basic building blocks of JPEG, but with everything upgraded to the next level.<p>It uses the same 8x8 DCT blocks, but with adaptive quantization. Like JPEG it also codes DC separately, but with 8 predictors instead of 1, etc.<p>It's like a combination the Guetzli JPEG encoder and Lepton JPEG recompressor.
The readme mentions "Brunsli (lossless JPEG repacker)" as a related project, but I can't seem to find that anywhere. Has it been released?
Now if APNG would gather some steam, high quality animated fully alpha transparent images would be nice. Gif's 256 color and 1 level transparency is ok, but to do better work we need something like APNG, although not sure how well it compresses.
HEIF already exists as a standard [1] with comparable compression [2]. What does Pik hope to do better?<p>(And please don't say "patent free" unless you are certain Pik will not infringe on those same patents)<p>[1] <a href="https://en.wikipedia.org/wiki/High_Efficiency_Image_File_Format" rel="nofollow">https://en.wikipedia.org/wiki/High_Efficiency_Image_File_For...</a><p>[2] <a href="https://nokiatech.github.io/heif/technical.html" rel="nofollow">https://nokiatech.github.io/heif/technical.html</a>
Calling it "Google Pik" implies that it's an official Google project, but the page explicitly says it is not. The post title should be changed to remove Google to avoid confusion.
Not gonna comment on the image format itself since I'm not very familiar with image compression, but from a code aesthetics point of view this project makes me a bit sad. It's a half-hearted modern C++ attempt and everything is in one directory. At least we don't have to dig it out of the Chromium repo, I guess.
"This is not an official Google product."<p>Can anyone explain this to me? It is posted under the Google organization. Are they just not actively supporting it?
The title of this post is misleading. It's not an official Google product and is not called Google Pik. This is just a project named "Pik" that happens to be developed by Google employee(s).
We're seeing a lot of different formats lately. So to make this more generic, I'm thinking we should move to an encoding-independent format. That is, the file contains an encoding-id, and the decoder can be downloaded from a standard location (a website run by a standards organization) using the encoding-id as a reference. Of course, this can be cached.<p>The decoder can be in different formats, e.g. bytecode, WASM, i386, ARM, etcetera. But of course, any binary decoders should be verified by the standards organization before it is published.