Does ACR cache use all allocated space regardless?

[Beemer]

I have set Camera Raw to use 65GB.   That done,  I was surprised that my separate scratch disk that holds this cache actually has used all 65 GB with 5140kb  .dat files.

How can I check if this usage should be as large?

Ian

[Schewe]

I have set Camera Raw to use 65GB.   That done,  I was surprised that my separate scratch disk that holds this cache actually has used all 65 GB with 5140kb  .dat files.

This is as designed. If you tell the cache to be 65GBs, it'll keep writing cache until it reaches 65GBs at which point when new cache is written, the oldest cache is deleted to keep the max of 65GB. If you have more free space, you might consider upping the limit.

[Redcrown]

I have not paid much attention to the ACR cache, so this question made me curious. Curious enough to do some research and some testing.

Google research led to a lot of bad info, mostly due to confusion between the Bridge cache, the Photoshop cache, the Lightroom cache. A lot of "experts" seem to think the cache contains previews. I don't think that's true.

I finally found this site: http://www.pixiq.com/article/camera-raw-cache

That link contains the following quote, "The early part of the process includes decoding, decompressing, linearizing, hot pixel filtering, and demosaicing an image. The results of this are the same each time, so for this reason, it’s perfectly legitimate to use a cached version of this as the basis for a preview."

That makes good sense, but the key words there are "as a BASIS for a preview." The actual preview you see in ACR has to have the ACR defaults applied. At a minimum, the true preview has to have a camera profile applied.

My first simple test was to bang away in ACR with adjustments on a single raw file. No matter what you do in ACR, the ACR cache file never changes after its initial creation. Seems to support the above claim that the cache file contains only the "basis." Also, note that if you open a tif or jpeg in ACR, no ACR cache file is created (so where does the ACR preview come from?)

My next test was to purge the cache, then open 8 raw files in ACR and look at the sizes of the cache files. The files were from a Canon 5D2 (5616x3744 pixel images). They cache files varied from 246kb to 107kb. Correlating the cache files to the images, it appears the differences are due to the level of detail in the images. Lower detail equals lower cache file size. So, it appears there is some kind of compression going on. Just like with jpegs, lower detail equals greater compression and smaller file size.

Then I purged the cache and loaded 8 images into ACR again, timing the result with a stopwatch. It took 5 seconds for all the thumbs to appear in ACR and for all the yellow triangle explanation marks to go off. Then I simply did it again with the previous cache in place. This time it took 4 seconds.

Even given a generous degree of error due to such a small sample and manual stopwatch timing, that's not much savings. And given that most of the time you are opening one image at a time, the time saved by the cache is a small fraction of a second. So, my conclusion is that the ACR cache is of very little value. Why waste several gigabytes of disk space on it?

But then a great mystery occurred. In previous tests I opened 8 images at a time by selecting them in Bridge and opening in camera raw. I purged the cache again and opened some of these same images one at a time. When opened one at a time, the cache file created is larger than when opened in a batch. A lot larger. An average of 2.6 times larger, with little variation in that ratio. And there is more mystery. When opening a batch of images, the cache for the first image is the same size as when it's opened alone. Only the 2nd through the last images get smaller cache files than when opened alone.

I can't figure out that mystery. Would appreciate someone else doing the test to confirm.

All this is on Win7 64bit with CS6 and ACR 7.1.

[digitaldog]

The other option you can look into, assuming you're not opposed to DNG is the new Fast Load Data option. Here a similar approach to speed up previews in Develop exist but that data resides inside your DNG's and there's no rolling cache (no limit to set or cache data to eventually lose). I've set the ACR cache as low as possible. Also, if you travel with your images, the ACR cache would in theory need to travel with them as well so you'd have to come up with a means to sync the data on differing drives, which isn't an issue with DNG.

[Redcrown]

Andrew makes a good observation about the new "fast load" option of DNG. If you create DNGs with fast load data, NO cache files are created when you open them in ACR. And it appears that ACR is slightly faster preparing DNG fast load files than other raw files with cache data. Most likely because ACR does not have to do the extra I/O to read the cache file.

However, that speed advantage is still very small, while the increase in disk usage is significant.

I tested a batch of 20 random raw files, converting them to DNG both with and without the fast load option. The fast load data added an average of 387kb per file. That's a significant chuck of disk, especially when you have thousands or tens of thousands raw files.

Opening the DNG files one at a time in ACR, I can't see any speed difference between "fast load" DNG files and normal files (cached or not cached). I'm sure it's there, but somewhere around 0.2 of a second, so virtually invisible.

It takes my system about 5 seconds to open the entire batch of 20 "fast load" files. It takes 6 to 7 seconds to open the same 20 "no fast load" files when they have no existing cache. Again, not a significant advantage.

I'm not in the habit of opening large numbers of raw files in ACR. I know some people like to do that so they can adjust one file and "sync" all the others. I find it easier to open and adjust just one file, then use Bridge to copy those adjustments to multiple files.

I suspect that the whole concept and logic of the ACR cache is a legacy from the time when we had very slow, single core processors. Saving CPU time was far more important back then than it is now. But with current technology, I'd argue that the "best practice" is to avoid DNG "fast load", and set the ACR cache to the minimum 1GB. It's unfortunate that you can't turn the ACR cache completely off.