As long as I can remember (which is a long time), Bridge has forced re-caching of its thumbnails every time a new version of Camera Raw is installed. I just installed 2018 and here we go again.
I've participated in numerous forum discussions over the years, provided ample evidence of the issue, yet Adobe still can't seem to get it. And it seems like a simple problem with an easy solution.
I've got over 30,000 images in folders, 100 to 500 images per folder. I "Export Cache to Folders" and keep the main cache size small. So, when I navigate to a folder, Bridge copies the folder cache to the main cache and displays the thumbs. That's very quick. Unless Bridge decides the cache thumbs are "out-of-date", in which case it scans all the main images to rebuild thumbs. That's very slow and gives sluggish performance - from 2 to 5 minutes depending on folder size and image type (raw files take much longer). Many hours over many weeks as I browse my 30,000 images.
Why does Bridge decide the thumbs are out-of-date? Why is it using Camera Raw to make that decision? I can only guess, and my guess is that there is a difference in precision of the dates. Bridge compares the date of the main file to the date of the thumbnail, and they are off by some small fraction of a second. If that's the case, then the solution is obvious. Round the two dates to the whole second.
Is the option "Prefer thumbnail generation over preview generation" checked or unchecked.
The "prefer thumbnail generation" is checked on my system. Must be the default, as I've not paid any attention to that one. Strangely, neither Google nor Adobe Help shows any info on that option. What does it do?
Regardless, I doubt it has any impact on the problem of regeneration. I've kept copies of Camer Raw.8bi back to version 8. When a new version of Camera Raw or Bridge starts re-caching everything, I simply replace the new version of Camera Raw with the most recent old version to test. Re-caching stops. Put the new version back, and re-caching starts again.
Let Bridge cache a few folders with a new version of Camera Raw. Put an older version in place, re-visit those same folders and Bridge re-caches them again. Put the new version back, re-visit folders again, and re-caching happens.
Return to the original questions. Why is Bridge using Camera Raw to make the caching decision? Seems that decision would be based on file name, date modified, and maybe file size. All that info is available from the OS.
You can try few of these options
1. In preferences panel under cache->increase the cache size to max.
2. Check purge cache older than n days . Increase the n value.
3. Automatically Export Cache to a folder when possible.
Please let us know that cache or thumbnails are regenerating in central cache or in Exported cache folder. Also please mentioned how you are updating Camera Raw.
Thank you for your attention. Please be aware that this issue has existed for a long time. Below are links to other Adobe forum threads dating back to 2012. I realize that the issue is difficult for Adobe to address, since it appears to be system dependent, and thus hard to duplicate.
To answer your questions and suggestions:
I have run the cache size from the minimum 10,000 to the maximum 500,000 and various points in between. Cache size does not make a difference. And the number of images cached also appears to make no difference. I have the purge cache option disabled. I never purge. If I want an empty cache I delete the entire cache folders with Explorer. I have always Exported Cache to folders.
Sometimes thumbs are regenerated in the central cache, sometimes not. Likewise, the exported cache in folders (.BridgeCache and .BridgeCacheT) are usually regenerated by not always. That remains somewhat of a mystery.
I point a new Bridge /ACR at a root folder with many sub-folders. All of which were cached by a previous version. I then select "Show items from sub-folders". That will regenerate thousands of images and take a long time. When it's finished, I browse the folders with Explorer. Some of the .BridgeCache files are updated (new date) some are not. However, when I then point Bridge directly at one of the sub-folders with old .BridgeCache files, it then exports new versions.
Long ago I started copying the Camera Raw.8bi files to a private folder whenever a new version came out. I have copies going back to 7.1. To switch versions, I simply close Bridge, copy whatever version I want to test from my private folder to the Adobe folder, and re-launch Bridge. Currently, I can switch back and forth between versions 9.7 and 10.0 and witness some re-caching each time.
In these old threads others share various theories on what variables cause the issue. I think I'm the only one proposing that the version of Camera Raw is the key variable, but I don't think anyone else has tested that theory.
can you explain what that setting does (Prefer thumbnail generation over preview generation). I too have never seen it and a bit confused.
Yes, me too.
I want to know what this means:
"Prefer thumbnail generation over preview generation"
Is the thumbnail image embedded in the image while the preview generation in the external cache?
We have released a new version of Adobe Bridge (CC 2019) on 15 October 2018. The new version build number is 188.8.131.52. This version is available to install via Adobe Creative Cloud application.
Please check the following link to know about all new features in Adobe Bridge CC 2019 - https://helpx.adobe.com/bridge/using/whats-new.html
You may need to update the Creative Cloud application and restart your computer to see the updated installer.
I installed Photoshop and Bridge 2019 on a Surface Pro4 running Windows 10 version 1803 last week. This is a new and different computer than the ones I have used in the past to test and document Bridge re-caching.
Again. Bridge 2019 re-caches all images for no apparent reason. The images have not changed. The thumbnail jpegs do not change after re-caching. Same as all previous versions dating back several years now.
A mystery within the mystery is that no one from Adobe has ever confirmed or denied this problem. Even a denial would be helpful. It only takes a few minutes to test, assuming you have access to old versions of Camera Raw.8bi and can swap them in and out.
Bridge requires cache to be generated when the version of Bridge is changed.
Once cache for all files is generated in Bridge CC 2019, the cache is not regenerated unless files are added or updated.
Please let me know the workflow in which Bridge is regenerating cache .
Hi redcrown on guard,
Please check the Bridge cache location in Preferences dialog. In general, each version of Bridge has a separate cache.
However, you can make Bridge point to common cache folder location to avoid re-caching.
From Bridge CC 2019 onwards, Bridge will be pointing to a version independent cache location.
AbhishekSeth, Deepak Gupta, Avinash Kumar Singh,
I appreciate your participation in the forum, but I have to say that you just don't get it yet.
For a long time now, there has been no change in the structure of the Bridge cache. The folders used to store the cache are the same, the thumb and preview images stored in those folders are the same, the "Store" database (SQlite) is the same.
AbhishekSeth said "Bridge requires cache to be generated when the version of Bridge is changed." Why is that? What triggers building the cache? Since there is no apparent change in the base logic and structure of caching, the only reason should be that the thumbs no longer match the image. But they do!
Installing Bridge 2019 lets Bridge 2018 survive. So you can run both, just not at the same time. However, both versions point at the same Camera Raw.8bi file. So, after installing 2019 your 2018 version has a new Camer Raw.
So try this "work flow":
1. Get yourself some old copies of Camera Raw.8bi. If you work at Adobe that should be easy. If not, just ask. I've got them going back to version 8.6.
2. Point both Bridge 2018 and 2019 at the came cache location.
3. Make sure the new Camera Raw v11.0 in the target location (88,752 KB).
Program Files/Common Files/Adobe/Plug-Ins/CC/File Formats
4. Launch Bridge 2019, point it at a "virgin" folder of images that has never been cached, watch it cache.
5. Stop Bridge 2019, re-launch, verify it does not re-cache.
6. Launch Bridge 2018. Point it at the same folder. See that it does not cache. Sounds good so far.
7. Now the fun part! Close Bridge. Delete the current Camera Raw.8bi file. Copy an old version of Camera Raw into the master location and rename it Camear Raw.8bi. Version 10.0 is 70,785 KB.
8. Launch Bridge 2019. Watch it re-cache images!!! Why? The only thing that changed was the version of Camera Raw.
So here I am, sitting on a 400gb library of 40,000 images in 400 folders. My Bridge cache is 23gb. I install a new version of CC and get a new version of Camera Raw. It makes my existing cache obsolete. Everything will be re-cached. Even though I have "Exported cache to Folders" and all my image folders have valid BridgeCache and BridgeCacheT files. Re-caching will take many hours.
I realize that I am one of the few surviving Bridge users who has not migrated to Lightroom. We are a shrinking group, and I fully expect Bridge to be dropped by Adobe in the future. But Guys, as an old programmer I firmly believe this "bug" has a simple cause and could be easily fixed if it just received attention from the appropriate techies at Adobe.
Changing the CameraRaw plug-in does mean that there may be additional capability available in updated plug-in which is relevant for regeneration of thumbnails, and this is the way plug-in support has been designed.
Your suggestion that changing the plug-in should not trigger to re-generate cache of thumbnails, will break the plug-in update happening independently outside of Bridge.
However, if you keep the plug-in version same, and keep the cache location same as in previous version of Bridge (as I suggested in my previous message), then Bridge will not re-cache the thumbnails again.
Let's try these simple questions:
1. Why does Bridge need to re-cache the thumbnails for an image?
I'd suggest the answer is because the thumbnail no longer matches the image. The image must have been edited with changes.
2. So, how does Bridge decide that the thumbnail no longer matches the image?
There are only a few variables to use for this decision. They "might" be the image size, the date and time, the bit depth, the color mode, or the color profile. But you would not need anything more than the date/time (last modified). Any changes to other variables will cause the date time to change.
So you have the image file name, including the full path, plus the date/time stamp. That's the only key you need. You get the file name from the operating system, look it up in the Bridge Cache "Store" database, and compare the date/time from the Store to the date/time from the OS. If they are the same, move on. If not, re-cache the thumbnail and update the Store entry.
But there is a problem somewhere in that logic. Either some other variables are being used, or the "If date-time-of-STORE = date-time-of-OS" test is giving false negatives.
So, for our Adobe friends here in the forum... How would you answer questions 1 & 2?
I'm back with an update. Since none of the Adobe team answered the 2 questions above, I have to assume they don't know.
But on closer inspection and testing I find that the caching in 2019 is different in 2 ways. That is probably enough to cause the re-caching.
First way: The jpegs cached in the "256" folder are different. They are larger in bytes, and strangely (very strangely) they are highly pixelated. This indicates that 2019 is using a different conversion or compression method. Why is a good question. Larger file sizes, lower quality!
Note that the "256" cache jpegs are probably not used for anything. They only get used if you size the thumbnail display in Bridge to that small size. I suspect most people make them bigger, in which case the "1024" cache jpegs are used to display thumbs in Bridge.
The jpegs in the "1024" folder are identical between 2019 and all prior versions. I use "Generate monitor sized previews" so the jpegs in the "1024" folder are not 1024, but 1920 to match my current monitor. Why they are unchanged while the 256 jpegs are changed is a mystery.
Second Way: Exporting cache to folders, which is an option NOT enabled by default. In 2018 and all prior editions, exporting cache to folders created two files called ".bridgecache" and "bridgecacheT". Yes, the filenames begin with a dot and have no extension in violation of Microsoft's recommendations.
In 2019 those files are not created and any old versions are ignored. Instead, 2019 creates a sub-folder called ".BridgeSharedCache" under the image folder. This folder contain more sub-folders in the same structure as the main cache (256, 1024, data, full). So, 2019 replaced two files with many, many folders containing many, many jpegs. And the old ".BridgeCache(T)" files are left untouched and unused. In many cases, this means several gigabytes of space is left behind.
In 2018 and before, exporting cache to folders was a good thing. When Bridge navigated to an image folder that was not included in the main cache, it would copy data from the folder cache to the main cache. That was considerably faster than re-caching every image. It took a lot of extra disk space, but protected you when the main cache overflowed or became corrupted.
In 2019, the folder cache appears to NOT be used! If I delete the main cache, launch Bridge and navigate to a folder that includes a previously exported cache, the time to "generate thumbnails and previews" is the same as if the exported cache did not exist. No time is saved, as was the case in 2018. This can't be right. Why export cache if it's never used?
Discovering these aspects of 2019 was a challenge, because 2019 creates the exported cache files as "Hidden". You can't see them unless you config your Windows Explorer to show hidden files (not the default).
We will have to wait until the next version release to see if the "new" caching of 2019 saves us from re-caching. In the meantime, some advice to users: Don't bother to export cache to folders. Delete all your old ".BridgeCache(T)" files. They serve no purpose after 2019. In my case that was 30+ gigabytes.
Also, note that the "Generate Monitor Sized Previews" option does not survive the retention of preferences when 2019 is installed. It gets reset to the default "no", so all the "1024" jpges are actually 1024. When you display a full screen preview in Bridge (spacebar) you get a fuzzy image because it upscales the 1024 jpeg to whatever your screen size is. This cost me a few hours because that caching option does not appear under cache management where is belongs, and I forgot about it. It appears under "Advanced."
Well, it's bad news folks. It's May, 2019, and Adobe released ACR 11.3. Guess what? Re-caching of all thumbnails again!
Woe is us.
If your image files are tiffs, make sure the file extension is .tif and not .tiff. The only files that get recached (for me at least) have a .tiff extension.
Or you can go to Edit > Camera Raw Preferences > File Handling and tick "Disable tiff support" and "Disable jpeg support." There will be one final (and much faster) round of recaching, and then Bridge should leave your thumbnails alone as far as Camera Raw is concerned. When tiff / jpg support is Enabled, the default Camera Raw ("Auto") settings are applied to every file in a folder to generate prettier-than-average thumbnails. When tiff support is disabled, you get the unadjusted thumbnails without all the recaching.
This has always seemed to be the case since I've been using Bridge (a long time.) In the bottom status bar it always says (Generating thumbnails...) regardless of what I am viewing. It can be a folder with a single image in it. I would not expect this to change.
Hi redcrown on guard,
Thank you for your feedback regarding re-caching of thumbnails on ACR update. We will continue to incorporate the feedback to enhance the experience.