20 ms·
Pik – a new lossy image format for the internet
- azhenley 9y ago"This is not an official Google product." Can anyone explain this to me? It is posted under the Google organization. Are they just not actively supporting it?
- deleted 9y ago[deleted]
- brian_herman 9y agoYes, it is from google but it is not supported by google.
- zitterbewegung 9y agoUsually 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.
- ilyagr 9y agoIt'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.
- stepik777 9y agoHow could Google own something written and supported in the authors' free time?
- hayksaakian 9y agoOppressive employment agreements
- corobo 9y agoThe Google employee thought the contract terms were worth the job so signed it
- mattnewton 9y agoIf 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.
- kuschku 9y agoThat depends on jurisdiction, obviously. If you do it during your break time, even if it’s produced on company machines, it remains yours, the company has no right to it. (in Germany).
- vinceguidry 9y ago"Free time" can mean time spent on the job not contributing to his delegated tasks, such as 20% time.
- polk 9y agoIf you work at Google everything you make, even in your spare time, belongs to them. That's how the contracts work, unfortunately.
- TulliusCicero 9y agoThat's not true, at least not in California. But if you made it with Google resources then yes they own it.
- DannyBee 9y ago"That's not true, at least not in California." 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)
- Terribledactyl 9y ago> By numbers, employees lose the vast majority of lawsuits under 2870 in california. Do you happen to know if this is because only very strong cases materialize?
- DannyBee 9y agoI don't, but it's certainly possible. 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.
- mkishi 9y agoIt'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.
- lucb1e 9y agoYeah 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).
- BurningFrog 9y agoAnd it's not actually called "Google Pik". Just "Pik".
- lowkeyokay 9y agoCertaintly will cause a few laughs in Denmark... (hint: Google translate)
- pbhjpbhj 9y agohttp://en.bab.la/dictionary/danish-english/pik http://en.bab.la/dictionary/danish-english/pik "cock/dick/penis"
- EddieRingle 9y agoIn 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/ https://opensource.google.com/docs/
- jimrandomh 9y agoFrom the readme: > "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.
- svisser 9y agoUnfortunate name if you happen to know Dutch.
- fredsir 9y agoDanish too.
- dep_b 9y agoGreat match for Flickr!
- deleted 9y ago[deleted]
- 0x006A 9y agoits 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
- colinbartlett 9y agoOh... (NSFW) https://www.google.com/search?q=pik+meaning+dutch https://www.google.com/search?q=pik+meaning+dutch
- forgot-my-pw 9y agoGood for porn images.
- corobo 9y agoWell that is how new tech is often proven
- maxxxxx 9y agoIn 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.
- deleted 9y ago[deleted]
- adrianN 9y agoBecause Webp was such a success?
- kyriakos 9y agoNot a failure either
- kuschku 9y agoIt’s unsupported on the browser that holds 43% of desktop marketshare in central Europe, how is that not a failure?
- trevyn 9y agoThat doesn't make it a failure.
- extra88 9y agoGoogle 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.
- theandrewbailey 9y agoFirefox support is coming. Looks like there's been a bit of activity on the ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1294490 https://bugzilla.mozilla.org/show_bug.cgi?id=1294490
- mercer 9y agoI am not well-schooled in this area, but I find it very surprising that webP is not supported on Firefox yet. Am I wrong in being surprised?
- coockciiciv 9y agopik refer to the male sex organ.
- tyteen4a03 9y agoI speak a bit of Danish and can't help but to giggle at the name. (Yes, it means dick)
- anigbrowl 9y agoWhy?
- pmontra 9y agoAny patents on this?
- cyphar 9y agoIt 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.
- blahshaw 9y agoIs this what Google Photos uses for their unlimited "high quality" image storage?
- adventured 9y agoThe short answer is: no
- Scaevolus 9y agoGoogle photos "high quality" means downscaling to 16MP if larger and compressing at 85% libjpeg quality level. I don't believe it uses exotic codecs.
- jxcole 9y agoCan anyone explain if there is something particularly new or interesting about this image format? Or do I have to read the source code?
- zitterbewegung 9y agoYes, 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).
- JyrkiAlakuijala 9y agoPIK 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.
- ninju 9y ago- 55% less bytes is a double negative so its 55% more :-)
- jordache 9y agoyawn.. let us know when a major browser implements support for it...
- Houshalter 9y agoWith 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.
- amelius 9y agoWe'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.
- a_t48 9y agoThe file does contain an encoding-id - it's the last three or so characters in the filename (alternatively, the first four bytes in the file data).
- amelius 9y agoYes, 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.
- janwas 9y agoThe 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?
- icebraining 9y agoSounds 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.
- Piccollo 9y agoewwww c++
- 0xffff2 9y agoWhat would be an acceptable language in your view?
- vladdanilov 9y ago> 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.
- trevyn 9y agoUh, WebP?
- vladdanilov 9y agoWebP lossy is aimed at low quality (Q<75) and YUV420 only.
- pasta 9y agoI had high hopes for FLIF. What I think is great is that the client can control how much data is downloaded. This is great for responsive use. Unfortunately the license is holding back implementations.
- oliwarner 9y ago> 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.
- jonsneyers 9y agoHow so? The FLIF reference implementation is Apache 2.0 licensed for the decoder, how does that hold back implementations?
- deleted 9y ago[deleted]
- clouddrover 9y ago
- euroclydon 9y agoWell, is it still using discrete cosign transforms like JPEG, or wavelets like JPEG2000, or what?
- JyrkiAlakuijala 9y agoYes, it is using the discrete cosine transform like JPEG.
- tarikozket 9y agoDoes Google recognize it and show it on image results?
- Camillo 9y agoCalling 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.
- wmf 9y agoOr maybe Google should avoid confusion and stop putting unofficial projects under github.com/google.
- londons_explore 9y agoPet projects done with googles time and resources can't easily be published elsewhere on github...
- wmf 9y agoSays who? Google? They made the policy, it's confusing as hell, now they should fix it.
- DonbunEf7 9y agoIt 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.
- alpb 9y agoThe 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).
- ThomPete 9y agoGood thing Denmark is a small market as it means Dick in Danish.
- martin_bech 9y agoIt litteraly means dick.. i mean.. no words.
- cptskippy 9y agoOddly 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.
- mercer 9y agoIn 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.
- iRobbery 9y agoIn The Netherlands too, cant wait till i can shout at my co-worker to convert some image to it.
- cjensen 9y agoHEIF already exists as a standard [1] with comparable compression [2]. What does Pik hope to do better? (And please don't say "patent free" unless you are certain Pik will not infringe on those same patents) [1] https://en.wikipedia.org/wiki/High_Efficiency_Image_File_Format https://en.wikipedia.org/wiki/High_Efficiency_Image_File_For... [2] https://nokiatech.github.io/heif/technical.html https://nokiatech.github.io/heif/technical.html
- mattnewton 9y agoMaybe "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.
- cjensen 9y agoYep. 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.
- janwas 9y agoIf 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.
- rwmj 9y agohttp://www.libjpeg-turbo.org/ 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).
- ThrowAway29112 9y ago
- s0me0ne 9y agoNow 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.
- Ajedi32 9y agoPretty sure APNG is supported now in all browsers except Edge and IE. So not quite there yet, but we're getting close.
- pbhjpbhj 9y ago>except Edge and IE // Any ideas why?
- ac29 9y agoDoesn't work in Chrome for Android either: https://caniuse.com/#search=apng https://caniuse.com/#search=apng.
- Ajedi32 9y agoAre you sure that's accurate? Chrome Platform Status says it's enabled by default in Chrome 59 on Android: https://www.chromestatus.com/feature/6691520493125632 https://www.chromestatus.com/feature/6691520493125632
- pornel 9y agoUse VP9, which is literally 15 times smaller. It supports alpha transparency, too.
- ttoinou 9y agoVP8 has Alpha built-in and works in ffmpeg, VP9 IIRC this could be implemented but I don't know if there are implementations out there
- TD-Linux 9y agoI 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?
- JyrkiAlakuijala 9y agoWe 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.
- Noctem 9y agoThe readme mentions "Brunsli (lossless JPEG repacker)" as a related project, but I can't seem to find that anywhere. Has it been released?
- pornel 9y agoAt the first glance it looks like it uses all the basic building blocks of JPEG, but with everything upgraded to the next level. 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. It's like a combination the Guetzli JPEG encoder and Lepton JPEG recompressor.
- JyrkiAlakuijala 9y agoYes, PIK is like guetzli + lepton, but decodes 2-3x faster and compresses 20 % more.
- jgh 9y agoNot 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.
- deleted 9y ago[deleted]