Optimizing ImageCR

By default, ImageCR prefers to generate high quality images. Coupled with intelligent caching, most consider ImageCR performance and quality excellent. ImageCR does what it is supposed to do as fast as it can.

By default, when ImageCR operates on an image, it is doing a lot of work. We have found most people do not understand or appreciate the amount of processing involved in 2D imaging and ImageCR in general.

Many operations will perform complex math for every pixel and a group of pixels around it. Even with small images, the number of image related formula your CPU is performing quickly hits six digits and beyond.

ImageCR is fast, but if you wish to make it even faster, consider the following :

Caching

You should not have a problem with caching, it is pervasive and automatic by default.

However, if you find you are generating images every time you call ImageCR, you may be using it incorrectly. Learn how ImageCR works, specifically caching. Additionally, make sure you have not accidentally set nocache.

Resampling

The default resampling algorithm, "lanczos", results in a very high quality image, much better than well known desktop applications. You can increase ImageCR performance when generating images by specifying a lesser resampling filter.

The filters are listed in the filter attribute definition from fastest to slowest and on the resampling algorithms page from slowest to fastest. The fastest is "point", which is basically no filter at all. If you still want some quality with your speed, consider items on the list near "point", such as "box", "triangle" or "hermite". The "box" algorithm is a good compromise for those seeking more speed but still want quality. At Efflare Systems, we use the default, "lanczos", 100% of the time, because we prefer the absolute quality.

Still, changes to filter can result in more quickly generated images at a cost of lower quality resizing.

Formats

When saving as certain formats, the image format compression algorithm performs intensive operations to decrease file size.

For images with more compression, ie. lower quality, the algorithm must do more work. Usually, a higher quality image can be created more quickly than a highly compressed, but lower quality image.

Consider increasing quality, thus decreasing compression, to generate the resulting images more quickly.

Similarly, some formats themselves simply require more processing to create than others. If this is a concern, try using another popular format and make sure you understand the benefits of each.

Autonames

For maximum performance after caching, specify explicit output file names. When you do not, ImageCR needs to calculate the autoname every time the tag is called, regardless of image caching. This happens quickly, but it still happens.

If you specify an explicit output file name, ImageCR bypasses the autonaming and detectchanges phases, resulting in improved performance. However, at Efflare Systems we often use the autonaming feature.

Return Values

For maximum performance after caching, instruct ImageCR not to set Return Values with returnextras="0".

This is best used alongside explicit output naming.

In closing...

We know the tag is fast for what it does and have set defaults we find most useful. As long as you are caching images intelligently with the tag, performance should be great.

If you run ImageCR over thousands of images as part of an initial conversion or batch process, expect to wait. If you cannot, you might want to simply implement ImageCR into your application so it creates images as it needs to. This is how ImageCR is meant to be used.

For example, you might not want to call ImageCR explicitly on 50 thousand images daily, especially if those images are updated daily. Instead implement ImageCR into the section of the application which displays the images. ImageCR will create the images as needed and will likely save much processing time.



« Resampling Algorithms (prev) (next) Operation Precedence »

Copyright © Efflare Systems