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).
For an internal tool, we’d like to allow access if you either coming from one of our office networks or you have a certain cookie set. If both are not satisfied, just show the usual basic auth dialog. And set that cookie, once you were allowed to access the page.
We wanted to do that in nginx and not the tool itself, as it looked like easier to do, especially since the tool didn’t have any authentication at all yet. Unfortunately it wasn’t that straight forward, but we found a working solution and wanted to share that.
192.168.0.0/24"yes":#some network which should have access
10.10.10.0/24"yes":#some other network which should have access
Update: Since 7.0.0 is officially out, we updated our binaries as well with the final release.
PHP 7.0 is very very near, if no showstoppers show up during the current Release Candidate #8. And I finally managed to update the package on php-osx.liip.ch, so that you can test and start writing applications on your local OS X machine easily, as well. The installer also automatically does the right thing in the apache configuration with regards to “mod_php7” and “mod_php5”.
Furthermore, since we are using CloudFoundry in one of our bigger projects, I also extended the official PHP buildpack to include PHP 7.0 (and some other things like varnish, but that’s not relevant for this). This way we can easily see, if our apps still work with PHP 7 and do some benchmarks (the initial ones looked promising). To use the buildpack, add the following line to your manifest.yml
and adjust .bp-config/options.json to include (and maybe also change your composer.json to use PHP 7)
Be aware, that I didn’t port many of the extensions the official buildpack includes, so your milage may vary. And if you want to be sure it’s thoroughly tested, maybe better wait for official PHP 7.0 support in the CloudFoundry buildpack. I’m sure, they won’t wait long once it’s is released.
There’s now no excuse anymore to not test your apps against PHP 7.0
“Self-managed companies” or “teal organizations” are a hot topic in many circles. Especially the books “Reinventing Organisations” and “Holacracy” are among the bestsellers in that area.
We at Liip try to be somehow self-managed since quite some time, it comes quite naturally with being agile. Teams (between 5 and 20 people) can decide a lot by themselves already. But of course, there’s still a management on top, which decides about company wide things and also not so company wide things. We now started an active discussion within the company (for example with a session at the last LiipConf) about how it could work, without such a central, top-down management. We haven’t figured out the details yet, but we’re very eager to try.
But we’re also very interested to get to know people who are already doing that or also want to try it. So, please get in contact with me, if you’d like to meet.
To get an idea, what I personally mean with “self-managed company”, here are some questions. If you can answer them with yes, you’re pretty self-managed (in my opinion)
Does your company not have a top-down management?
Do you have no hierarchy and fixed roles, especially not through job titles?
Can people in your company decide on their own without approval from someone “higher up”? Also for investments?
Are there no fixed budgets defined from above/centrally?
Do people decide about hiring and firing?
Do people even decide about their salary?
Are you more than “just the founders”? (not sooo important, but maybe for a future growth of your company)
Do you have a process to solve conflicts, so that not the one with the bigger voice always wins?
Can anyone take responsibility where they want? Define their own roles?
Don’t you always try to find a consensus while not trying to please everyone?
Do you trust everyone in your company that they take the right decision at that current time?
One important thing in all this is, that “decide on their own” doesn’t mean, they can just do whatever they want or what feels right. There are many different ways to approach this, but the most important part in all of them is, that you have to get advice from the others before deciding something.
The public transport app “Time for Coffee!”, made by some Liipers, was finally published at Github under the MIT License. Furthermore the Apple Watch app for it was also released last week, just in time for the watch release in Switzerland this Friday.
After we changed silently to using WordPress a few weeks ago for this blog (from the ageing Flux CMS software), we now also upgraded the server software to the latest and greatest versions. We finally use HHVM 3.6, nginx with SPDY 3.1 support, deliver everything in SSL only (but of course redirect from port 80), updated our certificate to use SHA256, disabled all “known-as-weak” ciphers and protocols (sorry IE 6 users), do OCSP Stapling and even send an HSTS header for being extra secure. We also switched to a server not on the edge of the continent anymore and deliver it additionally via IPv6.
With all that, this site should be faster and more secure than ever. Enjoy!
(We also applied the SSL/SPDY settings to www.liip.ch, so you may enjoy a better experience there as well)
Jan Hug, Cyril Gabathuler and myself worked hard in our free time the last few weeks on an iPhone app for the great website timeforcoffee.ch, a private project started by François Terrier and his friends Serge Pfeifer, Jean-Luc Geering and Kristina Bagdonaite. It also has newly addded support for the upcoming Apple Watch. As this is a project done by Liipers and non-Liipers alike, we talk about it more on medium.com, go and read it! And apply for the beta and follow us on twitter: @time4coffeeApp