Run-length encoding is a data compression algorithm that helps us encode large runs of repeating items by only sending one item from the run and a counter showing how many times this item is repeated. Unfortunately this technique is useless when trying to compress natural language texts, because they don’t have long runs of repeating elements. In the other hand RLE is useful when it comes to image compression, because images happen to have long runs pixels with identical color.

As you can see on the following picture we can compress consecutive pixels by only replacing each run with one pixel from it and a counter showing how many items it contains.

In this case we can save only counters for pixels that are repeated more than once. Such the input stream “aaaabbaba” will be compressed as “[4]a[2]baba”.

Actually there are several ways run-length encoding can be used for image compression. A possible way of compressing a picture can be either row by row or column by column, as it is shown on the picture below.

The problem in practice is that sometimes compressing row by row may be effective, while in other cases the same approach is very ineffective. This is illustrated by the image below.

Obviously run-length encoding is a very good approach when compressing images, however when we talk about big images with millions of pixels it’s somehow natural to come with some lossy compression.

Overview

Lossy RLE is a very suitable algorithm when it comes to images, because in most of the cases large images do appear to have big spaces of identical pixel colors, i.e. when the half of the picture is the blue sky. By using lossy compression we can skip very short runs.

First we’ve to say how long will be the shortest run that we will keep in the compression. For instance if 3 is the shortest run, then runs of 2 consecutive elements will be skipped.

Of course if we set the shortest run to be only one element long, this will make our compression completely lossless, which isn’t very effective. However when we talk about millions of pixels even runs of three or more elements are very short, so it’s up to the developer to decide how long will be the shortest run.

Some Examples

Let’s first define the shortest run that we will keep untouched to be at least three element long.

The above image is compressed more effectively than the lossless pixel row from the previous picture.

The thing is how to merge short runs. For instance the following three runs have to be blended into one color run.

We can choose the middle color (option #1) or not, but this will always depend on the picture and it will be effective in some cases and ineffective in other.

Implementation

Implementing run-length encoding is easy in general. Here’s a simple PHP code that shows a lossy RLE.

/**
 * Compresses an input list of objects by losing some data using
 * run-length encoding
 * 
 * @param mixed $objectList
 * @param int $minLength
 */
function lossyRLE($objectList, $minLength)
{
	$len 		= is_string($objectList) 
			? strlen($objectList)		// string as an input stream
			: count($objectList);		// array as an input stream
	$j 		= 1;
	$compressed = array();				// compressed output
	
	for ($i = 0; $i < $len; $i++) {
		if (isset($objectList[$i+1]) && $objectList[$i] == $objectList[$i+1]) {
			$j++;
		} else {
			$l = count($compressed);
			// This is where RLE is converted to a lossy algorithm!
			// In case the run is shorter than a predefined length the
			// algorithm will skip these elements and will stretch the last
			// saved run.
			// NOTE: this logic can be changed in order to take other
			// decisions depending on the goals.
			if ($j < $minLength && $j < $l) {
				$compressed[$l-1]['count'] += $j;
			} else {
				$compressed[] = array('count' => $j, $objectList[$i]);
			}
			$j = 1;
		}
	}
	
	return $compressed;
}

$input = 'aaaabbaabbbbba';

// aaaaaaaabbbbbb
lossyRLE($input, 3);

The code above can be modified in order to work with more complex data. Let’s say we have a “pixel” abstraction as on the example above.

/**
 * Pixel abstraction
 */
class Pixel
{
	private $_color = null;
	
	public function __construct($color = '')
	{
		$this->_color = $color;
	}
	
	public function getColor() 
	{
		return $this->_color;
	}
}

/**
 * Inits the pixels array
 * 
 * @param array $pixels
 */
function init(array &$pixels = array())
{
	$colors = array('red', 'green', 'blue');
	
	for ($i = 0; $i < 100; $i++) {
		$pixels[] = new Pixel($colors[mt_rand(0, 2)]);
	}
}

/**
 * Compresses an input list of objects by losing some data using
 * run-length encoding
 * 
 * @param mixed $objectList
 * @param int $minLength
 */
function lossyRLE($objectList, $minLength)
{
	$len 		= is_string($objectList) 
			? strlen($objectList)		// string as an input stream
			: count($objectList);		// array as an input stream
	$j 		= 1;
	$compressed = array();				// compressed output
	
	for ($i = 0; $i < $len; $i++) {
		if (isset($objectList[$i+1]) && $objectList[$i] == $objectList[$i+1]) {
			$j++;
		} else {
			$l = count($compressed);
			// This is where RLE is converted to a lossy algorithm!
			// In case the run is shorter than a predefined length the
			// algorithm will skip these elements and will stretch the last
			// saved run.
			// NOTE: this logic can be changed in order to take other
			// decisions depending on the goals.
			if ($j < $minLength && $l > $j) {
				$compressed[$l-1]['count'] += $j;
			} else {
				$compressed[] = array('count' => $j, $objectList[$i]);
			}
			$j = 1;
		}
	}
	
	return $compressed;
}

$pixels = array();

// initializes the pixels array
init($pixels);

$compressed = lossyRLE($pixels, 3);

print_r($compressed);

Complexity

In general lossless RLE compelxity is linear – O(n) where n is the number of items from the input stream. Even with the small modification above the complexity remains linear. However we can modify the compression in a slightly different manner (in order to get the middle value from consecutive short runs). This will somehow affect the complexity of the algorithm, of course.

Application

Run-length encoding isn’t a very effective option when compressing texts, but for images where long runs of the identical pixels happen to occur it is quite useful.

Nevertheless RLE is easy to convert into a lossy algorithm, that makes it very suitable for image compression.

Most of the code chunks I’ve seen about getting a file extension from a string are based on some sort of string manipulation.

$filename = '/my/path/image.jpeg';
echo substr($filename, strrpos($filename, '.') + 1);

Howerver there is a more elegant solution.

$filename = '/my/path/image.jpeg';
echo strtolower(pathinfo($filename, PATHINFO_EXTENSION));

Thus you rely on PHP built in functions and it’s harder to overlook the exact string manipulation approach.

Most of the mobile devices today support GPS geo tagging. In fact most of them come bundled with navigation software that uses GPS and therefore all the pictures and (maybe) videos can be geo tagged. But as expected different vendors come with different support and formats.

iPhone OS comes with geotagging both on video and image files, while the latest Android and Symbian (the Nokia main OS for smartphones) can geo tag only images.

Even more – until recently Symbian didn’t support any geotagging before the installation of an additional software – such as Location Tagger . So generally the things are quite simple:

1. iPhone OS geotags both video and image files;
2. Android geotags only images;
3. Symbian geotags only images – and on some devices this is possible only after installing a software;

This is in breve the state of mobile device geotagging!

Why Use GPS Data?

Perhaps one of the main reasons why not support geotagging especially on video files can be the usage of those geo tags. First of all what a geotag means?





You may know that even Android doesn’t “geotag” videos this is not quite true. Because after using you gallery you can see where those videos are shot. This is fantastic, but actually the real information about where the video has been taken is not into the video file, but it’s in an additional log file that keeps it. Thus actually the video files doesn’t know the geo coordinates.

Here comes the problem with video format, because you cannot be sure that every format supports tags that can keep geo coordinates. Actually quicktime’s MOV can store them, while Symbian’s 3GP cannot. In fact Symbian cannot store any geo information about video files!

So now we’ve at least three different formats for each of those three vendors.

1. quicktime for iPhone
2. mpeg-4 with Android
3. 3gp with Symbian

For now I can only say that iPhone can keep the geotag into his video files.





But let me return to the question – why we need this geo tags? Until the video file is on the mobile device – there’s no problem. But once you try to download it – whether on Flickr, YouTube, Picasa, etc. you’ll lose any geo information if it’s not into the file tags. And of course if the above sites can’t read it!

The general reason to store this data into the file is to move it along with the file. Once you move this file from your mobile device to a web platform you’ll see where the file has been created.

EXIF, Exiftool and PHP’s exif_read_data

There are several tools to read geotags. For images, and here we talk only for JPEGs, this is the EXIF information. You can download the exif command line program and try to reed data with it:

exif filename.jpg

Which can result in something like that:

Manufacturer        |Nokia                                                     
Model               |E71                                                       
Orientation         |top - left                                                
x-Resolution        |300.00                                                    
y-Resolution        |300.00                                                    
Resolution Unit     |Inch                                                      
YCbCr Positioning   |centered                                                  
Compression         |JPEG compression                                          
x-Resolution        |72.00                                                     
y-Resolution        |72.00                                                     
Resolution Unit     |Inch                                                      
FNumber             |f/3.2                                                     
Exif Version        |Exif Version 2.2                                          
Date and Time (origi|2011:01:24 12:15:01                                       
Date and Time (digit|2011:01:24 12:15:01                                       
ComponentsConfigurat|Y Cb Cr -                                                 
Aperture            |3.20 EV (f/3.0)                                           
Light Source        |0                                                         
Flash               |Flash did not fire, auto mode.                            
Focal Length        |4.9 mm                                                    
FlashPixVersion     |FlashPix Version 1.0                                      
Color Space         |sRGB                                                      
PixelXDimension     |2048                                                      
PixelYDimension     |1536                                                      
Custom Rendered     |Normal process                                            
Exposure Mode       |Auto exposure                                             
White Balance       |Auto white balance                                        
Digital Zoom Ratio  |1.00                                                      
Scene Capture Type  |Standard                                                  
GPS tag version     |0x02, 0x02, 0x00, 0x00                                    
North or South Latit|N                                                         
Latitude            |42.00, 39.00, 24.67                                       
East or West Longitu|E                                                         
Longitude           |23.00, 21.00, 28.45                                       
Altitude reference  |0x00                                                      
Altitude            |625.50 

While for video files (iPhone) exif cannot help you, this is possible through Exiftool. With it you can read even iPhone video geotags:

./exiftool filname.mov

In addition this information can be read with PHP via exif_read_data:

$info = exif_read_data('filename.jpg');
var_dump($info);

And this will give you not only standard tags, but geo tags too.

The title may sound unclear enough, but the task is simple. You’ve to make a file download process within a Zend Framework’s controller. Let’s assume we’ve the DownloadController setup:

In PHP there are at least three simple lines of code that will do the job of downloading a file.
header('Content-Type: image/jpeg');
header('Content-Disposition: attachment; filename="logo.jpg"');
readfile('images/logo.jpg');

Note that here there is a content-type header, which is important cause the browsers understands what kind of file is supposed to be downloaded. The second line suggests a name of the downloaded file and the third one returns the file to the client.
Download a File ... within Zend Framework
Those three lines wont work alone in a ZF application, because there's no view, but even if you create a .phtml (view) file for this action it won't work, because the header of the returned file is modified.
The question is how to possibly return the file for download, perhaps write some statistics to the database and if there's a problem (some permission issues for instance) return a message to the user.
The Basic Solution
The solution is simple. First make it work by disabling the view and possibly the layout for this action:
public function indexAction()
{
	header('Content-Type: image/jpeg');
	header('Content-Disposition: attachment; filename="logo.jpg"');
	readfile('images/logo.jpg');
	
	// disable the view ... and perhaps the layout
	$this->view->layout()->disableLayout();
        $this->_helper->viewRenderer->setNoRender(true);
}

Than add some code where you can check the permissions. Just because there's no view for this action you can redirect to another - errorAction():
public function indexAction()
{
    if (userHasNoPermissions) {
        $this->view->msg = 'This file cannot be downloaded!';
        $this->_forward('error', 'download');
    }

    header('Content-Type: image/jpeg');
    header('Content-Disposition: attachment; filename="logo.jpg"');
    readfile('images/logo.jpg');

    // disable layout and view
    $this->view->layout()->disableLayout();
    $this->_helper->viewRenderer->setNoRender(true);
}

But that still will prompt you a file to download, so there should be a return statement that will return false:
public function indexAction()
{
    if (userHasNoPermissions) {
        $this->view->msg = 'This file cannot be downloaded!';
        $this->_forward('error', 'download');
        return FALSE;
    }

    header('Content-Type: image/jpeg');
    header('Content-Disposition: attachment; filename="logo.jpg"');
    readfile('images/logo.jpg');

    // disable layout and view
    $this->view->layout()->disableLayout();
    $this->_helper->viewRenderer->setNoRender(true);
}

So here's the complete source of DownloadController.php:
view->msg = 'This file cannot be downloaded!';
	        $this->_forward('error', 'download');
	        return FALSE;
	    }
	
	    header('Content-Type: image/jpeg');
	    header('Content-Disposition: attachment; filename="logo.jpg"');
	    readfile('images/logo.jpg');
	
	    // disable layout and view
	    $this->view->layout()->disableLayout();
	    $this->_helper->viewRenderer->setNoRender(true);
	}	
	
	public function errorAction()
	{}
}

and the error.phtml:
msg ?>


Related posts:

Setting Up Global Cache in Zend Framework 
Models in Zend Framework – Initialize All Methods with init() 
Upload a File with Zend Framework 
Download Images with PHP 


]]>
			/2010/05/25/download-files-with-zend-framework/feed/
		7
		
		
		
		/2009/04/07/optimize-your-images-improve-the-performance/
		/2009/04/07/optimize-your-images-improve-the-performance/#respond
		Tue, 07 Apr 2009 05:39:19 +0000
		
				
		
		
		
		
		
		
		
		
		
		
		
		
		

		/?p=473
		

Related posts:

When you should use base64 for images 
Optimizing the web. Start with the images! 
Replace the Broken Images with a Default Image with JavaScript 
PHP Strings: How to Get the Extension of a File 


]]>
				Overview
In a series of articles I’ll share what’s my experience with image optimization. Of course the most images you have the most page weight you have. That’s why optimizing your images should be your primary task.
Image Formats
First, I’m gonna mention several formats, which everyone of the webdevs are using widely. There are GIF, JPEG and PNG, where PNG can be either PNG8 and PNG24 (PNG32 is also available as name of that format).
What are the differences between them and when to use one or another?
Well some of us just use one or another even without knowing the difference or without thinking about the optimization. I remember when I just put the images in JPEG with no idea what are the other formats before.
In fact all the formats has pros and cons.
JPEG
The JPEG format can be either progressive or baseline. The difference is that the progressive JPEG can be loaded directly in the browser with very low quality and then to load with better quality. Some experts insist that this is old school, but I don’t think so. When the image is not the required one (think of a wallpaper preview) the user can skip and go to another without waiting the hole image. The baseline JPEG is loading the good quality image but starting from top to bottom. With portions of the image.
IE and progressive JPEGs
Of course the Internet Explorer 6 don’t support the progressive downloading of an JPEG even if it’s progressive. Well this is no issue till the IE loads the image like a baseline JPEG.
Which JPEG is progressive and which is baseline
You can certainly make some test to determine which JPEG is progressive and which is baseline, from the loading behaviour in your browser. If you’d like to convert an image to a progressive JPEG or baseline you can use a free open source programs out there in the wild online space. Once they are converted to one or another format you can use them widely. Because most of the tools are comand line open source tools you can automate them on the server where the user uploads it’s images. Now every big image can be converted to be progressive.
When to use progressive and baseline JPEGs?
Well the tests show that for images small than 10 K best compression you get with baseline, and for bigger images the small size you get is with progressive JPEGs. There’s the rule use the baseline for thumbs and progressive for any other big image.
GIF
This format is well known from the early ages of the web. It allows transparency and animation. Actually the problem with the GIF images is that they don’t support semi-transparency which is a problem nowadays. Today the web users are used to good quality images and somehow the GIF is not suitable. But it’s still the most used format for icons and of course animations.
When should I use GIF?
Well as I’ll mention in a while the PNG8 is a better format than GIF for transparent small icons. But if you should use some kind of an animation like ajax loading circle (or bar) the GIF format is suitable for you. Than you must use a GIF.
PNG
As I said PNG can be either PNG8 or PNG24 (which is also called PNG32). Actually PNG8 acts just like GIF, with the important exception that it supports semi-transparency, but yet again on every browser except IE6. In IE6 the PNG8 is just the same like GIF which is not so bad. If you’d like to use GIF for an icon, you should make it PNG8. There are semi-transparent pixels (except IE6 and above) and you get better experience on other browsers than GIF.
PNG32 transparency?
In fact PNG32 is not transparent on IE6 (on transparent pixels IE puts some kind of gray pixels). There you can use AlphaImageLoader filter, but that can dramaticaly slow down your browser, so it’s not a good idea.
You should avoid the PNG32 transparent images and the usage of AlphaImageLoader filter.
Conclusion
For every of these formats there lots of tools that remove system information from the image crash and crunch the files so that they become smaller. They can be automated and used on the server.
Now when you use different formats you can be aware of the differences between them and to use the appropriate ones.

Related posts:

When you should use base64 for images 
Optimizing the web. Start with the images! 
Replace the Broken Images with a Default Image with JavaScript 
PHP Strings: How to Get the Extension of a File 


]]>
			/2009/04/07/optimize-your-images-improve-the-performance/feed/
		0