About 2-3 times every year, I have one of those “Duh! Why didn’t I think of that before?” moments. This week, my “Duh!” moment was in realizing that for a great-many .png images, removing the white background in them and replacing it with transparency would more than likely result in less pixel information needing to be stored for each image. And less pixel information needed to be stored would more than likely result in smaller overall file size.

I decided to put that theory to the test tonight. I picked three images from the mapformation.com website at-random that included a lot of white in them. The mapformation site uses a white background in its page template, so storing white background information in each of the .png files themselves would be unnecessary.

To perform this experiment, I used a combination of Adobe Fireworks and PNGSlim. In Fireworks, I used the Magic Wand Tool to remove a majority of the white from the image (all the background color). I then made the matte for the image transparent as well. When you save that .png out of Fireworks with alpha transparency, you’ll probably fall out of your chair, as the file size will INCREASE by roughly 15-30 times its original size. However, have no fear! Subsequently running the much larger .png out of Fireworks through PNGSlim will bring that file back down to a manageable size.

Unoptimized 750×97 pixel .png header graphic – 4,555 bytes

Optimized 750×97 pixel .png header graphic – 4,303 bytes

Unoptimized 201×155 pixel .png logo – 12,744 bytes

Optimized 201×155 pixel .png logo – 11,959 bytes

Unoptimized 251×37 pixel .png logo – 1,162 bytes

Optimized 251×37 pixel .png logo – 1,071 bytes

18.0 KB of imagery was reduced to 16.9 KB in cumulative size, an improvement of 6.2 percent. Not bad at all, considering those images had already been turned into “flying tin cans” at an earlier date by Yours Truly.

Replacing an unnecessary background with transparency is probably something many of you reading this have already been doing for years! However, in case you’re like me, I thought I’d share my “Duh!” moment and potentially save you a little time. Enjoy!

Parlez-vous français?

I personally don’t speak French well at all (other than knowing that when I get into trouble, I need to spend some quality time on the Google Translate web site). However, a recent comment on one of my blog postings lead me to find out about a French-language web page on the CSS-IG.net web site that makes me want to take a class or two.

That page described a PNGSlim-like command-line .png optimization tool called ScriptPNG. According to that page (and Google Translate):

“The ScriptPNG allows conversion of BMP, GIF, TGA, PCX, TIF, TIFF, PNM, PBM, PGM to PNG one or several images in one cycle, and optimizing PNG images. To do this, move your images in the folder scriptpng, Execute the ScriptPNG, and choose the value:

3 Change in Paletted PNG (PNG-8, web): PNG conversion Paletted strength up to 256 colors in the image from the original image. Can obtain significant gains weight, but may cause visual degradation. The image is then optimized with option 2 automatically.”

Option 2 seems to be the most desirable (most powerful, without the risk of visual degradation), so I grabbed 20 .png images from the “root” images directory on our mapformation.com web site to see what ScriptPNG might do. The need to have to copy files into the ScriptPNG root directory to optimize them was a bit of a hassle. However, that negative was quickly off-set by the speed in which ScriptPNG operates. I estimate that it took less than half the time to process those 20 .png images compared to PNGSlim, and the resulting output was nearly the same.

16 of those 20 images were within 0.5% of the optimized size of the PNGSlim output. Two of the 20 images were about 2-3% larger than the optimized size of my PNGSlim files, while the remaining two files were less than 1% smaller than the previous “smallest size” I had been able to achieve using the PNGSlim too.

It’s too early for me know what all of this means as of yet! However, the performance of ScriptPNG was strong and fast enough that I wanted to make sure and share a bit of information to encourage others out there to give it a try as well! Looks very promising…and if they can get those optimized results on-par with (or superior to) PNGSlim, we might just have a new favorite tool to play with when it comes to .png optimization!

In case a few of you who are regular visitors to this blog were wondering about the “radio silence” from Yours Truly during the past week, I’ve got four little characters for you: H1N1. Yep, I got to join the world-wide epidemic and enjoy a little flu.

I hadn’t felt good since the end of September, but my symptoms finally progressed to the point of a chronic fever of 99.5 F to 100.5 F, chills, a sore throat, sinus congestion, etc. I think the night I went down to microwave myself some popcorn, only to have to try three times to punch in the right time on the microwave because my hand and fingers were shaking so badly, was the night I thought: “Okay, this might actually be serious.” I also had a really unusual experience of feeling like I had some electric charges running through my body when I would sneeze. Wha-CHOO! …and then it would feel as though my entire body from my neck to the bottom of my rib cage was having a current of electricity passing through it. A very strange sensation…but I’m FINALLY starting to feel like I’m on the mend.

During the peak of the H1N1 pleasantness for me, I visited the Center for Disease Control and Prevention’s web portal for the topic…and, in my delirium, thought I’d better look at a few of the image from an image optimization perspective. The results of that bit of experimentation can be viewed below:

Unoptimized 170×637 pixel .gif graphic – 16,173 bytes

Optimized 170×637 pixel .png graphic – 184 bytes

Unoptimized 150×160 pixel .jpg graphic – 23,734 bytes

Optimized 150×160 pixel .jpg graphic – 15,688 bytes

Unoptimized 136×184 pixel .jpg graphic – 20,801 bytes

Optimized 136×184 pixel .jpg graphic – 11,762 bytes

xat.com’s Image Optimizer did all the heavy-lifting on these three sample images! I used custom zonal compression and the removal of excess colors to reduce the size of the two optimized .jpg files, and also used the tool to convert from .gif to .png format as well. I even gave PNGSlim and punypng a shot at further reducing the sizes of the resulting .png and .jpg output (respectively), but all three files could not be further reduced in size.

All-told, 59.2 KB of imagery was able to be reduced to 26.9 KB in cumulative size, an improvement of 55 percent! Excellent results, from a minimal amount of effort on my part.

I wouldn’t wish H1N1 on anyone out there…as it is nasty! Here’s to hoping none of you out there get it like I did…and here’s to hoping it doesn’t force me to take any more “extended vacations” from this blog!

How does that old saying go? The best compliment or flattery often comes in the form of imitation?

I had an interesting experience tonight. I approved a comment on this blog from a certain email address that eventually took me to a web site called Greenficiency. Sounds fantastic, as they are on that same soap box and preaching the same message that I have been attempting to preach these past several years.

Only one problem: in perusing that web site’s content, I noticed that they literally ARE preaching the same message as I have on our main GraphicsOptimization.com web site! The EXACT same message, in many instances. Sentences/Paragraphs of word-for-word write-ups that I spent hours/days trying to research and write, not to mention other striking similarities in information and content.

I guess I was surprised that someone would be bold enough to lift that much content off another person’s site with open disregard for US Copyright Law. That said, it doesn’t bother me TOO much…although it did irk me a bit to lift a lot of my content and then make sure to set price points just below the ones I have used in the “let us do it for you” section of my site.

That does lead me to want to crawl up on my soap box again though to mention two quick things:

1. The more I’ve gotten into image optimization, the more I’ve come to the mindset of needing to give it away (educate and broadcast) versus trying to monetize the service. That is one main section of content from our GraphicsOptimization site that is strangely missing from the Greenficiency site. The (main) part which we inform people how to do electronic image optimization themselves. The part which will have 100-times the positive impact on effecting change as keeping secrets and then charging people for that expertise might. Which leads me to my second point:

2. Ownership of the expertise. When I present workshops at conferences or guest lecture at a handful of educational institutions, I try and be very transparent in letting people know that I am not “the” image optimization expert. Rather, I am just a person who has made it a mission to create a clearinghouse and blog for everything I know about what the actual experts are doing out there. Andrew Dent…Conrad Chu…Stoyan Stefanov…Ken Silverman…and many others are the true experts in this field! Where the hard, dirty work is being done in the trenches squeezing every last bit or byte out of every electronic image format out there. I am just a “preacher” or apostle who is out there spreading the good news about their efforts…sharing what I know with as many people who will listen.

Since most of those experts freely share much of their expertise, ideas and feedback with us, I feel a strong sense of obligation to “pay it forward” and share my own expertise, ideas and feedback with others who request it. I do charge for performing optimization services on other people’s behalf from time to time…as my time IS money, and if they don’t want to learn how to do it themselves but still want/need it done, I do need to put food on the table for my family of four! However, image optimization services isn’t really a commercially sustainable business model IMHO…as the only way to make a decent living at it would be to take the tools and information others have freely shared with us, turn around and keep them secret. That just doesn’t feel right to me.

This isn’t a knock at Greenficiency! Heck, the more people out there spreading the image optimization message, the better! All the best to them in their efforts going forward. I just want people to do this for the right reasons. If Andrew Dent gives us PNGSlim for free, then we (the collective “we”) turn around and charge others thousands of dollars to access PNGSlimmed files when they might have been just as happy and empowered to optimize those files themselves, pretty soon, if Andrew is smart (and I know he is VERY smart), he’ll start thinking/saying “why am I giving this tool away and letting others make a lot of money while all I have is a couple thank yous and handshakes for my effort?” And then the wonderful “open source” style community we have really pushing new boundaries and reaching new “converts” out there will become tainted and/or will lose its responsiveness and core mission/values in pursuit of financial reward.

Sorry for the LONG posting tonight! Just wanted to say a few things that were on my mind.

In response to Conrad Chu’s comment from my previous blog posting (thanks for taking the time to comment, Conrad), I thought I would share a specific example of .png optimization related to punypng and PNGSlim. Conrad had asked me to share a concrete example to illustrate my “In my experimentation with the two tools, punypng has consistently only taken about half of the excess file size out of the typical .png image as PNGSlim has” comment from yesterday’s post…so since he was so gracious in commenting on my post, I wanted to quickly provide such an example.

For this experiment, I used the W3C.org validation service to check the status of my mapping firm’s home page at mapformation.com. We passed (whew), albeit with three warnings. W3C subsequently provided links to two .png files that I could post on that home page if I chose to:

Unoptimized 88×31 pixel .png graphic – 1,542 bytes

Optimized 88×31 pixel .png graphic using punypng – 1,446 bytes

Optimized 88×31 pixel .png graphic using PNGSlim – 1,267 bytes

Unoptimized 88×31 pixel .png graphic – 1,669 bytes

Optimized 88×31 pixel .png graphic using punypng – 1,605 bytes

Optimized 88×31 pixel .png graphic using PNGSlim – 1,417 bytes

Optimizing those two images from originals using punypng took 3,211 bytes of imagery and reduced them to 3,051 bytes in cumulative size, an improvement of just under five percent! Optimizing those same two unoptimized original images using PNGSlim took 3,211 bytes of imagery and reduced them to 2,684 bytes, an improvement of roughly 16.5 percent.

Conrad is absolutely correct when he says that one of the bigger drawbacks to PNGSlim is that it can be s-l-o-w…particularly when it is processing .png images with large file dimensions! Its speed has improved from what it used to be, but a LOT more improvement could still be made in that area. What I like about PNGSlim though is it can also be running in the background while I am doing other tasks, so it’s not really that big of a deal to me if it takes an extra 10 seconds here, 20 seconds there. For PNGSlim to be widely adopted as a potential .png optimization “standard” though, more work to improve the tool’s speed is most-definitely needed.

Thanks Conrad! I hope this subsequent post helps. Also, if you ever need anyone to help test-drive that “Professional” version of punypng down the road, just let me know. I’d be happy to help and give you as much feedback and ideas as I can.

It’s been about four months since I last posted in this blog about the great, free, web-based optimization tool called punypng. Consequently, I thought I would play around with the tool a bit more tonight to see what might have changed in recent months.

Related to .png optimization, I still have struggled to achieve comparable results to PNGSlim. In my experimentation with the two tools, punypng has consistently only taken about half of the excess file size out of the typical .png image as PNGSlim has. Consequently, I have not used punypng much with .png file optimization.

That said, I have begun to do a great deal more experimentation with punypng related to .jpg output, with very good results! As a recent example, I took all of the .jpg image tiles generated by a tool called Zoomify in the display of a 3D perspective vector-style campus map that our firm had produced for Auraria Higher Education Center in Colorado (USA) during the Summer of 2007.

70 total tiles, which Zoomify saved at 882 KB, were able to be reduced to 803 KB in cumulative size, an improvement of nine percent. Well worth the effort…especially if you are someone who makes HEAVY utilization of the Zoomify tool (as our firm does).

Keep up the great work, Conrad, Kevan, Abe and Matt! I can’t wait to see what’s next related to the punypng tool.

Hey everyone! Just wanted to post a quick “public service announcement” that Stoyan Stefanov’s smush.it tool now comes as an automated Wordpress plug-in! Smush.it offers the following resources:

* stripping meta data from JPEG images
* optimizing JPEG compression
* converting certain GIF files to indexed PNGs
* stripping the unnecessary colors from indexed images

Basically, smush.it will run in the background on your Wordpress site, automatically reducing the size of your imagery on your behalf. The only sad, selfish thing is that I cannot use it on this particular blog…as the before-and-after optimization examples I try to illustrate would be impacted by all of the “before” images being adjusted. However, if you operate a Wordpress blog, definitely give that plug-in a look!

I came across another fantastic article the other day by Carlos Bueno on the Yahoo! Developer Network Blog entitled “An Engineer’s Guide to Bandwidth.” Two things in particular that I really enjoyed about this article:

1. Distinguishing between bandwidth and packets. From the bandipedia.com web site:

“A packet consists of a certain number of bytes. A typical packet contains perhaps 1,000 or 1,500 bytes. Each packet carries the information that will help it get to its destination (i.e. from the sender’s IP address to the intended receiver’s IP address). The packets carry the data via the TCP/IP|Transmission Control Protocol/Internet Protocol (TCP/IP).

Trailer- The trailer, sometimes called the footer, typically contains a couple of bits that tell the receiving device that it has reached the end of the packet.”

One of the things I always try and pay attention to when I am optimizing imagery is how many bytes I can reduce out of an image’s size in multiples of 1,460 (the example size used in Carlos’ article). If I can reduce a 13,220 byte image to 10,220 bytes, that is only 3,000 bytes! However, that is THREE packets potentially not needing to be sent.

Right about now, a few reading this are saying “wait a minute! 1460 x 3 = 4,380 bytes. How can only 3,000 bytes equal three packets saved?” That’s the fun part. If you have an image that is 1,461 bytes, and can reduce that image’s size by even one byte, that could theoretically save one whole packet from being sent! That’s because whether one byte or 1,460 bytes are needing to be sent, a full packet is necessary, depending upon Path MTU (Maximum Transmission Unit). From the NetHeaven.com web site: “The full path from one computer to another may travel across many links with different MTUs. The smallest MTU for all the links in a path is the path MTU.”

Makes me even more excited even if I am only pulling out 10-20 bytes from an image’s size…as that 10-20 bytes might be the difference in one unnecessary packet transmission being sent.

2. Packet Latency and Packet Loss. From the article: “Packet Latency is the time it takes a packet to wind through the wires and hops between points A and B. It is roughly a function of the physical distance (at 2/3 of the speed of light) plus the time the packet spends queued up inside various network devices along the way.” Packet loss is basically the failure of a packet to deliver to its end destination, for any variety of potential reasons.

Stating the obvious here, but fewer packets to send through what former Alaska Senator Ted Stevens dubbed as a “Series of Tubes“ (or Jon Stewart’s version of Stevens making that comment…a LOT more entertaining), the fewer the chances of any packets getting lost in transit or delayed in their delivery.

Great job, Carlos! Thanks for the insight.

Back in February 2008, I shared a posting about one of my favorite disc golf sites out there, discgolfersR.us. A year and a half later, we’re still talking about the issue of image optimization a bit on that site, as can be seen at: http://discgolfer.ning.com/forum/topics/members-using-front-page-for

I’m just happy we’re talking about it…as if even 1-2 more people read some of those discussions and then begin to take much greater care when posting imagery to that site (and others), the Internet will be just a bit better place to be! While talking about image optimization issues on the site again though, I thought I would look at a few more images on the site to see what might be able to be done.

16 Unoptimized .png graphics of flags – 60.4 KB

16 Optimized .png graphics of flags – 17.9 KB

A simple PNGSlim batch optimization process on those 16 .png flags took 60.4 KB of imagery and reduced them to 17.9 KB in cumulative size, and improvement of 70 percent. Not bad…particularly when you consider how much the site has grown the past eighteen months, and how much more traffic it is now generating.

Keep up the great work, Terry! You are a blessing to all of us in the greater disc golfing community.

I came across a couple optimization tools I was unfamiliar with tonight, so I thought I would share a quick posting to see if anyone out there knows anything about either tool:

JPEG & PNG Stripper (Win95 to Win7) – (from their web site) A tool for stripping/cleaning/removing unnecessary metadata (junk) from JPG/JPEG/JFIF & PNG files. The image quality IS NOT AFFECTED. Includes command line support. Just specify a folder or file on the commandline (wildcards allowed).

PNGpong (Mac) – (from their web site) PNG is a wonderful file format that suffers from an unfortunate gamma problem (http://hsivonen.iki.fi/png-gamma/ ). PNGpong alleviates this issue by stripping the color “correction” information out of the file using pngcrush. PNGpong then attempts to further compress the PNG file by running it through optipng (I say “attempts” because some PNG’s may already be as compressed as possible).

Keep fighting the good fight!

Just for grins, I decided to re-visit my C:/ drive tonight using PNGOUTWin. I did a basic search on *.png within my C:/ drive and all sub-directories, then had PNGOUTWin do the heavy-lifting in the background while I caught up on a little work.

A few thousand images later, I had over 20 MB less disc space being used on my hard drive. Not bad…considering I only had the occasional 5-10 second interruption to start the next few hundred images files in PNGOUTWin!

I mention this to illustrate (again) that it is not just web sites or HTML-formatted email that can achieve substantial improvements in file size and performance! Software development and GUI design is just as fertile potential ground for making a positive dent in our e-world! Next time you have nothing better to do on a Wednesday evening, get yourself a copy of your favorite image optimization program of choice (PNGSlim, PNGOUTWin, PngThing, etc.), open up your File Manager on your computer and have a little fun as well!

I noticed recently that The MacArthur Foundation named its 24 MacArthur Fellows for 2009. For those that don’t know what I am talking about, these are the awards that are often dubbed “genius grants” by the media…where people with unique talents, ideas and gifts are given money to basically play and further explore whatever field of study happens to interest them.

In my wildest dream of dreams, somebody someday nominates me for a Fellowship, the selection committee chooses me as one of its recipients, and then I have five years where I don’t have to worry as much about generating income…and can focus on really building all of this GraphicsOptimization content right! Well that…as well as my continued efforts to build what my seven-year old daughter calls “Daddy’s Death Ray,” AKA using Fresnel lenses and rocks to heat and purify water for home-heating and human consumption.

Alas, I’m sure I’m not even a tiny blip on the radar of the individuals who serve on the nomination and selection committees…so I’ll have to keep working 12-14 hours/day, six days/week to eek out just enough of a living to keep all our designers at mapformation employed while keeping a roof over my family’s head and food on the table. My mind does occasionally wander to those Fellowships though…as I’m not sure they would ever have a Fellow work harder to earn that grant money if the planets ever aligned and I were lucky enough to be considered.

Okay, head out of the clouds and back down here on Earth! Image optimization! While I was on the MacArthur web site, I figured that I might as well take a look under the hood to see what might be done to improve the performance of their site. I selected eight “nav” images on the site, to see what might be done.

Eight unoptimized .gif buttons – 8.12 KB

Eight optimized .png buttons – 6.00 KB

Here is an example of where a CSS image sprite would make a lot of sense! However, for the purposes of this exercise, I kept “apples to apples” and simply optimized the eight images as separate files. A quick conversion from .gif to 8-bit .png format for all eight images using PNGOUTWin, followed by some further optimization work in PNGSlim, took 8.12 KB of imagery and reduced it to 6.00 KB in cumulative size, an improvement of 26 percent.

Modest file size and bandwidth savings in this particular instance (2.12 KB per page view with an empty browser cache). However, every little bit helps…and if we can pull 26 percent out of those sample images without changing their appearance on-screen, I’m confident we could do a lot to improve the dozens of other image files that are found on the MacArthur Foundation web site as well.

Congratulations 2009 Fellows! May you use your “extra” bit of resources wisely to continue to make a positive impact on our planet.

One of the sites that inspired me to really jump into the deep end and take this long, strange and rewarding journey related to image optimization was Google Maps. It’s obviously map-related, and if there is a mapping site/service out there which consumes more bandwidth per day than Google Maps (due to the volume of site traffic), I’ve likely yet to see it.

I revisited the Google Maps site this weekend to see what improvements have been made to the service from the perspective of image optimization. I began by looking at a few graphics that are standard for most views:

Unoptimized 147×935 pixel .png sprite graphic – 20,065 bytes

Optimized 147×935 pixel .png sprite graphic – 20,017 bytes

Unoptimized 59×492 pixel .png sprite graphic – 2,767 bytes

Optimized 59×492 pixel .png sprite graphic – 2,286 bytes

Unoptimized 20×374 pixel .png sprite graphic – 2,554 bytes

Optimized 20×374 pixel .png sprite graphic – 1,569 bytes

Unoptimized 37×34 pixel .png sprite graphic – 665 bytes

Optimized 37×34 pixel .png sprite graphic – 531 bytes

Unoptimized 142×131 pixel .png sprite graphic – 8,493 bytes

Optimized 142×131 pixel .png sprite graphic – 8,086 bytes

I took a very conservative approach to those images, leaving the number of image colors alone and simply defragging each file using PNGSlim. Modest results for those five images…as 33.7 KB of imagery was reduced to 31.7 KB in cumulative size, an improvement of six percent. Still, 2 KB per visit, multiplied times the number of visits with a clear browser cache on a daily basis, and you are talking about quite a bit of bandwidth savings over time!

Obviously though, the great and elusive “white whale” of image optimization associated with the Google Maps site are those millions upon millions of 8-bit .png image tiles! I’ve snooped around their tiles before to see what might be possible, but I figured I would give it another go.

I decided to look at the default tiles that appear when viewing Palo Alto, California, USA in Google Maps in my browser window at 1024 pixels wide. 16 image tiles. 365 KB in cumulative file size. I then decided to perform two simple experiments:

1. Run all pre-existing image tiles as-is through PNGSlim’s batch .png optimization process.

2. Convert all image tiles to 6-bit (64 colors), then use PNGSlim to defrag the images further.

Experiment #1 was easy enough. Not much work or effort on my end, except for the fact that the naming convention Google uses for its tiles weren’t working in PNGSlim, for some reason. I subsequently had to temporarily change each file’s name, run the procedure, then change all file names back to their original names. The end results were interesting. Those 16 optimized images were able to be reduced to 329 KB in cumulative size, an improvement of 9.87 percent.

Coincidentally, I also decided to run several of those image tiles through punypng as well, to see what results that tool might achieve. punypng was able to generate file size reductions of approximately 5.5 percent…roughly half the savings of using PNGSlim.

Experiment #2 is a bit more controversial. Google Maps tiles in my sample group were using anywhere from approximately 40-170 colors in them. However, my contention is that 64 colors should be PLENTY of colors 99.9% of the time. I tried a similar experiment with OpenStreetMap tiles approximately two years ago, and their staff had similar doubts about 6-bit color. “Not enough colors” was what I was told in response…so I asked for them to send me a few tiles that they believed would require more than 64 colors. I re-ran the experiment again, and showed them 64-color versus 256-color tiles, and there was no discernable difference between the two…other than a substantial decrease in file size.

My same contention with Google Maps tiles holds true. I believe 64 colors is more than enough to display their imagery, and re-ran my optimization procedures accordingly. Those same 16 sample image tiles of Palo Alto, saved to no more than 64 colors and then optimized using PNGSlim, resulted in a cumulative file size of 253 KB, an improvement of 31 percent from the original tiles, and an additional 23 percent improvement from the tiles using 8-bit color when processed using PNGSlim.

CONCLUSION: If Google did nothing but run their image tile inventory through PNGSlim, they could immediately achieve download/display and bandwidth savings of approximately ten percent. However, if they could also be “sold” on the value of converting all their tiles to 64 colors (or less), they could likely achieve a 30+ percent reduction in download/display time and bandwidth…which would likely mean an average savings of bandwidth in an HOUR that would far-exceed all of the bandwidth consumed by this GraphicsOptimization blog site in the typical YEAR.

I’m not sure if Google will take any of this to heart! However, if they are ever looking for a little help in this department, I can’t think of a better way to make a King Kong-sized dent in global bandwidth consumption than to spend a few months working to put their map imagery on a diet. Then once we got their Maps tiles in-order, we could start chipping away at their StreetView imagery, their Google Earth imagery, etc. One step at a time though…

I came across a really interesting site the other day called PrintFriendly.com. Their service is a simple yet powerful one: to empower individuals viewing content on the web to have greater control over the content of any page that they wish to print to paper or .pdf format. From their web site:

“How It Works

* Prints Clean: Our algorithm removes ads, navigation, and all the junk you don’t want to print.
* Prints Pretty: We use best practices in print Typography to format your document for great readability.
* Customize: Save even more paper and ink, remove images, paragraphs, and Get PDF”

I played around with the service on a few pages, and it works very well! Of course, while I was in there I thought I would experiment with a few images on their home page as well:

Unoptimized 277×323 pixel .png graphic – 76,339 bytes

Optimized 277×323 pixel .png graphic – 68,895 bytes

Unoptimized 291×279 pixel .png graphic – 22,077 bytes

Optimized 291×279 pixel .png graphic – 5,447 bytes

Unoptimized 207×102 pixel .png graphic – 23,439 bytes

Optimized 207×102 pixel .png graphic – 18,765 bytes

Unoptimized 219×63 pixel .png graphic – 10,461 bytes

Optimized 219×63 pixel .png graphic – 8,538 bytes

Unoptimized 214×106 pixel .png graphic – 18,165 bytes

Optimized 214×106 pixel .png graphic – 14,952 bytes

Some quick batch optimization work using PNGSlim took 146 KB in imagery and reduced them to 113 KB in cumulative size, an improvement of 23 percent. Not too bad! A quick way for making the PrintFriendly web site a little more “web friendly.”

Thanks PrintFriendly! Awesome tool you’ve got there.

During my recent NACIS trip to Sacramento, California, I had the privilege of going out to lunch with a University of Wisconsin-Madison grad student named Daniel P. Huffman, along with three other individuals, to discuss the Ortellius software demonstration presented at the conference.

Daniel seemed like a very nice person, so I thought I would take a look at a lot of the work he has produced and uploaded on to his web site, somethingaboutmaps.com. Both from a mapping standpoint and related to image optimization. My brief evaluation related to image optimization work can be viewed below:

Unoptimized 175×175 pixel .png graphic – 104 KB

Optimized 175×175 pixel .png graphic – 9.65 KB

Unoptimized 175×175 pixel .png graphic – 98.2 KB

Optimized 175×175 pixel .png graphic – 9.24 KB

Unoptimized 175×175 pixel .png graphic – 144 KB

Optimized 175×175 pixel .jpg graphic – 15.7 KB

Unoptimized 175×175 pixel .png graphic – 151 KB

Optimized 175×175 pixel .png graphic – 19.3 KB

Unoptimized 960×129 pixel .png graphic – 14.5 KB

Optimized 960×129 pixel .png graphic – 4.94 KB

All five of those .png images were pretty easy to process. One of the images used 24-bit color, so I converted it to .jpg format and then zonally compressed portions of it using xat.com’s Image Optimizer. I processed the remaining four images in the same tool for a bit of initial optimization work, then pulled additional file size out of each image using PNGSlim. All told, 512 KB of imagery was able to be reduced to 58.8 KB in cumulative size, an improvement of 89 percent.

Best of luck to you, Daniel, as you work to complete your graduate studies and move forward in your career! Just remember to try and keep the electronic imagery you create in-check if you can…so that people from different connection speeds, on different tools, from different regions of the world, can all access your content in a timely manner.

As I eluded to in my October 7 posting, one of the really interesting products I was introduced to at the 2009 NACIS annual meeting was Ortellius, which is described on their web site as “powerful map illustration software” designed exclusively for the Macintosh platform. Jill Saligoe-Simmel of at MapDiva.com did an excellent job of demonstrating the tool…and some of the features built into their solution leave Adobe Illustrator FAR behind in complexity and ease-of-use.

I was particularly impressed with their Automatic Junctions and Linear Select™ functionality. There are other features that got a few oohs and aahs from those in attendance at the session…but those two features were really, really nice.

I also talked with Jill a bit over lunch about my work with image optimization…so I thought it might be fun to take a look at a handful of images from their homepage as an illustration of what is truly possible related to efficient file sizes and bandwidth savings. Below are a few examples of their imagery:

Unoptimized 570×350 pixel .png graphic – 160 KB

Optimized 570×350 pixel .jpg graphic – 71.7 KB

Unoptimized 570×350 pixel .png graphic – 98.8 KB

Optimized 570×350 pixel .jpg graphic – 29.9 KB

Unoptimized 950×350 pixel .png graphic – 214 KB

Optimized 950×350 pixel .png graphic – 51.1 KB

Unoptimized 950×350 pixel .jpg graphic – 106 KB

Optimized 950×350 pixel .jpg graphic – 34.8 KB

This was one instance where converting from .png to .jpg format (on two of the images) resulted in a dramatic decrease in file size. I think sometimes people read some of the optimization resources out there and just assume that .png = good, .jpg = bad. When it comes to drawn imagery, that is generally true…for 8-bit imagery! However, for images with 24-bit color, .jpg is generally a superior option.

I ran the various images through a combination of xat.com’s Image Optimizer and PNGSlim. After about 4-5 minutes of effort, 580 KB of imagery was able to be reduced to 187 KB in cumulative size, an improvement of 68 percent.

I’d love to look under the hood and play a bit with the imagery that makes up their graphical user interface (GUI) for Ortellius! However, a two-thirds reduction in bandwidth consumption on a sample set of imagery from their home page is a pretty exciting start to hopefully convincing Jill and Graham to investigate this issue further.

If you’re a Mac user and looking for a good tool to make some interesting map designs, give Ortellius a try. Alas, I’m on a Windows platform, so I can’t use their product. However, if anyone has any comments about that software, feel free to share them here. Thanks!

Day three at NACIS felt a bit more like a death march. I was exhausted from only getting about 8-9 hours of sleep the previous 72 hours. We also had an always-difficult “Future of Cartographic Perspectives” session in the morning (the international journal of NACIS that seems to always be trying to find its way…at least since I got involved with NACIS 4-5 years ago). Too many academics with too many opinions trying to make CP be too many things to too many people. Anyway, enough about that.

The “Interface Design and Tech” track (four sessions) was pretty good…though I had to spend a bit of time catching up on email while sitting in on those sessions. I skipped the early afternoon sessions on Friday to try and get a little rest. No nap for me (unfortunately), but the 90 minutes or so of rest did help. The last four sessions I sat in on were in the “New Tools for New Cartographies” track.

While sitting in on Stuart Miller’s “Producing quality mapping quickly and efficiently with Mercator” session, I got the interesting experience of hearing my words quoted within another session. I don’t remember ever sitting in on a session and having that happen before. I thought it was cool, but it was also a little embarrassing…as I don’t really think of myself as an “expert” in cartography. Rather, I have expertise at 2-3 interesting, peripheral tasks associated with cartography. It was very flattering though, to say the least!

The day ended with a closing banquet that was good, but lasted at LEAST 60-90 minutes longer than it should have. I felt really bad for Dennis McClendon in particular, as his Geodweeb Geopardy event (a spoof on the TV show Jeopardy, containing lots of mapping and geography/cartography topics) didn’t start for more than an hour after it was supposed to be finished. I didn’t have the stamina to make it that late (too little sleep), so I headed up to the hospitality suite for about 30 minutes, talked with a few individuals, then went to bed. All work and no sleep makes Derek a dull, tired boy.

All in all, a good conference! I wish the event wouldn’t have ended with a thud (having the banquet become a test of endurance)…but I still had a great time anyway!

Day Two started a lot like Day One at NACIS…not nearly enough sleep for Yours Truly. I had good intentions, but trying to catch up on a little work, coupled with catching up with a few friends (and trying to make a few new ones) at the hospitality suite, meant another LATE night.

I spent my morning attending the “Design with the User in Mind” and “Mapping the Physical Landscape” sessions (6, in total)…with the most interesting session of the morning likely being the “Egocentric perspectives in map search” session presented by Matthew E. Millett from the University of Oregon. A bit controversial, and I do think that Americans too-often get TOO bad of a name when it comes to being a little too egocentric when it comes to the world and politics. However, an interesting presentation nonetheless.

I spent the first part of my afternoon attending the “Emerging Visualizations” track…with three very interesting presentations. The first was another Indiemapper demonstration from the team at Axis Maps, LLC. The second was an interactive mapping case study from James Robertson at the University of Montana (a campus I got familiar with during some free time at NACIS 2008). The third session was a talk on Google Streetview from Andy Szybalski of Google.

After a break, I (and three other individuals) switched back into Presenter mode and offered our Business of Cartography panel discussion. We were worried there wouldn’t be enough questions to fill our 90-minute time slot. However, we ended up having the opposite problem…running out of time. Thanks again to Hans van der Maarel, Dennis McClendon and Alex Tait for what turned out to be a very fun and informative session!

After a bit of R&R, I then enjoyed a night out at the River City Brewing Company, followed by more time in the Hospitality Suite. Lots of good networking was occurring…as well as a little talk about some common enjoyment of things such as disc golf and the TV show Family Guy.

Back at it again tomorrow!

I sleep-walked through my presentation at Practical Cartography Day at the 2009 North American Cartographic Information Society annual meeting in Sacramento, California, USA today…after struggling to get MAYBE four hours of sleep last night. However, my session: Ideas for Creating Smaller Interactive
Map File Sizes in .swf Format …seemed to go over well with the 100+ individuals in attendance.

I don’t think people believed me at first when I was illustrating some of the radical changes in .swf file sizes that were being observed just from variations in the application of tools such as symbols, line segments, and compound paths. A few people even raised their hands during Q&A time and were questioning the results. I was glad to have a few people in the audience though who chimed in and told people that the interesting variations we were observing were very-much real (as well as some of the reasoning/programming behind it).

I’m trying to think of the best way of incorporating those slide materials into our main GraphicsOptimization web site. For the time being though, I’ve been more busy trying to introduce many of those techniques in vector design (and raster exporting) into our day-to-day operations at mapformation, LLC.

The other sessions I really enjoyed today were from Jill Saligoe-Simmel at Ortellius (I’ll talk more about this one later), Event Animation Mash-ups in the Google Maps API (presented by Robert E. Roth and Kevin S. Ross at Penn State), and David Heyman’s (Axis Maps, LLC) demonstration of Indiemapper.

A good day! I had 4-5 minutes of technical difficulties at the beginning of my own session (a flashback to my one and only blue screen of death moment at Practical Cartography Day at NACIS in 2008), but had smooth sailing after that. I also got to enjoy exploring outside the California State Capitol building and grabbing dinner with my friend Hans from The Netherlands as well. I have the pine cone from one of the very tall pines on the West side of the Capitol building to prove it.

Thought I would document some of my experiences at the 2009 North American Cartographic Information Society (NACIS) annual meeting in Sacramento, California, USA.

I list today as “Day Zero” as it is effectively just a travel day. I got to the Minneapolis Saint Paul International Airport at 3:00pm this afternoon, all ready to board my flight at a few minutes before 5:00pm. Over seven hours later, I was still stuck at MSP…waiting for my new ride to be fixed by mechanics after my old ride didn’t arrive in time (causing me to miss an eventual connecting flight in Phoenix, Arizona).

“Happy” times. Oh well…at least I did get to watch innings 7 through 12 of the Minnesota Twins/Detroit Tigers game to determine the winner of Major League Baseball’s American League Central Division. That was fun, huddled around the televisions at the various sports bars scattered throughout the concourse with a few hundred other Twins and Tigers fans. I’d have rather been in Sacramento by then, but when life deals you lemons…time to squeeze a little lemonade.

Didn’t get too much work done other than to dry-run my session for tomorrow’s presentation. Trying to get the timing of my session down to around 26-27 minutes. We’ll see how tomorrow goes…