Lightroom/Camera Raw: Why does standard preview size affect acr cache entry size?

  • 2
  • Question
  • Updated 7 years ago
  • (Edited)
I thought standard preview size was for non-1:1 library viewing only (and fleeting develop views), and acr cache entries were for develop view only (including 1:1).

Why does standard preview size affect acr cache entry size?
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 376 Reply Likes

Posted 7 years ago

  • 2
Photo of Mark Sirota

Mark Sirota

  • 146 Posts
  • 29 Reply Likes
Are you saying that the preview dimension and/or quality setting is affecting the size of the files in the Camera Raw cache?

(The Camera Raw cache is not for develop-only -- it is for any rendering task, including preview generation, export, print, ...)
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 376 Reply Likes
Mark Sirota said: "Are you saying that the preview dimension and/or quality setting is affecting the size of the files in the Camera Raw cache? "

Yes - The filesize of the acr cache entries (example filename: Cache0000000001.dat) depends on standard preview *size*. It does *not* depend on standard preview *quality*.

This table shows standard preview size and corresponding cache entry size:
1024 pixels - 4336 KB
1440 pixels - 8571 KB
1680 pixels - 11673 KB (not a typo)
2048 pixels - 5101 KB (not a typo)

which begs 2 questions:
1. Why is there a dependency at all.
2. Why is the size smaller at 2048 than 1680.

The end-game of this inquiry is to come up with a solution to the problem of ACR cache not speeding up (develop mode) rendering by any noticeable amount.

I just double-checked: cache is used for export rendering as well as develop mode, so I ran a formal test (timing multi-photo exports): Exports take the same amount of time to render whether cache entries are present or not - its official: the ACR cache does not improve rendering speed by a measurable amount.

Thank you in advance for any help you may provide,
Rob
Photo of TK

TK

  • 531 Posts
  • 109 Reply Likes
If standard preview size affects acr cache entries then the latter are apparently only used for previews (e.g., in the Develop module). They should have no use for exports, etc.

The cache entry size for 2048 pixels should be ~3.4 times bigger than it is, based on extrapolation. I'm also curious what is happening here.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 376 Reply Likes
ACR cache entries are *written* when an export is done. Whether they are ever read or not, I've no clue. But if writing them is correct behavior, then it stands to reason if they were already present, they would be read instead ( although not necessarily).

On the other hand, if their dependence on standard preview size is correct, then at least some of the data is being computed for the sake of the lib previews, no?
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 376 Reply Likes
Here's a theory:

The ACR cache entries don't do squat for the sake of the develop mode nor exports (speed-wise). And if previews are already generated, then they don't do squat for lib previews either, but maybe there is a tiny gain when regenerating lib previews when there is an ACR cache hit(?)

And, maybe the reason the size is smaller when standard preview size is 2048 is that its so close to 1:1 that it simply computes less data for the preview pyramid - using 1:1 data instead.

I don't know if this is correct, but it would certainly explain what I see - dunno 'bout U.

I'll check my theory and report back...
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 376 Reply Likes
I can see no value in the ACR cache whatsoever - everything I test is same speed with or without. Dunno how to test my theory about the smaller cache entry filesize when standard preview size is 2048 - I'm all out of ideas...
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 376 Reply Likes
Really? Nobody who knows the answer is willing to share it??