Earlier quoted context omitted.
In The Netherlands too, cant wait till i can shout at my co-worker to convert some image to it.
I'd be careful about asking your co-workers for "dick pics".
Pik pics
Pik – a new lossy image format for the internet
91–100 of 151 posts
Re: Pik – a new lossy image format for the internet
#92Earlier quoted context omitted.
> 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…
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 id…
> it __doesn't even have to be written into__ an employment contract.
well I am glad I am not working in US then..
Re: Pik – a new lossy image format for the internet
#93Can anyone explain if there is something particularly new or interesting about this image format? Or do I have to read the source code?
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.
- 55% less bytes
is a double negative so its 55% more :-)
Re: Pik – a new lossy image format for the internet
#94Earlier quoted context omitted.
That doesn't make it a failure.
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.…
Firefox support is coming. Looks like there's been a bit of activity on the ticket:
Re: Pik – a new lossy image format for the internet
#95HEIF 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_For...
Re: Pik – a new lossy image format for the internet
#96Now 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.
Re: Pik – a new lossy image format for the internet
#97Good thing Denmark is a small market as it means Dick in Danish.
It sounds like "dick" in Brazilian-Portuguese too.
Re: Pik – a new lossy image format for the internet
#98Because Webp was such a success?
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.
Re: Pik – a new lossy image format for the internet
#99Is this what Google Photos uses for their unlimited "high quality" image storage?
Google photos "high quality" means downscaling to 16MP if larger and compressing at 85% libjpeg quality level. I don't believe it uses exotic codecs.
Re: Pik – a new lossy image format for the internet
#100HEIF 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_For... [2] https://nokiatech.github.io/heif/technical.html
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.