V9 SDK Correction Speed

This FAQ will look at various factors that determine the processing time when using our Perfectly Clear Server SDK.

Executive Summary

How fast is Perfectly Clear? In summary, we can correct an average of 20,000 images per hour.

This handy graph gives you an idea of how many images can be corrected per hour depending on average image size.

This is typical performance when using our new iAuto ’21 correction parameters on images with a range of content.

Let’s Get Into the Details

Major factors influencing the processing time include:

  1. Size in megapixels of the images being processed
  2. Corrections being applied
  3. Overall performance of the server
  4. Implementation method

Let’s look at each of these separately…

Image Size

Larger images require more processing time, so the time per image will grow and image size increases. But, processing efficiency increases as image size increases – so processing 100 files that are 1MP is slower than processing 10 files that are 10MP. We used 10MP images to gather all the data below, and the final chart shows processing performance for a range of image sizes.

Image Correction Settings

Enabling more image correction settings will add to processing time. The chart below shows the relative amounts of time of each major component of the v9 SDK when processing 10 megapixel JPEG files:

  1. I/O: this is the time required to read the JPEG file, decompress it, and then re-compress into JPEG and write the corrected image back to disk. Note that if you are adding Perfectly Clear to an existing image editing system, this work in likely not necessary – which allows for a very substantial speed gain.
  2. Calc: This is processing that happens regardless of the parameters being applied and is also largely independent of file size.
  3. Core: These are the main corrections applied to nearly every image: exposure, contrast, saturation, depth, sharpness, etc. This is about making the PHOTO look it’s best. Read more here.
  4. Beautify: this is about making the PEOPLE in the photo look their best: Perfect Skin, Perfect Eyes, Perfect Face. Read more here.
  5. Noise Removal: our powerful noise removal will only run if noise is detected – but the detection process itself takes some time. The time in the chart is for images containing noise.
  6. Creative LOOKs: the Creative Enhancements allow you to apply your creativity and take it to the next level. These photo enhancements give you even more control over your image, and you have the option to get a little more inventive with the image! Read more here.

Server Performance & Multi-threading

The Perfectly Clear SDK itself is multi-threaded, so processing a single image will use several CPU cores automatically to speed up the overall image processing. But, processing several images in parallel still provides a substantial processing speedup. The exact threading benefit you will see if heavily dependent on hardware details – CPU cache sizes, memory bandwidth, total RAM available, and others – but the chart below is indicative of the type of speed gains you should expect.

This data was gathered on an 8 CPU server. Speed gains begin to diminish after 5 or 6 concurrent images are being processed.

Perfectly Clear is also optimized for the AVX2 CPU instruction set – which is available on most Intel and AMD CPU produced after 2015. AVX support will improve performance by roughly 33% – and all reporting in this FAQ is using AVX. We do provide separate libraries without AVX support, to support legacy hardware.

Implementation Method

The manner the SDK is implemented plays a substantial role in the overall processing time. There are three main ways Perfectly Clear is typically implemented, so let’s look at each

1. Using our Command Line application

This is the simplest approach, and companies can usually be up-and-running with this method in under a day. The Perfectly Clear SDK includes a pre-build, production-ready command line tool that you can integrate directly on your servers. It can process a single image, a list of images, or an entire folder of images.

While this is the easiest to implement, it also has the lowest overall throughput. This is due to two main reasons. 1) File I/O is required, as much as 40% of the total processing time might be used just reading and writing JPEG files, and 2) you will have less fine-grained control over the number of simultaneous images being processed – unless you include a queueing system.

2. Building the SDK into an existing correction pipeline

This is the most efficient and most performant method – it eliminates the need for file I/O entirely, utilized RAM most efficiently, and you gain finer control over threading and concurrency. However, this also takes the most development & deployment effort. If performance is a major priority, this method provides the best opportunity.

3. Hybrid Integration Approach

There are many options in between the two approaches above – you can build you own command line application that is more tuned to your working environment, or you can integrate our SDK directly, but still work on image FILES instead of image DATA that is already read and uncompressed. This approach is the most common, and the performance lines between the two previous methods.

So, What Throughput Can I expect?

We ran tests on real-world images, using an AWS c5d.2xlarge instance with 8 CPU’s and 16 GB RAM, with both our command-line application and well as a custom-built SDK integration that omits file I/O. The results:

This is typical performance when using our new iAuto ’21 correction parameters on images with a range of content. Throughput scales linearly with hardware capability – so a 16 CPU instance would be expected to double this performance.

Data for this FAQ was gathered Feb 2021

Keep Reading