We took the technique of “simulating” alpha channels in JPEGs with SVG one step further and made it even easier to use with rokka. Now you just have to set the jpg.transparency.autoformat stack option to true and rokka will return the most appropriate format, if the rendered image has a visible alpha channel. No need to build the SVG on the client side anymore.
Compared to the approach described last week, we had to include the actual binary images with a data-uri attribute. Most browsers don’t load remote resources defined in a “remote” svg. This will make the SVG response quite a bit bigger than the binary formats, but gzip compression helps here enough.
Another obstacle was detection, if the client actually supports SVG. Firefox and Safari for example just send “*/*” in their accept header, when requesting an img in HTML. But consulting Can I use? revealed that browsers not supporting that are very much negligible. Therefore, rokka will now return a SVG, as long as there is “*/*” in the accept header (or image/svg+xml is explicitely mentioned), when this stack option is set. Unless the browser states that it knows how to handle WebP, then we return that (since that’s still smaller than the SVG approach). If no accept header is set (or no */* is in it), we return the whole thing as PNG.
All this only applies if you request a jpg, set the right stack option and the rendered image has a visible alpha channel. In all other cases, there’s no magic applied and just the stated format is returned (meaning for example, it’s delivered as normal jpg, if there’s no visible alpha channel).
Inspired by this blog post by Peter Hrynkow, we implemented some new features to rokka to provide a solution to his question “Wouldn’t it be great if you could get the compression of a JPEG and keep the transparency of a PNG?”. There’s a new operation now in rokka, which allows you to extract just the alpha channel as a mask.
Let’s take a picture. A PNG with an alpha channel surrounding the screen. It’s 24 kB large (due to the use of pngquant and zopflipng on rokka here, it’s smaller than usual, without those it would be 95 kB). The green pattern is the background and not part of the image.
This is just the JPEG of it, but it lost transparency in the process. Just white, no green pattern, not the desired result. But it’s only 12 kB in size.
(as a side note, with lossy WebP, which supports transparency, the size would be in the same area as the JPEG one, just with transparency included, but that’s not the topic here, since only chrome supports WebP)
Now with the solution of Peter, we need a PNG with just a mask for where it should be transparent. rokka can create that automatically for you with the same source image uploaded before, no additional work needed. The mask PNG has a size of 5 kB
The mask PNG and the JPEG together have a size of 17 kB, smaller than the initial 24 kB of the original PNG (or 95 kB unoptimized). For bigger pictures, the gain would be significantly more. And all you had to do is to upload one image with the correct alpha channels, create initially two different rokka stacks and an svg snippet. The conversion then is done automatically by rokka.
A little remark. As you can see, there’s a little shadow below the screen in the alpha channel. This one is hardly noticable on the SVG version, due to more or less “double” transparency. We couldn’t come up with a quick solution for this problem, but are happy to look into it, if anyone is depending on that. In short, this approach produces best results, if you only have 1-bit transparancy. For other cases, there may be small differences in the output.
Apple produced quite some hype with their support for the HEIF image format in the upcoming iOS 11 and macOS High Sierra. HEIF (High Efficiency Image File Format) is a new image file format, which supports many use cases and uses HEVC for the compression part, also known as H.265. Apple is using HEIF on their latest devices as a replacement for storing pictures and claims up to 50% saves on storage.
Even though no browser does support HEIF yet, also not Safari in the current betas, we nevertheless thought it would be cool to add HEIF support to rokka – our image storage and delivery service. And so we did.
Unfortunately there’s no out-of-the-box solution to create HEIF files currently. But Ben Gotow‘s site jpgtoheif.com inspired us. He published instructions how to create HEIF files with the help of ffmpeg, x265 and Nokia’s heif writerapp. But due to the uncommercial-only license of that Nokia code, we use GPAC to create the HEIF container, which is published under the LGPL license.
Looking at and comparing HEIF compressed images
What’s the fun, when almost no one can look at the result? So we built a little site, where you can compare the output of rokka’s HEIF, JPEG and WebP (the later is only supported on Chrome) and even upload your own pictures. Just head to
and enjoy it. The uploaded images will be deleted from time to time.
The site also allows you to play with different quality settings. All formats support a setting from 1 to 100. 1 is the lowest and 100 the highest (also means lossless for WebP). The different quality settings for the different formats don’t really correspondent to each other. Just play around with them and compare the sizes of the images with different settings.
We use pretty much the default settings of ffmpeg, maybe some stuff could be improved on that side. And we also don’t know what kind of encoder Apple is using for generating HEIF images. So don’t really compare the compression we produce for HEIF images with what maybe other encoders can do.
Also be aware, that we asynchronously compress JPEG images in the background with mozjpeg (see the rokka docs for details), so the first render output is not the maximized compression we can get for JPEG images. Just hit the render button 10 seconds later to get the final compression (the site will inform you, when it’s not done yet with that compression step).