K2 Problems

0

K2 Problems

Before settling in with ProcessWire, I spent some time evaluating other CMS frameworks. For a few days, I experimented with Joomla, Gantry, and Wordpress, among others, and I also played with some of the various add-ons, extensions, themes and examples that are widely available.

I spent more time than I'd care to admit. It is easy to get swallowed up in the whole process of evaluating the capabilties of various systems.

Along the way, I uncovered some problems with each of the top CMS dogs. Today, I present just one example:

Herein lies another cautionary tale..,

K2 is kind of a framework-within-a-framework. It is designed to extend and add value and fuunctionality to Joomla! I read good things about K2, so  I added it to my list of evaluations (in for a penny, in for a pound). K2 adds support for uploading media files, and also offers some automatic extras -- graphics files will be replicated in various sizes, so that you, as a web server, can optimize and minimize the payload delivered to clients. Instead of sending that entire 1920x1080 graphic to a client with a smaller screen, for instance, you can easily send a quarter of that, because K2 will have created a smaller version, automagically.

I implemented a test site using this feature. I made it responsive to media queries, and uploaded this main graphic for my test article:

WriteCacheEffect1of4.png

This image is a 693x454 capture from my Windows 8 desktop. The size of this PNG image is modest, only 14kb (partly because I run a high-contrast theme and only 330 colors are used). But when I uploaded this graphic with K2, I was dismayed to learn how it performs.

2ff2ba0051687eef5ca0459cf942940c.jpg

K2 takes whatever pix you upload, and creates multiple copies of differing sizes, so that you (it) can provide a size appropriate to the page and device you're (itz) serving. There is a configuration page where you can specify the canonical sizes, which it maps (like t'shirts) to Small, Medium, Large, etc.

A total of seven (7!) copies are made. The original is then discarded!

First, a copy of the same dimensions is made, using the Quality percentage defined in the K2 parameters.

Then, six more copies (XS,S,M,L,XL, and Generic) are made.

In my case, I chose 100% quality, then examined the resulting files. I was dismayed to discover a loss of quality and color vibrancy. Viewing the original side-by-side with the conversions, I could easily discern color shifts and other artifacts.

Not as important, but certainly a factor-- the multiple files created (all jpegs) were horrendously large.

I uploaded a PNG graphic, one of four in a series, captured from my desktop (so that I could write an article on Windows 8 disk write caching -- see I Want Arrays). This original graphic is 693x454 pixels, with 330 colors counted, and has a file size of 14kb. The seven copies made by K2 amounted to 746kb. The cloned copy, alone, is almost 10 times the size of the original (118kb!).

Most importantly, every picture looks worse. The jpeg clone (copied into k2's 'media/k2/items/src' directory), with the exact same dimensions, looks pale, faded, as if viewed through a fog. Checking the color count revealed a possible root cause: the original's 330 colors were morphed into 6,142 colors used.

Must be a whole 'lotta dithering going on.

All of the other manufactured images look similarly distorted.

The moral of the story could be drawn from any one of a number of our collection of platitudes. There's no such thing as a free lunch. You have to do your homework. Be careful what you wish for. I could go on, but the bottom line is, you always need to put the work in, to do the cost/benefit analysis, whenever proposing to incorporate Other People's Code into your applications.

Tags: OPC, NIH