> New lossy image format gives 55 % less bytes than jpeg with the same butteraugli score.
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.
> Unlike some other image formats (e.g. BPG and JPEG 2000), FLIF is completely royalty-free and it is not known to be encumbered by software patents.
The reference implementations are also open source (dual licensed between LGPL and Apache 2)... But even if you don't like those, you can write your own under whatever license you like. They're just implementations of a spec.
I'm not certain, but I think HEIF itself is royalty-free.
HEIF is just an image container format. The current implementation of HEIF supports JPEG, H.264, and H.265. So, yes, if you use H.264 or H.265 inside HEIF then you have all of those attendant patent licensing issues. But if you use JPEG inside HEIF or if someone implements support for VP8 or VP9 or eventually AV1 then I think you should be able to use HEIF royalty-free.
The "License Grant" section of LICENSE.TXT sounds like it grants a royalty-free patent license to the HEIF format itself, exclusive of any codec patent licenses as you'd expect. So I think once VP9 or AV1 support is added HEIF may be a nice container format for images.
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.
Have you considered using Daala's lapped transforms? They work with variable block sizes and are quite effective for still images.
Also, was there anything that motivated doing a custom image format rather than applying Butteraugli to WebP?
We have tried a large variety of approaches for the integral transform, but we were not impressed with the density/complexity/quality/decoding speed compromise -- at high image quality. We believe that we can only add a certain amount of complexity in this kind of format, and we try to keep our complexity budget targeted on solving the high-quality-high-decoding-speed image compression as well as possible.
Waterpik uses another name in Denmark. "Pik" is the common Danish word for male genitals. Most Danes can easily translate "water" to the danish word "vand". And "vandpik" is a term for the morning erection.
"And you put that thing in your mouth?!?!"
I'm just gonna start naming my projects by rolling my face on my keyboard, that way I won't have to be afraid of naming it something offensive in another language.
A naming pattern that I used for some time was to open the Wikipedia article of the thing that my program is about, and look in the sidebar for nice-sounding names for it in another language. It often ended up being something Scandinavian. For example, KDE's jigsaw puzzle game is called Palapeli (Finnish for "jigsaw puzzle") for this reason.
Oddly the name Dick is spelled and pronounced just like the slang term for a man's penis in the English language. You would think that would offend American puritanical sensibilities but the name is quite common.
In Holland there's a famous 90s detective show with a main character surnamed 'De Cock'. One of his 'catchphrases' is that upon being introduced to someone, he explicitly spells out C-O-C-K to them (because in Dutch the typical spelling is K-O-K), which means 'cook'.
Despite the fact that Dutch people are often fluent in English, and despite the fact that we even had a prime-minister with the name 'Kok', there's a surprisingly low number of jokes, in my opinion, involving this particular surname. I guess somehow the context switch from Dutch to English is big enough that it's just not all that funny.
Change the first letter to S and guess what you get in Turkish... It's far enough that it wouldn't be necessarily embarrassing to mention but interesting in the light of this knowledge.
PIK is building on guetzli and butteraugli, gives about -55 % less bytes than JPEG for the same butteraugli score. Decoding speed is 2/3 that of JPEG. Encoding speed is impractically slow in this version. PIK aims at delivering very high quality photographs with minimal bandwidth and decoding (cpu and memory) costs.
Yes, you would have to read the source code. My guess reading the README.md is that due to the dependencies in the README.md its a JPEG competitor that is fast due to HEVC. The README.md even says this is still experimental. This project really looks too immature to be posted on HN without a technical breakdown. (This is not to disparage the software but for people to remain interested there would have to be at least some benchmark and it would be nice with a visual comparison).
Google has failed to convince any browser maker not using their entire Blink rendering engine (i.e. Opera) to implement support for WebP. It's been almost seven years, not what I'd call successful.
On the server side, if you're processing images to create multiple versions anyway (thumbnails, different sizes for mobile & desktop, etc.), throwing WebP versions in there is simple enough and should reduce bandwidth use. It's not worth doing if you're not fully automating image handling for other reasons.
It's not hard to use SRCSET to put WebP + JPEG2000 + JPEGXR images which covers Chrome, Safari and IE, and fallbacks for old browsers / FF. Hardly ideal but easy to get pretty good results.
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.
Who “absolutely can’t use” it, and for what purpose?
Most people use patent-encumbered media formats all the time.
HEVC is going to have dedicated hardware support on most devices in the near future, and will therefore be power-efficient and fast to encode and decode.
> Who “absolutely can’t use” it, and for what purpose?
Web browsers. H.264 was finalized in 2003 and while it was supported by Chrome at launch in 2010, it wasn't supported in Firefox until 2013, a full 10 years later, though admittedly support was in Flash in 2007.
> Most people use patent-encumbered media formats all the time.
A major difference between HEVC and other patent-encumbered formats is that HEVC has no single licensing pool with a clear pricing scheme. There's no single place you can go and say "I want HEVC" and know how much you're going to need to pay. Off the top of my head, there's MPEG-LA, HEVC Advance, Velos Media and Technicolor. All of them have different requirements and cost schemes. Also importantly, HEVC Advance was intending to charge for distribution separately from encoding.
As much as I hate MPEG-LA, it definitely helped with H.264's adoption.
> HEVC is going to have dedicated hardware support on most devices in the near future, and will therefore be power-efficient and fast to encode and decode.
Yes but that hardware support needs to be piped through to browsers, which will take time and consent. Is Mozilla going to allow patent-encumbered HEVC into its browser when it's part of AOM and AV1 is just around the corner?
To be clear, I'm mainly talking about web browsers, since they're how most people consume images these days. I'm sure HEVC will find its way into things like TVs, cameras and home theatre systems without issue but I have doubts about its viability on the web.
There has never been anything quite like the patent situation around HEVC. Using HEVC legally requires signing four different license agreements at the minumum[1]. The license agreements with Technicolor and Velos Media are actually secret. This includes their fees. The other two licenses (MPEG LA and HEVC Advance) are public. They are far more expensive then H.264 taken individually, even at current promotional rates.
As a result the Alliance for Open Media (AOM) was formed by major hardware and software companies. AOM is developing an alternative to HEVC. AOM has almost all hardware manufacturers of any significance as members.
[1]: Other essential patent holders who have not officially licensed their patents include AT&T, Microsoft, Motorola, Nokia, and Cisco. They may elect to license their patents unilaterally, which adds additional uncertainty to HEVC.
Maybe "The software currently requires an AVX2 and FMA capable CPU, e.g. Haswell." holds the secret? Some kind of experimental test bed for using CPU vector instructions to speed up compression/decompression?
Disclaimer: I have no idea what I am talking about. For all I know possible use of these instructions is already a feature of HEIF and that statement is irrelevant.
http://www.libjpeg-turbo.org/ uses some CPU vectorization features already. (If you're using Linux, most likely you're already using it since most Linux distros switched over a long time ago).
Yep. Use of AVX2 and so forth a pretty standard thing to do to get decent performance for video/image encoding and decoding.
Worth noting: Skylake with Integrate Graphics includes an x265 encoder and decoder. If that can't be adapted to HEIF, that's a huge win for the format.
If you're interested in this kind of thing, dc_predictor.cc might be fun to look at. It computes the predictors in parallel (rather than the usual 'do the same thing to 32 pixels') because here pixels depend on causal neighbor pixels.
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.
It might not have been done with Google's time and resources; Google likes to strong-arm employees into agreeing that Google owns their side projects. The `google` organization on GH is a compromise.
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.
It is licensed under Apache 2.0, so if Google has any patents on it they could not use them against users of this code or derivative code because of the terms of the license. This doesn't protect you from the several other irresolvable issues in software patents however.
It's written by a Google employee, and therefore Google owns all rights to it. However, in all other respects it's just an open source project written and supported in the authors' free time.
You have the option of having Google own the code, and in return you can work on it using Google hardware, work on it while at work, use other google code or discuss it with your coworkers freely.
Or you can ask to retain ownership of your project, but then you don't get to do any of the above. This option is also sometimes (thanks DannyBee for correcting me) not available if your project is considered to be too similar to some critical Google interest. The basic idea is outlined here: https://opensource.google.com/docs/iarc/
"This option is also not available if your project is considered to be too similar to something Google's working on (due to obvious IP issues.)"
Speaking as an IARC committee member, this is not quite correct.
We have in fact, approved plenty of stuff that is close to what google is working on. For example, we've approved plenty of search engines.
(The overall approval rate is >96% last i looked).
It's not so simple that i can easily draw principled bright lines for you though :)
An example would be those where the person is really trying to get the IP to create a separate company that competes with Google in some area, and then quit.
Yes, this happens. It's not even that we care or don't care in that case, we are just literally the wrong forum.
People, for the most part, very badly misunderstand what california law says.
For most large diversified corporations, the corporation will own all of it, because it will "Relate at the time of conception or reduction to practice of the invention to the employer’s business, or actual or demonstrably anticipated research or development of the employer;"
Note that it's completely irrelevant what the employee is doing for them. Also note that most employees rarely have any idea of all the things their employer does.
By numbers, employees lose the vast majority of lawsuits under 2870 in california.
(I believe that the fact that people think it is so great is one of the things that holds us back from making it actually great)
Most employers have no desire to sue employees, so most of these settle or get ignored, AFAIK.
At least in the case of Google (literally, i have no concept of other Alphabet companies), the only cases i'm aware of where Google has claimed it owned something was when the employee sued Google first.
example: A former employee suing Google over a patent developed while employed by Google, google counterclaims it owns that patent under the IP agreement.
Since some folks have trouble reading between the lines: Google considers all code possibly relevant to its business interests, and treats employees (in)appropriately.
> If you work at Google __everything you make__, even in your spare time, belongs to them.
Okay, google makes software and if you make software on your spare time maybe it's reasonable that company does not want to leak IP and thus produces these contracts.
But what about these stupid examples:
- Building a backyard deck for your house
- Taking pictures as a hobby
- Doing woodworking (e.g. making a chair and a table for your home office)
- etc..
So with this contract, Goggle owns my deck, desk, chair and a picture of these items, because I produced them on my spare time? Will horde of lawyers will come to my house and take my deck, desk, chair and picture of those items, because I used them while working remotely and bought tools to build them with the salary they payed me?
Even if those examples are completely rubbish and won't stand in court for Google, it's still absurd idea. You get payed salary for your time and work - that's it! That's where Google's power ends. After hours you go home and it's bullshit that they can own your personal work done on your own freetime at your private property with private tools and your own ideas. If they want to own everything then they should pay hourly average times 24hours , times 365 days per year as a salary, because I am giving all my time and work for them, while I am in contract with them.
EDIT: quote from Google's Personal Projects (IARC) [1]:
> Because Google’s business interests are so wide and varied, this likely applies to any personal project you have. That includes new development on personal projects you created prior to employment at Google.
Errr. Decks are not intellectual property, for starters.
"Even if those examples are completely rubbish and won't stand in court for Google, it's still absurd idea. You get payed salary for your time and work - that's it! That's where Google's power ends. After hours you go home and it's bullshit that they can own your personal work done on your own freetime at your private property with private tools and your own ideas. If they want to own everything then they should pay hourly average times 24hours , times 365 days per year as a salary, because I am giving all my time and work for them, while I am in contract with them.
"
You are sorely confused about the state of the law in the US. In the US, in most states, it doesn't even have to be written into an employment contract. The employer will simply own the IP, period.
At the end, he mentions that general statements never apply to everybody, and unique situations vary. Additionally, in California the law protects moreso than other states.
but grellas doesn't actually disagree with me anywhere?
FWIW: I'm also an IP attorney, and among other things, have been doing "invention assignment" work for quite a while.
I'm very familiar with the employment law situation in california, and this area in particular.
" Additionally, in California the law protects moreso than other states."
I didn't say it didn't?
I said it's not as good as people seem to think
This is not true, and employees are explicitly told that this is not true.
There is an internal process to have google release any copyright they may hold on any project you produce on your own time without using corp resources. All it requires is going through a standard and a (mostly) boilerplate legal review.
If Google resources were used to create it (machines, the author's 20% time, google tools, etc), or if the author lives in a state/country without moonlighting protections.
I guess the former, and the author might be doing it as a 20% project owned by Google in the hopes of making it a larger, more successful project.
It's worth noting that depending on your location this is actually _the default_. As in, if it isn't in your contract, your side projects belong to your employer.
Yeah I was very surprised to read this in my current contract (first employer, the Netherlands). It basically says: "as is the default, we own products/code/whatever that is relevant to our business, even if you made it in spare time, but we make the exemption that contributions to pre-existing open source projects can be under an open license, because we are so benevolent and don't want to discourage this".
I asked about it, but without raising a formal complaint, I didn't get more than the general logic, which is "because you also learn from experiences on the job, it's unfair if you can can put stuff together and then sell it or even give it away for free to potential competitors".
I'm still considering whether or not to make a big deal out of it in future contracts; but next month I'm going to do a master's anyway, so it was a temporary limitation (and I accepted with that in mind).
Usually these are 20% projects that googlers are allowed to make the MVP of the project. Those same people that created it will support it on their own time.
In addition to what other replies stated, you can read Google's documentation on how open source projects (official and unofficial are released) here: https://opensource.google.com/docs/
> "This project is in the initial research stage, please don't use it for any purpose."
So it's not a product at all, it's a research project. In particular, not being a product means that if you try to store or distribute images in this format, they'll probably be hard to recover a few years from now.
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).
In one company we named projects after mountains in the alps. One was called "Wank" until a few months later an English intern told us that maybe we should change this.
its for images on the internet - are you sure it's not a good match?
Joke aside, Pik is also Spades in German. Since its a compression library and it looks like Jan Wassenberg
works at the the Zurich office, it might also be some food, in line with the other work they have been doing: brotli, butteraugli, brunsli, guetzli
With web assembly it should be possible to use new image formats even if the browser doesn't support it. This will improve in the future when wasm gets access to SIMD instructions and GPU computation.
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.
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.
Sounds like a recipe to leave out unpopular platforms in the cold. What are the chances Adobe or whoever makes their decoder compatible with Haiku or NetBSD? At least with a few standard formats, volunteers have some hope of writing their own decoders once every few years. Plus, what about more restricted platforms? Lots of featurephones include browsers that can decode JPEG and PNG, but good luck getting them to download and run a custom software based decoder.
Yes, but the amount of encodings is pretty limited. It's better (imho) to make the encodings free of any viewer or browser. That way, we can more easily handle a large variety of encodings, and different versions of encodings. Anyone could make a new encoder, and create files using them.
You can see it as a "democratization" of encodings.
The FourCC at the beginning is indeed your encoding-id. This is common in file formats (e.g. RIFF).
Out of curiosity, how is the 32-bit space insufficient?
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.