What is the purpose of the BigTableGroupCache folder?

[redcrown on guard]

I've discovered another Adobe garbage dump. On Win11, in my ...User/AppData/Local/Adobe/CameraRaw folder there is now a subfolder called BigTableGroupCache. Mine had 1 gigabyte in over 700 files named "Table..." followed by a long string of meaningless letters. The oldest files had creation dates in October 2024, which is when Camera Raw version 17 was released.

Google says "Bigtable is a distributed, scalable NoSQL database service offered by Google Cloud", but says nothing about Adobe's use of BigTable.

So I closed all things Adobe and deleted everything in BigTableGroupCache. Then I launched Bridge and Photoshop and browsed and processed a few raw files in ACR with no problem. The BigTableGroupCache was repopulated with files for the raw images I processed. Next, with Bridge and Photoshop still loaded, I deleted everything in BigTableGroupCache again. Then opened and reprocessed the same raw files, again with no problem. BigTableGroupCache was again repopulated.

Then I noticed not all raw files I processed caused an entry in BigTableGroupCache. Turns out only raw files with Denoise AI applied show up. Same as the *.acr files that now get created when you do anything "AI" in ACR.

So, apparently the Adobe BigTableGroupCache folder serves no purpose. It just keeps logging files which don't get used again. Note this is all separate from the regular Camera Raw cache, which is still there and can be cleared from within Camera Raw. There is no option with Adobe Bridge, Photoshop, or Camera Raw to clear BigTableGroupCache.  So, beware... some more useless gigabytes will pile up over time.

[MadManChan2000 · Accepted solution]

This is a folder of cached data to make images load faster when they use certain AI-related settings.  This includes AI Denoise (as you've pointed out), Reflection Removal, Super Resolution, Distracting People Removal, and others.  It particularly makes a difference in loading and image walking (switching from one photo to another photo) if the photo has many such edits.  Deleting or clearing the folder will reduce disk space usage, but will slow down your image-loading and walking performance.  This is why it's called a "cache" and why the word "cache" appears in the folder name.

[CapnMario]

Thanks for the info on this, I've been following the problem on a different forum.
Could you clarify though; If this is caching AI related edits like "Distracting People Removal", will deleting the cache cause the image to be regenerated, possibly changing the look? 

Thanks,
Mario

[redcrown on guard]

Wow! I'm impressed and honored that MadManChan showed up here. Thanks. But I'm a little confused and need to ask, what do you mean by "images load faster"? Load into what? Load from Bridge into ACR? Load from Bridge or ACR into Photoshop?

I did a couple quick tests to try to understand. First I used Bridge to copy 8 raw files with Denoise AI into a temp folder and deleted all in BigTableGroupCache. Then I selected all those 8 files in Bridge and opened in Camera Raw. That was fairly fast, about 3 seconds, and BigTableGroupCache got repopulated. So I did it again, opened the same 8 denoised raw files in Camera Raw. That was slightly faster, about 2 seconds. I repeated this several times, always the same result. Slightly faster when BigTableGroupCache is populated. But isn't the difference due to the time it takes to repopulate BigTableGroupCache?

Next test, I selected the 8 Denoised raw files in Bridge and did a "Load files into Photoshop layers". This took 18 seconds with BigTableGroupCache fully populated. It also took the same 18 seconds with BigTableGroupCache empty. And when BigTableGroupCache was empty the Load into Photoshop layers did not repopulate it. Another variation: I deleted the acr and xmp files for these 8 files (so, really raw raw) and loaded them as layers. Same 18 seconds!

Another test, I took 1 Denoised raw and made 18 duplicate copies in a folder. When I opened all 18 at once in ACR via Bridge I only got 1 entry in BigTableGroupCache. So I opened them one at a time. Still only one entry in BigTableGroupCache. So I applied one different exposure adjustment to several of them. Still only 1 entry in BigTableGroupCache. This is a mystery -- does Adobe recognizes enough similarity in raw images to let them share a single entry in BigTableGroupCache?

Bottom line for me: Wipe out BigTableGroupCache and do it often. The benefit of faster "loads" is questionable, and not worth the cost of letting those gigabytes pile up on your system drive and bloat your backups.

[redcrown on guard]

Yet another interesting test. I used an image with people standing in front of a building. There were 16 people in 4 clusters.

Starting with raw raw (no settings) I first let ACR find and remove all the people, then clicked Done without opening in Photoshop. It found the 4 clusters and removed all. Although it added one new person of its own invention where one of the clusters used to be. But the big surprise, I got 6 new "Index" files and 8 "Table" files in the BigTableGroupCache. All from that one remove people step.

Then I reopened the image in ACR and did a Denoise. That got me one new Table file and all the Index files were updated. It also turned on the yellow "AI Edit Status" icon, and told me I needed to update the Remove People. So I did. And now I had 17 Table files in BigTableGroupCache! I assume one Table file was for the Denoise, 8 were for the first Remove People, and 8 more for the second (update) Remove People.

I repeated the sequence but did the Denoise first, then the Remove People. That way I got no AI Update Status warning, and no extra Table files in BigTableGroupCache.

But even more fun followed. I started over with raw raw and an empty BigTableGroupCache. I opened the image in ACR and deleted 1 person by hand (no auto detect, no Denoise), then clicked Done. Nothing showed up in BigTableGroupCache. I kept doing this, removing 1 person at a time until I had removed 8 of the 16. Still nothing in BigTableGroupCache. Mysteries abound.