This project has less practical value that I'd like to admit, but I decided to go down the rabbit hole of trying to figure out how to create simple GUI for a bash script. This script takes a retina image and down converts into a plethora of formats. Perhaps one day this could be wedged into a straightforward Xcode project that gives it a real GUI and thus more options. I merely ported my my CodeKit 3 hook to an independent shell script and added Zenity after exploring a few options. Notably, there is no error catching.

Dependancies

    brew install imagemagick --with-openjpeg
    brew install webp
    brew install mozjpeg
    brew install zenity
  

GitHub Jist

Updated for 2019

An oxymoron can occur in a year, everything and nothing can change. That's exactly what happened since I wrote this guide in late 2017. Now in January 2019, I figured it was time to update this guide.

I've had an affinity for image optimization, going as far as to test out Google's guetzli, a hyper-optimized JPEG encoder and running a comparison of ImageOptim vs. Squash 2. I decided to revisit something I've meant to test out: Alternative image formats.

For those who aren't as versed in image compression, our choices are familiar for bitmapped images: JPEG (lossy, no alpha), PNG (Can do alpha, optimized by pre-processing with lossy strategies), BMP, and GIF (LZW and a complete waste of bandwidth). However, there are other image formats that browsers support:

• JPEG 2000 (Safari 5+) - supports alpha, RGB/CMYK, 32-bit color space, lossy or lossless
• JPEG-XR (IE9-11, Edge) - supports alpha, RGB/CMYK, n-channel, lossy or lossless, progressive decoding, 32-bit color spacing
• Webp (Chrome, Opera, Android Browser, Edge 18+, Firefox 65+) - supports alpha, lossy or lossless.

If you're keeping score, you're probably noticing two things: That's a fractured landscape, and FireFox wasn't mentioned, both are true. When I first wrote this guide, FireFox hadn't backed a format, and instead chose to write its own JPEG encoder (MozJPEG) that offers a 5% data savings as opposed to adding support for WebP, or either JPEG format. However, in FireFox 65, on target for early 2019 will soon support WebP and with Edge switching to Chromium comes WebP support.

So far no browsers support HEIF (high-efficiency image format), Apple's newly preferred image capture format for iOS, although I documented recently the fate of its support on macOS recently. (it's actually quite good).

From my experiences, avant-garde image formats shouldn't necessarily be viewed as saving pace so much as delivery more quality at the same file size as each format seems to yield varying results, especially in the cases of JPEG2000 and JPEGXR, as drastically reducing the file size will produce so-so results. However, comparing like images at the same file size, both yield better results highly tuned JPEG libraries like MozJPEG or guetzli. As a general rule, you shave about 10% off of a JPEG (after optimization) with JPEG2000/XR to deliver like results, JPEGXR being the laggard of the of the two. WebP tends to deliver like results at slightly better file sizes.

Combining classic bandwidth saving strategies like: minification of CSS, uglification of js, lazy loading, inlining the crucial CSS to speed up time-to-paint, and such with avant-garde formats can shave off hundreds of kilobytes.

Looking forward: WebP, HIEF, and AVIF

When I wrote this guide, Internet Explorer had a bit more of a foothold, and it was unclear of Edge would manage to dig itself out of its hole. JPEGXR's future also is unclear if Microsoft will continue support for XR now that it's moving towards WebP. For the obsessive or people with user bases with heavy Internet Explorer usage, JPEGXR is still an option, but for everyone else, I'd skip JPEGXR moving in 2019. hen there's BPG and FLIF, which no browsers have embraced nor announced support for, effectively banishing them to the realm of the forgotten.

Apple is the only WebP holdout and has not announced plans to support it. In the iOS 10 beta and macOS Sierra beta, Apple tested WebP support but removed it before finalizing support. Strangely, despite Apple's investment in HEIF, it's not even supported in Safari's technical preview. I'm not holding my breath for WebP support on Safari.

Lastly, WebP might a be a bump in the road to AVIF (AV1), a royalty-free open joint venture from engineers at many firms such as Mozilla, Google, Cisco and so on. FaceBook raved about AV1 as superior to x264 and VP9 video formats. Mozilla plans on supporting AVIF, so at least one major browser is onboard with others likely to follow. The results look promising although, like all things in compression, there's rarely a clearcut winner.

Quick Primer

There's plenty of other places that perform comparisons, but the long and short is that per kilobyte. JPEG2000, JPEG-XR and WebP deliver considerably better images than JPEG and (often) PNG, and it doesn't take too much effort. I'd recommend reading the following, David Walsh's WebP images and Performance and playing with the incredibly nifty a format comparison tool.

All three image formats do not require any purchases although JPEGXR is the most cumbersome of the formats on macOS.

What you need:

• A high-quality source file (preferably lossless)
• JPEG-XR: Microsoft provides a free photoshop plugin that can be downloaded here or nab XnView
• WebP: WebPonzie provides the most painless and easy to use solution. XnView also has WebP support. A small company, Telegraphics, also provides a webp plugin. I had minor issues with it.
• JPEG2000: Photoshop, Preview both have native support. XnView also has JPEG2000 support. (I've had the best results using Apple's Preview for whatever reason)

Since there isn't a excellent singular solution, you'll need to open the high quality source image and open the image in the listed programs. Photoshop can handle exports to all three formats (with the aforementioned plugins) making it the closest to a one-stop solution, followed by XnView (which can be cumbersome). With JPEGXR's fate in future Edge iterations hanging in the wind, WebPonzie + Apple's Preview is completely viable.

ImageMagick

ImageMagick is the other one stop solution, and it's a CLI utility, quite powerful and fast although occasionally a little obtuse with the flag options for each file format to toggle features like lossless or target sizes. Depending on your terminal comfort, this may be the easiest method. Getting start however is pretty straight forward.

The easiest way is to use Homebrew, a package manager for mac CLI utilities. If you have Homebrew already installed, run the following commands in your terminal (install both ImageMagick and webp), otherwise go to the afformentioned link:

    brew install imagemagick --with-openjpeg
    brew install webp
    brew install jxrlib
  

Imagemagick includes several CLI utilties, but the one we're concerned with is convert. Converting a file to webp looks like the following:

  convert path/to/file.png -quality 50  path/to/new/file.webp
  

The same goes for JPEG2000 and JPEGXR it requires using the correct extension. Tweaking the quality takes tinkering for each format.

  convert path/to/file.png -quality 50  path/to/new/file.jp2
  

• ImageMagick WebP options flags
• ImageMagick JPEG2000 optionsflags

The markup

Adding multi-format support doesn't require much, just a picture element. Below is an example of a simple picture. This can be mixed with srcset.

  <picture>
    <source type="image/webp" srcset="path/to/image.webp">
    <source type="image/jp2" srcset="path/to/image.jp2">
    <source type="image/jxr" srcset="path/to/image.jxr">
    <img src="path/to/image.jpg" alt="alt description">
  </picture>
  

Final Thoughts

Really, that's all it takes. Notably on macOS previewing JPEG-XRs is a pain and on it's way out, whereas at least WebP can be previewed in Chrome. It takes Photoshop or opening a JPEG XR in XnView then going to the actions tab, applying a filter so you can view the original JXR file (it's cumbersome). I created a CodeKit script to automate WebP and JPEG2000 and CLI bash script to convert images to WebP / JPEG200 / MozJPEG using ImageMagick. At the very least, you'll be providing better images at the same file sizes as a normal JPG. JPEG XR likely on the way out, even if its still supported by Edge. JPEG 2000 will never be embraced by the industry at large. WebP has a lot of traction these days. HEIF and AV1 though might soon replace WebP. JPEG isn't going anywhere, anytime soon.

• Jan 21, 2019 - added ImageMagick information
• Jan 14, 2019 - rewrite of about 1/2 the content, restructured and added information about future formats.
• Aug 17, 2017 - Correction on JPEG 2000 and SRCset
• Jul 26, 2017 - Original article published

Last week I had an interesting conversation with a co-worker. She had taken her laptop to Apple. Apple restored her computer but it wiped her iTunes library, and she was confused as she assumed she'd get her music back. She doesn't have Apple Music or Match, but he did get some of it back. She only has the free iCloud 5 GB library which was sufficient to restore most of her docs, and the rest were on cloud services like Google Drive (as our office uses Google Drive). Add in another layer, Apple allows all music purchases to be redownloaded but doesn't extend the service to users without buying match. While hardly an Apple apologist, my knee-jerk reaction was "Well, yeah, you have to pay for it." However, I kept thinking about it after the conversation. Expectations being what they are, media is no longer finite. It lives and always lives: Spotify, Apple Music, Google Play, Netflix, HBOGo, Hulu, Audible, Amazon Kindle, Apple Photos, Google Photos. While we do not expect physical books, CDs/Vinyls, DVDs, Blu-Rays, Photo albums to magically exist in vast media centers, the cloud hype has given a strangely disconnected permanently ephemeral (ephemerally permanent?) quality to digital media; that it should be forgotten until remembered. Google already gives away music/photo storage for free, and Amazon does as part of it's mostly buried Prime services so why doesn't Apple?

iTunes has been a mess for years, and there's been a cottage industry of music purists who've abandoned iTunes, with utilities like Waltr, PhoneView, iMazing, and the music players Swinsian, Tomahawk and Vox Music Player. Perhaps match should be the driver to keep people in the iTunes sphere.

While it's nothing new to point out the brokenness of iTunes, iTunes Match should be a killer feature provided for free with iTunes long as you're using an Apple ID as a free service or included as a bonus for anyone who pays for iCloud regardless of the storage tier. It's confusing and disjointed for the average user.

It's not every day I discover a task manager GUI utility that I haven't heard of. Apparently, today is such a day as I randomly came across SqueezerApp, a minimalist pre-processor.

Pictured: Main app window is sparse

In my previous reviews of GUI task managers for front-end development, I went so far as to write glossaries for them so novice readers could find the reviews more accessible. However, due to the narrow lens of this utility, I'm going to skip this. I highly suggest novices read my review of CodeKit 3 as it goes far far more in-depth than this review ventures into the world of task managers, preprocessors and code compiling. I do my damnest to make my reviews effable, convert esoteric front-end web developer speak into human speak rather than pointless pontification. I'll be using words/phrases like task manager, minification, and uglification, with the assumption that you are already familiar with them or you've skimmed through CodeKit 3 Review.

Squeezer is the most minimalist task manager I've seen to date. For a course refresher: Task managers are programs set to execute pre-defined actions based on events. These events can be chained to many behaviors, but the most common is by manually triggering (usually by a terminal command or in GUI apps, via a button) or when a file is changed. The most common are terminal based applications that do not include GUIs such as Grunt / Gulp / Webpack and are used to compile pre-compiler languages like Sass or TypeScript into browser readable CSS and Javascript. These pre-compiler languages offer benefits of syntactic sugar (making code easier to read/understand) and ability to perform shortcuts to simplify development. This is only scratching the tip of the iceberg when using task managers as they can be configured to do highly specialized tasks like scanning for unused CSS or spin up a headless browser to perform visual auditing. The problem though is that these task managers take a lot of overhead to set up. For junior developers, it may be more important to focus on coding than tooling. For seasoned developers, it may not worth the time investment to create the tooling for a small project.

Capitalizing on the need, both CodeKit and Prepros have filled the niché of GUI task managers, (and quite well I might add). CodeKit 3 is powerful enough to be viable in a professional environment, and my review of CodeKit 2, I used CodeKit 2 off and on professionally for 9 months (mixed with Grunt). However, GUI task managers do not offer the flexibility of Grunt, Gulp or Webpack. GUI task managers are about ease of use as most users find GUIs far more intuitive than using a terminal and text configured files. The value that a GUI task manager is the simplicity and ease of use it brings.

Pictured: General settings only allow one single path to export compiled code/images to.

The Review

Squeezer's website is a bit low on info. There's no information as to what engines it's using to process files, versions of compressors and so forth. It's a mystery box and poking inside the app reveals little. The website is almost a non-entity, and it's developer, Yanis Zafirópulos lists himself as "Dr. Kameleon", adding to the mystery.(If there's ever a red flag, it's someone who calls themselves a doctor without a full Ph.D.). Also, Chameleon? I could infer plenty more. To be clear, I'm joking... I doubt that there's any ulterior motive to less transpicuous.

Part of the reason I'm learning just now about the application is that there are several "Squeeze" named OS X applications, like the high-end video compressor, Sorenson Squeeze (formerly Squeezer), PDF Squeezer, and a few other utilities making for a tough SEO battle. Finding the official website takes more google-fu than one would expect.

Squeezer supports the following:

• HTML: Minification
• CSS: LESS, Stylus, Scss/Sass and CSS compiling/minification
• JavaScript: ES6, CoffeeScript or TypeScript compiling/minification.
• Images: PNG, JPEG (compression), SVG (minification)

Unlike CodeKit or Prepros, Squeezer isn't made for monitoring your entire project. Typically, with CodeKit or Prepros, the setup project looks something like this:

• Drag project folder into application window and wait for a second for the application to scan your project
• Via the GUI's folder structure, click on the parent Sass/Less file, JS file and set the output locations. Configure JS concatenation.
• In the project settings, enable/disable features like Linting
• As long as CodeKit or Prepros is open, it will compile your code. The application will remember your settings and create settings a file in your project folder that can be distributed with your project so others can quickly jump in with minimal configuration.
• Errors are logged in a central error log. The error log highlights problems in your code

Squeezer is significantly different. Squeezer only wants to know about your parent files. Dragging the entire project into Squeezer will create unexpected results, creating a bunch of partials of compiled code. I made this mistake when testing it and ended up with a CSS file matching every Sass file in my project, plus the properly compiled code when it hit the parent most CSS file. To make matters more confusing, if you enable file watching, Squeezer will not automatically trigger files unless the parent Sass file is manipulated. Even on single page sites, I like to divide up my Sass into separate .scss files. The shortcomings are immediately apparent, as I'm used to Gulp / Grunt / Webpack / CodeKit / Prepros which watch all your Sass and/or CSS and/or JS and recompile your CSS / JS whenever any of said files are manipulated. This isn't simply a preferred methodology, is the most sensible as you never have to remember to trigger your CSS or JS builds. Everything happens automatically.

So this leaves Squeezer in a strange space. It's a minimalist utility, but it also is more work to use. If you're simply looking to process Sass files in a project just once with the aid of a GUI, I still find CodeKit and Prepros easier.

Pictured: There's a few mystery options such as "advanced optimizations" and "remove all special comments except the first one."

Squeezer doesn't offer a proxy server either to inject your CSS changes, or trigger reloads when your JS/HTML (or other assets like Python/PHP) changes. Quite simply Squeezer is the most minimal task manager.

Who is it for?

If you only need to compile one type of code, then perhaps this is the GUI utility you've dreamed off. Just drag in the parent file, and it'll recompile on saves or perform a single compile. The problem is, I don't know anyone who works like this.

Lastly, it's worth mentioning that Squeezer is the cheapest of the GUI utilities.

Pictured: JS options are thin

Final Thoughts

Several things jumped out at me while writing this review:

• The one day trial for a development utility feels mildly insulting. I wanted to test the software and found myself against the gun to test it. I'm unwilling to pay $15 for something that I'm unable to even test drive properly. In fact, I may have missed settings and may have some inaccurate information in this review.
• Squeezer is not as easy to setup as CodeKit or Prepros nor does it have an easy way to specify multiple paths for individual file types.
• Little documentation, no real support to speak of and a few "mystery" options that'd require me looking at the code to see what they do. I didn't have time to test all options. My review contains more information about Squeezer than its documentation.
• Even at almost half the price of its competition and functionality, it's not a viable utility outside of the most bare-bones projects.
• Image optimization actually managed to INCREASE file sizes of many PNGs and JPGs run through ImageOptim and proceeds to overwrite them with the larger files. If image optimization is increasing the file size, then it shouldn't bother to apply changes.
• Squeezer logs inaccurate minification stats for Sass as it compares the parent file vis the entire compiled CSS, rather than unminified compiled CSS vs the newly minified CSS.
• There's no error console, and files that shouldn't have compiled still compiled.

Pictured: Squeezer did a great job with vector images but ended with questionable results with PNGs

I hate to trash on an indie developer I but just cannot recommend Squeezer when CodeKit and Prepros exist, even at double the price. I do think there is room for an even more simple task manager than CodeKit or Prepros but I found Squeezer too simplistic to mimic a workflow even for a very straightforward static website. It may fit others workflow and it has a free trial but even that has its shortcomings of being laughably short, making it difficult to evaluate if there are workable patterns for Squeezer. Add in the lack of documentation or clarity on the compiler versions, no proxy serving/live-reload and stupid logic on image compression, and Squeezer is a bit of a dud. It functions as advertised but without much grace. Squeezer feels like a beta more than a refined application.

Moving Forward

Pictured: The Misc options mostly should exist under other tabs like "Just compile".

Squeezer isn't a total bust, it performs the tasks it purports to do but without any finesse. It really wouldn't take much to make this utility a viable solution. It's a good start and perhaps it could be a useful task manager if just a few things changed. The biggest changes I'd ask for out the gate are:

• Allow multiple export paths, at the very least by file type. Compiled JS goes into JS folder, compiled CSS goes to CSS folder, images go to the images folder, etc.
• Extend the CSS/JS watch to include imported files or allow the entire directory to be moved into the project window.
• Clean up the options; it's baffling that there are "just compile" options in the Misc tab instead of under the file types they pertain to.
• Add in an error log. I didn't see an. The file size savings is misleading if Sass files or JS files contain imports. The app either should compare the compiled file against all the sources or not at all.
• Add at the very least live-reload support (CSS Injection would be nice)

Adding those five features would make this usable and inexpensive alternative.

Version Reviewed: 2.0

Price: $15

Website: squeezerapp.com

I don't post much in the way of code on my blog, most of my tech posts are bug fixes or esoteric configuration. I’ve been sitting on a nifty sass mixin for about two years. and I've recently ported it to codepen. It’s clever for color theming elements. What it requires is:

• A predefined list/set of colors
• The desire to use all of these colors on multiple CSS attributes (borders, backgrounds, color, etc) and UI elements
• A simple way via CSS to set the color dynamically

See the Pen Sass parent mixin by Greg Gant (@fuzzywalrus) on CodePen.

Sass doesn't have arrays. Thus you need to iterate through multiple lists, one to define the CSS name and one with the corresponding color value. This can be taken further so other elements on a page could use other themes, even if the parent theme is different.

See the Pen Sass mixing by Greg Gant (@fuzzywalrus) on CodePen.

In no way is this limited to colors only, this could be done with lists of any attributes and values.

This is a slightly belated follow up to "Thoughts on Front End Development in late 2016". The idea is to chronicle thoughts I've had between the last time I wrote about front-end development by quarter. I like to pretend this blog is about front-end development and not random hacks for emulators, pining for new Mac Pros and audio gadgetry.

• I finally used Docker on a project and its wonderful (I'll admit I did not do the tooling to set up the container). It'd be interesting to try and fold in the front end techs into a docker container.
• Chrome is kinda glitchy again when dealing with React. I've had better luck with code injection on Safari the past few weeks.
• • I set up Webpack for our two apps at my company. Webpack is mysterious (unlike piping in Gulp) but damn if it isn't necessary for React. I even saved the day for a coworker with custom fonts. It turned out to be configuring MIME types for font loading. It really shouldn't be this hard, but it is.
• I started on another side project like CSSFilterGenerator.com, and it'll be on React.
• I'm happy to work on another Django project. I wish I had more projects with Django.
• Drupal 8 should be headless and do away with its own goofball templating. Ship it with popular templating options.
• For the first time I'm (almost) full stacking a site (at my current job), with Expression Engine.
• The next step for React and me is getting into Redux.
• Windows 10 S makes me sad. It means Edge will gain market share. It's also pretty much an anti-pattern, desktops are open, and Windows best strength has been: its huge library of software. Limiting it to the Windows Store is pretty much terrible, sure its $50 to "unlock" it but if I were Apple, I'd be laughing myself to sleep.
• I wish Node apps idled better.
• Changing OS X to target tabs instead of new windows really has been a surprisingly big change in my day-to-day.
• Net Neutrality is on the ropes again... If there's ever an example of nepotism and a conflict of interest, its appointing Ajit Pai to run the FCC. We're living in a kleptocratic kakistocracy

I wrote this some time ago as part of a review of a Focusrite Scarlett 6i6 audio capture box, but decided to break it out into its own separate page. This calculator uses the signal-to-quantization-noise ratio formula, Nyquist frequency, and bitrate formulas to calculate various properties of uncompressed PCM digital audio quickly.

Common formats:

Maximum Dynamic Range

Pressure Level Values

Frequency Range (folding frequency)

Google posted Guetzli last month. Curious about testing it out, I decided to give it a go. Image optimization is one of the bazillion things a front-end developer needs to know something about. For the sake of sanity, I'm going to assume that readers understand that PNGs are (mostly) lossless and JPGs are lossy. However, most programs that encode to file formats often include additional metadata, or do not make the most efficient usage of the codec thus not all encoders are created equally. Perceptual encoding is tricky and thus assumptions are made within the constraints of the codec as how to interpret the input data. Based on this, there's frequently wiggle room to improve encoders to make them "smarter" and deliver better results.

Optimization doesn't end at the encoder. In the interest of delivering the smallest file possible, people have written many series of optimizations designed for existing formats, specifically for this article: JPEGs and PNGs. The easiest (and incidentally one of the most effective) is ImageOptim. Without going too deep, ImageOptim combines several popular image optimizations specific to both JPEGs and PNGs and makes it into brain dead easy optimization. It shaves off valuable kilobytes without affecting the image quality. Usually, I export assets from Photoshop or Sketch then treat them with ImageOptim and ImageAlpha (for PNGs). Often front end developers will use Grunt and Gulp tasks that use many of the same libraries that ImageOptim uses to auto-optimize images in a project. Google's Guetzli is a new JPEG encoder which offers new opportunities over my usual post-export optimization tweaks. Guetzli promises better results as opposed to simply smaller files.

I downloaded guetzli using the HomeBrew version for OS X/macOS. For my test, I started with high fidelity non-lossy phtoographs captured in RAW and converted to PNG source files.

Time tests

Rather than inline my source images, here are the below links for reference and the relative time it took to encode on my MacBook Pro 2016 2.5 GHz Intel Core i7, 16 GB RAM, at 84 quality as defined by Guetzli.

• Guetzli Test Image 1 (19 MB) - roughly 16 minutes, Result 1.7 MB, Compare against Photoshop (6 out of 12 quality) at 1.1 MB
• Guetzli Test Image 2 (2 MB) - roughly 2 minutes, Result 223KB, Compare against Photoshop (6 out of 12 quality) at 236K

Apples and Oranges

The big problem is that Photoshop uses a 0-12 quality setting which has never been very sensible. Unlike video codecs that allow you target file sizes via bit rates, there's no real way to produce file sizes at the same size a Guetzli's JPEG engine. Instead it was a guess work, trying to figure out what Photoshop quality produced nearish the same file sizes. After testing several images, Photoshop's 6 out of 12 was the most "like" setting and its highly imperfect. For my very large image, the Photoshop 6 out of 12 quality JPEG was much smaller than the Guetzli's minimum 84 setting. However, when the images were much smaller, all other tests found Guetzli's 84 quality setting producing smaller files than Photoshop's 6 out of 12 quality setting. All images were also run through ImageOptim for further optimization.

Guetzli just isn't that effective on high resolution images and at least with my test source, the differences were not very profound. I debated running Guetzli on several 16 MP images but with 16 minutes per-convert, the practical application isn't there for most use cases. This left me going back to the drawing board. I downscaled my image to represent a more likely scenario.

Zoomed In Test

The following images are screen captures of the zoomed in results of the PNGs/JPGs for comparison. Linked next to each image is the original image (prior to zooming in). Right click to open up the zoomed images for full sized images. My two main test images are both images that have large gradients, where JPG artifacting often is the most visible.

Original PNG (size 1.2MB)

Photoshop JPG (size 95k)

Guetzli JPG (size 88k)

Surprisingly, Guetzli doesn't come out ahead. You can see the gradient blockiness in Guetzli's JPG. It's more apparent viewing this on a non-Retina display or at 2x on a retina display. The JPEG blur of the default Photoshop image works to its advantage on the gradients. I certainly didn't expect Photoshop's JPEG engine to win any test. That said, the Guetzli image is 7k smaller.

Original PNG (size 2MB)

Photoshop JPG (size 236k)

Guetzli JPG ( size 223k)

Guetzli comes out ahead quite a bit in the detail of the sky, something JPGs tend to foul up quite a bit. Guetzli certainly wins in this instance and looks better than the Photoshop image.

Reactions

Guetzli is slooooooooooooooooooooow. Converting a 20 mb PNG (4,608 x 3,456) image under a normal load (a few applications open, Atom, Preview, Messages, Safari, Chrome, iTunes, Sketch, Codekit, textedit, 1password, Lightroom, Tower), cost roughly 16 minutes of CPU time on a 2015 MacBook Pro (2.5 GHz i7 / 16 GB Ram). First off Guetzli is a single thread application, occupying 99-100% of the 4 cores on my CPU. Sadly, it left 80% of my MacBook idling. Optimization for OS X is nearly non-existent.

Guetzli is designed for high quality JPGs, by default the quality slider is limited to 84. Anything else will throw up an error in the CLI. It is possible to bypass this by building the binary yourself. Guetzli also is designed to delver higher quality at the same file size than a JPEG encoded by lesser image encoder, as opposed to simply produce smaller JPGs.

Guetzli assumes the color profile for the JPEGs is SRGB with a Gamma profile of 2.2, this is the same as the default for Adobe RGB (1998) buuuut not as wide of a color space as it'll read as an untagged image color profile. Thus images you've been viewing in a different color profile may look less end up looking less saturated or vibrant or different

Final Thoughts

For static assets that rarely change, Guetzli is certainly an option but for my Front End flow, it's not going to be anything I lean on. There's certainly been some impressive image optimization utilities for JPEG over the past several years but my guess we're coming up against the limitations of JPEG. The sadistic side of me wonders if it could be used for Motion JPEG, which is eschews interframes/keyframes and thus is still a great video codec for high motion scenes.

The Mac Pro is a frequent topic in my blog as I've been a bit of an enthusiast. To this date the most read article is Recommended Mac Pro Upgrades. Needless to say, when Apple redesigned the Mac Pro 2013 as a glorified iMac, my reaction to it wasn't kind. I needed some good news today and I got it, Gruber at DaringFirelball.com came away with the biggest scoop today, and I quote:

We’re not going to get into exactly what stage we’re in, just that we told the team to take the time to do something really great. To do something that can be supported for a long time with customers with updates and upgrades throughout the years. We’ll take the time it takes to do that. The current Mac Pro, as we’ve said a few times, was constrained thermally and it restricted our ability to upgrade it. And for that, we’re sorry to disappoint customers who wanted that, and we’ve asked the team to go and re-architect and design something great for the future that those Mac Pro customers who want more expandability, more upgradability in the future. It’ll meet more of those needs.

While the word "PCIe" isn't present, expandability and upgradability show up in the above quote, inferring hopefully a return to towers. My 2008 Mac Pro is still going strong and remains easily the best computer I've ever bought, and quite possibly the most over-engineered beautiful computer to date, down to the RAM upgrade trays, to the dual CPU, dual bus design that has made it a viable computer for almost a decade. It's a problem that Apple left us all wondering about it's fate.

If they're releasing a new Mac Pro, with a few PCIe slots and drive bays, I'll be the first in line to upgrade.

You can read the whole thing here

I created a photoshop action after being annoyed with favicons and all the variants. It's on GitHub for download. There's quite a bit to it but it creates 13 icons in total. The support list is loooong! I tried to cover everything and this includes (but not limited to): IE11, Edge, Chrome 4+, FireFox 2+, Opera 10.1+, Safari 3.1+, iOS Safari 6+, Google TV, Android Browser 2.1+, Chrome for Android, FireFox for Android, UC Browser for Android, Samsung Internet, QQ Browser, Chrome Store, Windows 8+ pinned sites.

Install

1. Download the Photoshop Action and double click to decompress
2. In Photoshop in the actions menu, click the hamburger menu and select load actions
   
3. Locate the Favicon Creator

Using the action

The default image must be square and above 228 x 228 pixels (I personally recommend using higher than this). Click play and the action will create 13 icon sizes in PNG.

Optimization

Unoptimized PNGs from Photoshop tend to be quite large. I highly recommend for macOS users the free application ImageOptim for lossless PNG compression. It's brainlessly easy. Drag and drop all the newly created PNGs to shave off valuable KBs off your images without any quality hit.

For the more obsessive, macOS users, ImageAlpha (works in tandem with ImageOptim) as it allows users to use indexed color profiles to even further reduce file sizes. PNGquant works natively from Photoshop and TinyPNG provides a free service usable from your web browser. See favicon cheat sheet for CLI utilities.

Favicons and you

As mentioned above this suite of Favicons includes support for (but not limited to): IE11, Edge, Chrome 4+, FireFox 2+, Opera 10.1+, Safari 3.1+, iOS Safari 6+, Google TV, Android Browser 2.1+, Chrome for Android, FireFox for Android, UC Browser for Android, Samsung Internet, QQ Browser, Chrome Store, Windows 8+ pinned sites.

So what does that leave off? IE8-IE10 and Windows Start Screen Icons. IE8-10 require .ico formats. Notably if you opt to include a favicon.ico, Safari will use the Favicon.ico (macOS/OSX) over the PNG version. This means you will need to create a retina caliber icon. See DaringFireball's guide.

Due to the unusual formats of the Windows 8-10 tiles, I'd recommend creating these separately.

HTML (place in your head)

    <!-- generics -->

<link rel="icon" href="/path/to/favicon-32.png" sizes="32x32">

<link rel="icon" href="/path/to/favicon-57.png" sizes="57x57">

<link rel="icon" href="/path/to/favicon-76.png" sizes="76x76">

<link rel="icon" href="/path/to/favicon-96.png" sizes="96x96">

<link rel="icon" href="/path/to/favicon-128.png" sizes="128x128">

<link rel="icon" href="/path/to/favicon-228.png" sizes="228x228">

<!-- Android -->

<link rel="shortcut icon" sizes="196x196" href="/path/to/favicon-196.png">

<!-- iOS -->

<link rel="apple-touch-icon" href="/path/to/favicon-120.png" sizes="120x120">

<link rel="apple-touch-icon"  href="path/to/favicon-152.png" sizes="152x152">

<link rel="apple-touch-icon" href="path/to/favicon-180.png" sizes="180x180">

<!-- windows -->

<meta name="msapplication-TileColor" content="#FFFFFF">

<meta name="msapplication-TileImage" content="/path/to/favicon-144.png">
  

Is all of this really necessary/is there any penalty to including all these images?

How often do you really bookmark websites? It's an honest question. Favicons are most useful for desktop browsing as they give a nice indicator. The 32x32 is the only Favicon that truly matters, the rest are Favicons for bookmarking sites. If you only created a single 32x32 favicon, you'd support roughly 95% of desktop users and mobile users (albeit with caveats). The biggest losers are mobile Safari, Chrome for iOS, Opera Mini, Blackberry browser being the odd men out either requiring their own formats or not supporting the 32x32 at all. iOS Safari/Chrome only use use the favicon touch icon sizes for bookmarks within the dock. Chances are your users would never see the icon.

Today, Web browsers are very smart. The only requests made are for the favicon that matches your browser's parameters. Since it takes almost no effort with this action, you may as well include all the favicons for the edge case users.

Twitter Cards and FaceBook OpenGraph is the new Favicon

Users now expect Favicons and social media shares to be equally as compelling. Both OpenGraph and Twitter Cards take a little more effort to support: you need to fill out additional meta data but the image sizes can be found below. Either set can be used with regular meta data to make other services (Slack or iOS's Messages in iOS 10/macOS's Messages) social sharing with more beautiful site previews.

FaceBook Best Practices for Images practices

Twitter Summary Card with Large Image

Google MetaData Console

Future Plans

Next up is creating an OS X automator version of this, so you won't need Photoshop at all :D

I finally took time to fire up Final Cut Pro X. The experience was surreal; it's eerily a foreshadowing of the Apple to come: a paternalistic and patronizing tone to its professional users that seems to shout "We know best" rather than "You know best, and we want to provide you with the best." It's the Apple that removes headphone jacks and dreams TouchBars are a feature for professions. The writing was on the wall: The Xserve. The Mac Pro. Final Cut Pro. Soldered on RAM in the MacBook Retina, all in the span of a year. Let it be known, 2012 was the last year Apple cared about creative professionals.

2016 didn't kill the Apple that we once loved; it happened five years ago when Final Cut Pro 7 was replaced by Final Cut Pro X. If it weren't for OS X, I don't think any of us will still be buying Macs..

"Speaking of the Mac Pro, I was reminded today about a time when Apple was proud of the professional Macs they shipped. Until the middle of last year, they had a dedicated page for professional users and case studies." - Nick Heer, PIXELENVY

". In the Mac line, at least, 2017 Apple seems a lot like 1994 Apple: misguided products, propped up by gouging the loyalists. The difference is that today’s Apple isn’t dependent on computers, and indeed barely cares about them thanks to the timespace-warping enormity of the iPhone. It’s like being in an alternate timeline where the Newton was a smash success, so the Sculley/Spindler era went on indefinitely."

"I’m honestly not sure Apple is even a consumer electronics company anymore. I’m starting to think they’re more a fashion and luxury goods company instead. When they make the devices thinner just for aesthetics, at a genuine cost to their performance or utility, the old “form over function” slam rings a little more true than it used to. As does the idea of charging high prices because they can" - Chris Adamson. Time Code

"But here’s the problem: in retrospect, what they built was a device based around their own ego needs of proving their critics wrong, not a device that served the purposes of their power users. It’s not configurable, it’s not upgradeable, it’s not expandable: It’s pretty, and full of (for 2013) innovative hardware design, but is that really what Apple’s power users needed?

I don’t believe so. I think they were much better served by the “cheese grater” Macs of the previous generation, and I think Apple needs to rethink this, and for the high end, go back to more of a developer machine which gives users flexibility to expand it and customize it to their needs. Just like the old Mac IIci, one of the best computers Apple ever built. I propose just this in a piece I wrote about this.

The Mac Pro, and its possible successor are serving niches within the niche that is the Mac market overall, but it’s an important niche: it’s the power users, the influencers and the developers who build all of the Mac and IOS apps we all depend on. These are important people that support and evangelize the Mac AND IOS platforms and ecosystems, and Apple has done a poor job of supporting their needs for a good three years now." - Chuq Von Rospach, chuqui.com

"I use a Mac as my daily driver, and have rarely made a tech-related purchase I regretted. And I've never returned a Mac, until today.

The 2016 MacBook Pro is a mixed bag. Many features (most shared between the two models) are huge improvements in the Pro lineup—like the SSD speed, size and weight, keyboard feel, and Thunderbolt 3/USB-C. Other features (like the Touch Bar) are worse than useless—they make the user experience worse.

I hope Apple realizes the blunder with the Touch Bar (and with the confusing lineup of laptops they currently sell) and either fix it or remove it entirely. I'd be happy if Apple only preserved the Touch ID/power key combo." - Jeff Geerling, jeffgeerling.com

While Brooks and others are arguing that iPad will eventually replace the Mac, Gruber is arguing there will always be a need for macOS—specifically a desktop operating system. Despite what my aforementioned dalliance with iPad might suggest, I’m firmly in Gruber’s camp. - , Delusions of Grandeur

I find a bit of solidarity that other Mac faithful seem to be echoing my initial reaction to the Mac Pro. As much as I like the iPhone, there's a viable alternative to it. As a web developer and creative professional, OS X is the beginning and end of why I use Apple products. There is no real competitor even on the same field, mixing a clean UI, and the power of *nix Apple's "courage" is taking its toll. Computer updates do not need fancy press releases but rather a constant component refresh of the latest and greatest, and ability to accommodate the power users rather than Jonathan Ive's whims. As someone who codes, blogs, designs, creates music, and does visual effects compositing (all of these at some level of professional capacity) OS X is vastly superior. iOS always feels like an apology when I try to do real work. It's great for some people, but for those who value raw power and/or raw efficiency, it's OS X or die.

I doubt I'm the first to notice this, but when will Apple learn that a tiny high end/professional, virtually un-upgradable desktop is the computer no-one wants? The 20th Anniversary Mac, G4 Cube, and the Mac Pro 2013 all have been flops.

My brother, sister-in-law, and dad started a cidery, Bandon Rain and I've been slowly building up its web presence. The website, while far from done, is finally ready to be viewed by the public. There's a lot more to be done (lazy loading, better high-density screen handling, more info, better design, press kit and inevitably a backend for others to manage the copy) but it's finally taken the mighty first step. They'll be at First Taste Oregon and I'll probably be there as well.

Update: Bandon Rain is starting to make a splash (bad pun). It can be found on tap in many southern Oregon cities on the coast, as far north as Eugene and Portland.

Important Update:

This guide is dated to the pre-Apple Silicon / Big Sur era. For users on macOS 11.x Big Sur and above (Apple Silicon and Intel) see the new updated guide: Mac MAME Arcade emulation & NeoGeo using OpenEMU and SDLMame for Apple Silicon or Intel.

The last OS X native GUI is forever locked in 2013 at version .149.1 but fear not, you can run the current version of MAME ( version .180 as of writing this). However, there is a current MAME port for Intel OS X by @sdlmame_osx.

Download and install SLD

Go to libsld.org download and download the DMG. Then install the SDL2.framework into (in your root) Library/Frameworks. SLDL2 is a library for cross-platform development designed to provide low-level access to hardware such as I/O and graphics cards (many Steam games are based on this library for OS X).

Download MAME/MESS for Mac OS X - 64-bit Intel

Go to sdlmame.lngn.net and download MAME and decompress it into a folder of your choosing

Create Roms folder

Create a roms folder and place your roms within the newly created folder.

You can stop here but you'll probably want to download the m64 launcher from github.com/bamf2048/bamf2048.github.io (Direct link) to zip and place it in the directory. This will launch the app without the terminal and default to the installed games.

It isn't pretty but it'll get you the latest MAME compatibility. Notably sites like emuparadise have the rom sets. You may want to consider setting up OpenEmu with Mame if you want native GUI. Enjoy!