Using Huffman Coding to Compress Images Taken by the iPhone Camera

Using Huffman coding to compress images taken by the iPhone camera

If you mean the image files (like jpg, png, etc), then you should know that they are already compressed with algorithms specific to images. The resulting files would not huffman compress much, if at all.

If you mean that you are going to take the UIImage raw pixel data and compress it, you could do that. I am sure that the iPhone could handle it.

If this is for a fun project, then go for it. If you want this to be a useful and used app, you will have some challenges

  1. It is very unlikely that Huffman will be better than the standard image compression used in JPG, PNG, etc.

  2. Apple has already seen a need for better compression and implemented HEIF in iOS 11. WWDC Video about HEIF

  3. They did a lot of work in the OS and Photos app to make sure to use HEIF locally, but if you share the photo it turns it into something anyone could use (e.g. JPG)

  4. All of the compression they implement uses hardware acceleration. You could do this too, but the code is a lot harder than Huffman.

So, for learning and fun, it's a good project -- it might be easier to do as a Mac app instead, but for something meant to be real, it would be extremely hard to overcome the above issues.

Are algorithms like Huffman coding actually used in production?

From Wikipedia on the subject:

Huffman coding today is often used as a "back-end" to some other compression methods. DEFLATE (PKZIP's algorithm) and multimedia codecs such as JPEG and MP3 have a front-end model and quantization followed by Huffman coding (or variable-length prefix-free codes with a similar structure, although perhaps not necessarily designed by using Huffman's algorithm).

So yes, Huffman coding is used in production. Quite a lot, even.

Create JPEG thumb image with general fixed header

I'm afraid you cannot do that using built-in method of each platform. The problem is in the compressing phase.

There are a number of variables in JPEG compression, including the type and breakdown of scans, samples, DHT selection, and DQT selection. If any of those are different in the encoder you use, you are going to get different output. It's the nature of the beast.

For example: The Define Huffman Table (DHT) define how the "image data" (after SoS segment) was compressed. And you use fixed Huffman tables only for decoding, that’s what caused the problem.


So you may have some options to choose:

  • Send the full quality image (without compressing) after scaled down to max dimension 30px as preview thumb photo.
  • Write your own compression algorithm or use a cross-platform library.
  • Upload entire original image to your server to process & send back the "minified data" to Android/iOS.

Telegram has preview photo too, and their approach is similar to you. But they transfer entire original image (in byte array) to server, create a thumb photo, strip out "fixed header" and send back to the receivers the "minified data".

When receive on mobile, they decode the "minified data" to bitmap, by appending it with "fixed header" (Bitmaps.java#L111) & update image size in SoF segment. See ImageLoader.java#L750.

What information is stored in EFIX/JPEG photos taken on the iPhone with geotagging enabled?

Okay, good news :). The direction is stored in GPS Img Direction. Here's what I was able to get from a photo taken from an iphone (with location services and compass turned on) using the ExifTool mentioned by @rwong.

ExifTool Version Number         : 8.34
File Name : photo.JPG
Directory : C:/Documents and Settings/user/My Document
s/Downloads
File Size : 349 kB
File Modification Date/Time : 2010:10:19 14:05:39-06:00
File Permissions : rw-rw-rw-
File Type : JPEG
MIME Type : image/jpeg
JFIF Version : 1.01
Exif Byte Order : Big-endian (Motorola, MM)
Image Description : Back Camera
Make : Apple
Camera Model Name : iPhone
Orientation : Horizontal (normal)
X Resolution : 72
Y Resolution : 72
Resolution Unit : inches
Software : 4.0.1
Modify Date : 2010:10:19 14:00:52
Y Cb Cr Positioning : Centered
Exposure Time : 1/146
F Number : 2.4
Exposure Program : Program AE
ISO : 80
Exif Version : 0221
Date/Time Original : 2010:10:19 14:00:52
Create Date : 2010:10:19 14:00:52
Shutter Speed Value : 1/146
Aperture Value : 2.4
Metering Mode : Average
Flash : Off, Did not fire
Focal Length : 3.9 mm
Subject Area : 1295 967 699 696
Flashpix Version : 0100
Color Space : sRGB
Exif Image Width : 1296
Exif Image Height : 968
Sensing Method : One-chip color area
Exposure Mode : Auto
White Balance : Auto
Scene Capture Type : Standard
Sharpness : Hard
GPS Latitude Ref : North
GPS Longitude Ref : West
GPS Time Stamp : 14:00:46.81
GPS Img Direction Ref : True North
GPS Img Direction : 32.52336904
Image Width : 1296
Image Height : 968
Encoding Process : Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components : 3
Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2)
Aperture : 2.4
GPS Latitude : 45 deg 14' 58.20" N
GPS Longitude : 121 deg 39' 4.80" W
GPS Position : 45 deg 14' 58.20" N, 121 deg 39' 4.80" W
Image Size : 1296x968
Shutter Speed : 1/146
Focal Length : 3.9 mm
Light Value : 10.0


Related Topics



Leave a reply



Submit