Blog

Tagged by 'exif'

  • An image doesn't just consist of pixels. It is a container full of additional information and structural inefficiencies hidden from the naked eye. When you capture a photo with a smartphone or a professional DSLR, the resulting file is almost always significantly larger than it needs to be for the web.

    This "image bloat" generally falls into two categories: Informational and Structural.

    • Informational: EXIF (Exchangeable Image File Format) data is metadata stored within the image header that includes GPS coordinates, camera serial numbers, and date-time stamps. While useful for photographers, this data adds unnecessary kilobytes to every upload and can even pose a privacy risk.
    • Structural: This is mainly down to resolution overkill, where modern cameras capture images at 12MP or higher - perfect for a billboard print, but massive for a website. But other reasons could be due to Sensor Noise where the digital sensor captures random variations in colour that the human eye can't distinguish, but the file's compression algorithm works overtime to preserve.

    The Hidden Cost of Raw Uploads

    When it comes to the process of uploading images through an online, we are often causing unnecessary strain on the end-user's connection as well as our own servers. By forcing a browser to transmit raw, unoptimised files, we create a high probability of failure through multiple, redundant requests.

    Every time a user on a unstable connection attempts to push a 10MB high-resolution photo, they are essentially gambling with the connection's stability. If that connection blips at 95%, the request fails, and the server is left with garbage data it can't use. The user is forced to start the entire process over again. This cycle doesn't just waste bandwidth; it inflates server CPU usage as it struggles to manage timed-out threads and increases the physical storage costs for data that the user never actually intended to be so large.

    Real-World Scenario

    I encountered this exact bottleneck while developing a valuation form. In this scenario, users were required to upload multiple high-quality photos of their assets for appraisal. On paper, this sounds simple. However, in the real world, users aren't always sitting on high-speed fibre-optic broadband. They are often out in the field, where the connection could be unstable.

    What was required is the ability for the image to be compressed on the users device before the upload process even starts. I found a JavaScript library that was worth a try: browser-image-compression.

    How The Client-Side Compression Works

    This library works by leveraging the browser's internal Canvas API and Web Workers to perform a digital reconstruction of the image. When a file is processed, it is drawn onto an invisible canvas at a set resolution, which instantly strips away all bloat like EXIF metadata and GPS coordinates. Then re-encodes the pixels using lossy compression algorithms to discard high-frequency noise.

    This entire magical process happens on a background thread (Web Worker), the image is crunched down to a fraction of its original size without freezing the user interface, ensuring the new lean file is ready for a faster upload.

    Results

    The difference in upload performance was night and day. Images that were originally 8–10MB were now being compressed to approximately 900KB. It is worth noting that the compression could have been even more aggressive; however, we capped the maximum size at 1MB, as we felt that was the perfect "sweet spot" for maintaining high visual quality in this scenario.

    By hitting that 900KB mark, we effectively reduced the data transfer requirements by 90%!

    Demo

    To see these performance gains in action, I have put together a live demo where you can upload your own high-resolution photos and see the real-time reduction in "image bloat" without any loss in visual quality.

    Browser Image Compression - Demo

    Conclusion

    Implementing client-side compression isn't just a nice-to-have feature. It is a fundamental shift in how we handle user data and server resources. By moving the processing to the user's device, we achieve three major wins:

    • Reliability: Small files don't just upload faster; they succeed more often. By reducing an 8MB file to 900KB, you remove the timeout risk that plagues users on unstable connections.
    • Privacy by Default: Because the library reconstructs the image on a canvas, sensitive EXIF data and GPS coordinates are stripped before they ever reach your cloud storage. This reduces your liability and protects your users.
    • Infrastructure Savings: The backend no longer needs to spend expensive CPU cycles stripping metadata or resizing massive blobs. You save on bandwidth, processing power, and long-term storage costs.
  • My Fujifilm X100F camera only comes out of hibernation when I go on holiday. Most of the time, I fail to ensure my camera settings are correct before I take the very first snap. This happened on my last holiday to Loch Lomond.

    When it came to the job of carrying out some image processing from RAW to JPEG, I noticed all of my photos EXIF dates were incorrect. I am such stickler for correct EXIF information, including geolocation wherever possible. EXIF information is so useful for cataloging when consumed by photo applications, whether it’s on my Synology or uploaded to Google Photos.

    Due to the high number of photos with incorrect date stamps, I needed a tool that will automate the correction process. After a bit of Googling, I found an application called exiftool by Phil Harvey that allows the EXIF date/time stamp to be modified using a method in the documentation called “Shift”.

    The exiftool has no GUI (graphical user interface) and will need to be run in Terminal on a Mac or command line for Windows users. The command to use is relatively simple and the only complex thing you will have to do is calculate how many days, months, years, hours, minutes and seconds you need to add or subtract.

    In my case, the calculation was a matter of subtracting 3 days from all the photos and the command to do this looks like the following:

    exiftool -AllDates-='0:0:3 0:0:0' -m /Volumes/LochLomond
    

    Lets breakdown the command to get a better understanding what each part does.

    • exiftool: Runs the application and you have to ensure that your Terminal/Command Line is run in the same directory exiftool is housed.
    • AllDates: Modifies all dates in a photo.
    • -=‘0:0:3 0:0:0’: Subtract 3 days off the photos exif date. If you wanted to add 3 days, use “+=” instead. The date time format is presented as “<year>:<month>:<day> <hours>:<minute>:<second>”.
    • -m: Ignore minor errors and warnings (as stated in the documentation).
    • /Volumes/LochLomond: Location to where all the photos reside.

    When making mass changes to files, it’s always recommended to ensure you have a back up of all photos for you too fallback on if you accidentally mess up the EXIF update.

Support

If you've found anything on this blog useful, you can buy me a coffee. It's certainly not necessary but much appreciated!

Buy Me A Coffee