Saturday, February 09, 2013

Photo Quality

Before
As most of you have probably noticed, I've been working on a new website, Walking4Fun.com. Creating this website from scratch went a heck of a lot quicker than creating AQ from scratch, and one of the reasons is because I use a lot of the same code on both websites. In fact, all of the core, generic code is the same for all of my websites--which includes TheSodaCanStove.com and a new website I've been developing for a pizza place. (That one isn't up, however, so I'm not posting a link to it.)

Code reuse is a wonderful thing because it makes development go faster. And if I find and fix an error in one location, the fix magically works for all of the other locations as well. Or if I add a new feature or improvement to this core code, all of the other websites can also benefit from it.

Consequently, you mind notice some "cross-pollination" between websites. Work on one invariable causes improvements in the others.

And today's (admittedly small) improvement on AQ comes from Walking 4 Fun. For those of you who haven't heard about it, it's a site that allows you to virtually hike the Pacific Crest Trail and Camino de Santiago. You track how much you walk each day--around town, around the office, and wherever your feet should carry you--then enter it into the website at the end of the day. It'll show where you would be on one of these famous trails had you done your steps on there, along with photos of all of the places you would have passed that day. It's not easy to see how far a mile of walking here and there can really add up, but you'll see it on this website.

After
So I wanted to create a promotional kind of link that would display one image among the thousands that are on this website--along with what trail it came from and where on the trail it was taken. (This is working now--that's what you see at the top of the right-hand column of this blog post!)

Not a big deal--just a bit of graphic manipulation.

During the process, I needed the photo shrunk down from what was on the website, and I had conveniently already created a function in the core code that could do this. I pass in the photo, the maximum width or height I want it to be, and it returns the properly resized image.

The first issue was that I found a bug. The returned image was smaller, but it wasn't the correct size. I found the error and fixed it, and the fix went up on AQ as well. It was a relatively minor bug, though. Not something most people would notice. (Heck, *I* didn't even notice it until now, and I've been using this code for years!)

The other thing that bothered me was that the code depended on a function call for the actual process of resizing the photo that wasn't very good. If you good a super high resolution photo and shrunk it down a lot, it looked pixelated and ugly. I didn't really know of a good way around this problem, though, and just lived with it.

Well, in the process of working on this feature for Walking 4 Fun, I was scrolling through a list of functions available to manipulate images and discovered that there was a different option available to resize photos--and this one smoothly interpolates pixel values which is what I've always wanted the resize to do! It just looks better!

So I updated the code to use this new option instead and tried a few test images on my development machine--some uploaded with the old function and some uploaded with the new function. And without a doubt, the new stuff looks so much better!

So I've worked the update into Walking 4 Fun, AQ, and the pizza website. (It also works on the soda can stove website, but there aren't any images that I manipulate programmatically there--not at the moment, at least!)

What's this mean for you? Well, not much for the most part. Images uploaded as clues, signature stamps, or event photos will generally look better now. Old images still look blocky and pixelated, though. If you have some older images that have this problem, try uploading new images to replace them with.

In the past, I've always recommended that you "pre-shrink" your photos down to at most 1,000 pixels to a side to help reduce that pixelated look, but with this update, that no longer applies. The maximum file sizes haven't changed so if you take some really high-resolution photos, you could still hit that limit and might need to shrink down the photo to a smaller size anyhow. But that's just a file size limit--not a quality control issue which was where my recommendation originally came from! =)

There are some more tricks and techniques I learned while working on Walking 4 Fun, but those haven't made their way onto AQ as of yet. They will, though... There's definitely more coming down the pipeline! But I'm pretty excited about the dramatic improvements in photo quality. =)

The photos at the top of the blog post are of me with Nancy, MaryK, and Jeannie at the train station in Santiago that I did some of my tests with. The original file was 4000 pixels across and 3000 pixels tall, and I wanted to see how it would look of AQ shrunk it down to a "standard" image size that had a width of 300 pixels--over 90% smaller than the original file. The first photo was how the old code shrunk the file, while the second photo is the newly updated version of the code. You might have to get your face really close to the monitor to really see how bad that first photo is and how much better that second one is, but the difference is remarkable!

AQ would also create thumbnail images for every uploaded file and those were a maximum of 100 pixels to a side--a whopping 98% reduction in size! The difference in quality is even more stunning!

Before
After

1 comment:

MO UR4Me said...

So what is the magic method? It looks like there is nothing in this page code that is rendering the photos smaller, as it appears they're coming directly from Blogspot. I have many sites with photo galleries; I just have a perfectly sized thumbnail with a link to larger sized image usually just display it in the actual pixels. Perhaps your way would be easier.