Slashdot Mirror
Google Releases Open Source 'Guetzli' JPEG Encoder (betanews.com)
BrianFagioli writes: Today, Google released yet another open source project. Called "Guetzli," it is a JPEG encoder that aims to produce even smaller image file sizes. In fact, the search giant claims a whopping 35 percent improvement over existing JPEG compression. If you are wondering why smaller file sizes are important, it is quite simple -- the web. If websites can embed smaller images, users can experience faster load times while using less data. While Google didn't aim to improve JPEG image quality with Guetzli, it seems it has arguably done so. It is subjective, but the search giant surveyed human beings and found they preferred Google's open source offering 75 percent of the time. Smaller file sizes and better image quality? Wow! Google has done something amazing here.
We should use h265 to encode images.
who cares.. most of the bloat in today's sites comes from the javascript blobs..
This will probably be also be useful for videos.
... until they're sued by Comcast, Cox, Verizon, T-Mobile, Sprint, AT&T, Disney and my Mom over lost profits from metered bandwidth fees. After all, it worked for the Oil industry for decades...
At least the hosting costs for her p0rn site will go down.
By websites not have 20 tracking pixel GIFs, 50 different ad servers, 5 different CDNs, 10 tracking servers, and a partridge in a pear tree. Websites are built fucking stupid these days, too much shit relies on too many other sources to work correctly and if even one doesn't respond in a timely manner, the whole thing stalls.
Is the survey comparing their 35% smaller JPEG to the "original size" JPEG (starting from the same reference lossless image), or is it comparing theirs to something with the same size as theirs?
I'm impressed if and only if it's the former.
about time google started to use middle-out compression techniques, but I feel bad for the little guys they stole it from.
ôó
I'll let you give me a Rusty trombone.
Until you read the bit about it needing 300mb of ram per megapixel of input data.
I don't think we'll see any hardware encoders being able to implement the algorithm any time soon.
And certainly not running in realtime on a CPU.
They're leaving pretty soon.
There is little or no value to a full I frame anymore. These days, to handle better bitrate allocation within a video stream, it's better to avoid burstiness by spreading I macroblocks across more frames. Not only that, but I frames only provided good quality based on a timer, not based on when it was needed. So for example, a blinking traffic light might have had to be encoded as B blocks which are actually quite inefficient when handling major changes and also requires a great deal of stream latency since the forward prediction block might be quite far off in time. So, being able to inject a new I-block when needed instead of on a schedule could produce mostly I and P video while reducing latency and compensating for loss of bandwidth saved with long distance prediction with B blocks by sending less I data to begin with.
It's also nice in environments where pure I/P video can be popular and the companies delivering the media employ both spacial and temporal compression techniques as the I data when it is transmitted can be used to provide enough information per frame to allow for fast scrubbing of media in post production which would allow for better solutions than Avid or Apple codecs.
the search giant surveyed human beings and found they preferred Google's open source offering 75 percent of the time.
How many human being? It is in the research paper:
23 raters participated in our experiment.
Statistics on 23 persons seems rather weak.
Written in C but using a C++ compiler for namespace handling.
I can't provide a why or why not other than "does it really matter?"
Yes, A page should not contact more than 5 or say x count of other sites. First come first listed in the source code basis
I looked at the code and it looks like they allocate a ton of memory, using it and then keeping it around without freeing it. There seems to be the habit of using data in one step and then copying the data to a new block of memory and using the copy for the next step. There could probably be some large gains through fixing the use of memory like that.
Web data is transferred either as text, as ZIP streams or as DEFLATE streams.
So if you want to reduce the transfer size, most browsers will send a header : "Accept: Zip, Deflate...", and Apache will automatically compress and send the data in zip or deflate when configured to enable the feature.
So this isn't as useful as you might think. But it *will* replace other libraries for the same purpose and you'll see it pop up in other products.
*HOWEVER*, can someone check the code to ensure it doesn't put tracking data in based on the PC's its run on, because this is Google and they ram their tracking shit down everyones throats.
The original version was written in Rust...it's still compiling.
I dare you to read TFS.
>If you are wondering why smaller file sizes are important
>If websites can embed smaller images, users can experience faster load times while using less data
>Smaller file sizes and better image quality? Wow!
It's incredible to think that someone actually wrote this for a slashdot submission, and that it was approved. As I typed this I immediately thought it must have been approved by BeauHD.
Yes, A page should not contact more than 5 or say x count of other sites. First come first listed in the source code basis
So then the sites would sacrifice the content and serve only ads?
I never thought I'd ever see the day that a large international corporation gives its product a Swiss-German name.
"35 percent improvement over EXISTING JPEG compression."
Just so you know
No shit, sherlock. We know that part. I'm asking about what the survey compared it to.
There is no algorithm that can decide jpeg in real-time. The reason for this is that an image is an instant. It doesn't have a duration like video. Most other jpeg compression algorithms are also relatively slow.
Note: Guetzli uses a large amount of memory. You should provide 300MB of memory per 1MPix of the input image.
Github
No it's not written in Rust, do not be silly. Who wants to install all the bloated self-referential wankery that makes up the Rust toolchain?
It is written in C++, as is butteraugli the library it depends on. So to compile butteraugli you first need install bazel*, Google's build tool which itself requires a Java runtime...
.
.
.
.
* actually there is a makefile included for the 3 files comprising the source code, but it's nowhere near as enterprisey as installing bazel and Java. Just look at it...
I don't know what the survey compared it to. But I did a quick test with the same result.
Source: https://en.wikipedia.org/wiki/... (a resized version was used)
Input Image: ../zayapa.jpg JPEG 1608x949 1608x949+0+0 8-bit sRGB 1.097MB 0.000u 0:00.000
Output Image: zayapa.jpg[1] JPEG 1608x949 1608x949+0+0 8-bit sRGB 641KB 0.000u 0:00.000
Only "gotcha" is:
$ time guetzli ../zayapa.jpg zayapa.jpg
real 5m39.725s
user 5m35.340s
sys 0m4.188s
It is a relatively low-end Pentium processor, but still over 5 minutes to compress a 1MB image is too high.
Bullshit. MJPEG is used in almost all security cameras running at 30 or 60 fps in real-time.
I just tried it out on a 550kb jpg and it reduced the size to around 450kb. It looks nearly identical except a few pixels maybe moved in some dark areas - only noticeable when switching back and forth between the two.
and put everything behing BPG. There are no longer any requirements for license or royalties for the use of the HEVC components for most cases of decoding BPG images. Now is the time to get rid of decades old image formats.
That's right. I'm that one asshole using OGG and annoying people with it.
The preceding post was not a Slashvertisement.
Lossy compression of javascript works fukin awesome.
If you're referring to minification, I'm inclined to agree. It loses variable names and internal comments, compressing them to a table mapping minified JavaScript files to their source code.
Its called NoScript. Loses it entirely!
Installing that and then not whitelisting any sites makes interaction with web applications require a full page reload for each update. Good luck getting web-based chat to refresh in a timely manner or making web-based image editing programs respond quickly without script. I assume that web users who find full page reloads inconvenient outnumber web users who are paranoid about a site owner running code in a sandbox on the user's computer.
There is little or no value to a full I frame anymore.
Adding more intra-frames reduces the time that a throbber is displayed when the user has chosen to seek to a different point in a recorded video or join a live stream in progress. And as you pointed out, "scrubbing" is the upper limit of seeking speed.
I frames only provided good quality based on a timer, not based on when it was needed.
That depends on the video encoder. Older real-time MPEG-1 and MPEG-2 encoders had a rigid "group of pictures" (GOP) structure that inserted I frames on a timer. Apple's HTTP Live Streaming breaks a video into a playlist of four-second segments, each of which needs to start with an I frame. But if you don't plan to let viewers seek or join a live stream in progress, you can use automatic keyframe detection with I-to-I intervals capped in the hundreds of frames.
A page should not contact more than 5 or say x count of other sites.
By "other sites" do you mean other origins, where an origin is a (protocol, hostname, port) tuple, or other registrable domains as defined by the Public Suffix List? For connection overhead purposes, you want origins, but for privacy purposes, you want registrable domains.
Video keyframes already use newer algorithms than JPEG that are about twice as space-efficient for the same quality. There were attempts to use them on the web that got bogged down by patents, but "webp" is a VP8 keyframe:
https://groups.google.com/a/webmproject.org/forum/#!topic/webp-discuss/Dj8UGeaHDAY
it's better than this release. The news here is some moderate space savings without changing the decoder.
There are no longer any requirements for license or royalties for the use of the HEVC components for most cases of decoding BPG images.
Citation? And what license is required for encoding, such as a server that makes BPG thumbnails of uploaded JPEG or PNG images?
https://www.youtube.com/watch?...
Google becomes Hooli? They just discovered middle-out compression?
Pied Piper was years ahead of them!
I just gave this thing a try on a Win7 x64 box on a Core i5 3770K @ 3.4 GHz, and the results are... interesting, but not in a good way.
First, I tried to explicitly use a quality level of 78% to test it against some low-quality images, and the program immediately yelled at me that if I want to use a setting below 84%, I need to modify the source code and recompile. WTF? Do we really need idiot-proofing of command-line utilities, too? Second, I found out that setting a quality of 88% actually sets the quality much higher than 90%, resulting in huge, HQ files. I have no idea how they determine the quality from the command-line flags as I haven't looked at the source, but apparently this program is pretty buggy. Unsurprisingly, like most programs these days, Guetzli only utilizes one CPU core, so it will be slow, but at least it won't lock up your machine while it works.
Anyway, compared to the default Photoshop "save for web" feature, this program makes files about the same filesize, but takes about 200-300x as long (roughly 1.5 minutes for Guetzli compared to less than a second for Photoshop). All my test images were between 0.5 to 1.0 megapixel, and consisted of gradient shaded cartoons and a few shaded pencil drawings, which normally show horrible artifacts and are difficult to compress well. For the images I used at 90% quality, there's apparently no real advantage. I couldn't get the quality settings in Guetzli to work correctly, so I did the runs with Google's tool first, then made comparable images with Photoshop to match the quality. File size differences were less than 10%. I did find that that Guetzli prioritizes chroma over luminance, so strong colors have fewer artifacts, but base colors and B&W patches have more artifacts and are blurrier. The net quality is about the same overall, so this tool is disappointing. If you're going to use this utility, it's best reserved for highly saturated pictures, but overall I didn't see any gains in compression.
If you're looking for serious gains in compression, you're better off using PNGOut by Ken Silverman to crush PNG files. It's usually not worth trying to get more compression out of JPEG files over a utility like Photoshop, Irfanview, or ImageMagick. Even JPEGTran never gave me any significant gains over Photoshop's JPEG routines.
It is a relatively low-end Pentium processor, but still over 5 minutes to compress a 1MB image is too high.
Is it? It only has to be compressed once and put on a website, where it will be served to a million browsers and decompressed a million times. Does decompression take any longer?