Sorry for my English - perhaps I will describe it clearly.
Some extra info - Processor Core2 Duo, Graphic c NVidia 8600GT, no program running in the background - so at least 2 GB is available. Saving 100 files from RAW to JPG - everything is OK (however RAM allocation for Bridge is huge - over 1 GB, but still plenty free). Consequent reviewing of created files works - but 100% file sizes are unavailable I've got the warning "Bridge is running low on memory - restart is recommended". Some commands do not work - e.g. RAW files are no more editable in ACR. Neglecting the need to restart the Bridge finally leads to Bridge crash and complete disappearing from the memory. This is probably all I can tell at this moment.
Anybody else with similar problem - or is this just mine PC?
I don't have CS4, but you might want to check the cache in Camera RAW preferences. Default in CS3 was one gig and you might need 5-10 gig for smoother operation.
Thanks for suggestion - I actually have set the cache to 10 Gigs, so the problem is somewhere else. What is quite strange that BR CS4 is increasing its memory allocation until... Never goes down, only up.
Not a computer geek, but batch processing 50 RAW images would be 500 megs to 1+ gigs of data to handle in short period of time. Could be the computer is just not up to it, especially if you have other programs running in the background.
Look at average size of files and see it the total is reasonable for your processor/system.
Thanks Curt for suggestion - PC here is Core2Duo 3,2GB with 4 GB RAM - I would say plenty of processing power. However Pentax camera RAWs are more then 20MB uncompressed each. Multiplied by 50 it really is 1GB+. But batch process should IMO open the file/allocate the memory/adjust the file/and save the file - then release the memory. Bridge CS4 is just eating more and more memory (though slowly) with no option to purge it after the process is over. This does not hurt until the error "low memory" occurs - especially when there is still plenty of memory available. BTW 50 Raws is not that much - typical batch to process may be several hundreds.
I have the same problem - XP pro SP3, Bridge CS4, 3GB of memory. Processing of 77 RAWs ("build cache" command) result in "low in memory warning". No ideas =(
The problem has been solved.
In my case Bridge was unable to write in cache folder due to permission limitation (the user, under which credentials the Bridge was running, had only read permission to that folder). As the result, Bridge was unable to save images on the disk, so it keeps them all in memory - that's why it consumed so much memory. Also that problem had many bad consequences.
I grant full access permission for user, so Bridge and other applications can write to the cache folder. Everything works fine.
P.S. Bridge CS4 is extremely MUCH BETTER in handling RAWs comparing to slowly Lightroom 2.x! I'm so happy))
That brings up a good point on the cache. If you have the cache on a disk partition with XX amount of space make sure you have significant free space. Some suggest you fill a disk to no more than 75% of capacity. If you are doing large batch processing you will need to make sure you have plenty of free space to accommodate the operations.
If you have the cache on the entire disk make sure you defrag frequently as it can really mess it up quickly with frequent write and erase operations. A fragmented disk will slow down all operations.
I have plenty of free space (600GB out of 1TB) on my RAID drive and full access to that space so in my case this is probably not the reason. However I tried to limit the thumbs generator to "prefer embedded" instead of "always high quality" - which was default with my installation. Not testing it exhaustively but so far so good - at least memory allocation does not go beyond 500MB.
In my case Bridge was unable to write in cache folder due to permission limitation (the user, under which credentials the Bridge was running, had only read permission to that folder). As the result, Bridge was unable to save images on the disk, so it keeps them all in memory
Does this refer to Bridge Preferences, Edit, Preferences, Cache menu "Automatically Export Cache to folders when possible" ?
I've just recently upgraded to CS4 and never had low memory errors, with 4GB of RAM.
Yesterday I did some extensive search in my photo library - and though no low memory error occurred - all other "low memory symptoms" remained. It typically happened after browsing through app. 1000 images and opening in ACR three - four times a batch with 10-20 shots in one session. In each session I did some common corrections (exposure/contrast etc) incl. some not so common - such as applying graduated filters + some local adjustments (curves/hues/masking). Each time (i.e. after a lot of browsing + 4x opening/correcting app. 20 JPGs (each 15 MPx in size] - I ended with the same result:
-Memory usage more than 1 GB,
-no Low memory error (as mentioned earlier)
-ACR stopped responding to more changes applied to the picture - but did not crash or freeze - just did not display any new changes
-Upon return to Bridge the thumbs were not updated (however were updated upon next restart of Bridge)
-Some images (not all) were unavailable for 100% preview.
-Preview mode (CTRL+B) started to react unpredictably not showing some images, dropping some picures instead of moving around etc.
So the result was not a "crashed/frozen" application just no more working as it should. Restart was necessary and obviously helped.
I think it is necessary to put a heavy load on Bridge to reveal this.
I'm having exactly the same problem. I have an Intel i7-920 processor with 8 GB memory running on 64-bit Vista. After 15 minutes or so I start getting "memory low" warnings and have to exit and restart Bridge. Symptons are as described by Vlad. The folder has ~600 raw files and I have preferences set to "always high quality."
I know that's a lot of memory, but as someone pointed out it should release the memory when it's not being used; instead usage just keeps going up. Also the folder cache is only 1.3 MB. I sometimes get the low memory warning when opening a single image in ACR. Any ideas would be appreciated.
If your cache folder is only 1.3MB I don't see how anything can work. I have my cache on a 40 gig partition (shared with photoshop) and it has 21 gigs filled, and I rarely open more than one RAW file at a time.
I have my preferences set "to automatically export cache to folders when possible," so the 1.3MB cache file is only for the one folder with ~600 raw files.
I am certainly not an expert, but I believe the data is stored in a central cache, even though it may export to folders if indicated. I do not know where the memory goes but even a small collection on photos seems like it takes up 6 gig of cache.
I think the Bridge cache is used as a temp dump for files opened, slide shows, edits, and ?. If you are low on memory as least something to think about. Perhaps with 8 gig of RAM those process are carried out there.
One other consideration: LR 2.2 has a well known memory leak associated with the adjustment brush use and with large, multiple file operations of differing kinds. If my memory serves me well, both ACR and LR use the same basic engine under the hood, with obvious differences. They do share the same basic adjustment brush, for instance. So, it is possible that Bridge CS4 also suffers the memory leak problem.
Th adjustment brush in LR2.1 was very slow and jerky--just plain buggy--so when they sped it up in LR2.2, they inadvertenly introduced a memory leak. LR did not have one in 2.1.
For me the adjustment brush is a very weak tool, so I don't use it. I do that sort of work in better applications, like PS for example. I also have no memory problems and I do batch significant numbers of NEF and CR2 files.
These problems are very hard to pinpoint--good luck.
The posts by Curt Young and Don Soloman are very timely. First, Curt is right about Bridge storing data in the central cache (...AppData/Local/Adobe/CameraRaw/Cache). My cache was 1.99 GB and preferences were set at the default value to limit the cache size to 2 GB, so it seemed like I had found the problem. I increased the cache size and I had no more memory warnings. At least not for quite a while. Thanks Curt!
A couple hours later I started to use the adjustment brush in ACR and the low memory warnings started again. I can only use the brush on 2 or 3 images before having to exit Bridge and restart. As near as I can tell this is the only time I'm getting the low memory warnings now. I have a 26" monitor and despite a very fast machine the brush is still somewhat slow and jerky on high quality previews. The adjustment brush is a great idea because now I don't have to use PS in my workflow. However, it looks like Adobe needs to do a little more work to make it right.
it's definitely and Adjustment Brush issue. My ACR and Bridge were just perfect until yesterday, when for the first time, I began using the adjustment brush.
Graduated filter make the same trouble - couple of pictures and LoMem issue is here
I'm also getting low memory errors when I try to batch process in ACR (eg convert .cr2 to .jpg). If I load 25 files I'll only get half of them done before it runs out of memory and stops. If I then load 25 more I'll only get 2 or 3 done before I get the low memory error. I have to exit and restart before doing any more.
It seems like these errors are very repeatable by many users. I hope Adobe is reading this.
They are undoubtedly well aware of the memory issues. Both Lightroom and ACR share the same basic engine and both have the memory problem--it has been widely reported and they have acknowledged the memory leak.
The problem is far more crippling on computers with smaller amounts of memory, of course. It makes using the adjustment brush, the grad tool, either LR or ACR, and other file intensive operations, like large exports from LR or batching from ACR, virtually impossible on my older P4 2.4 with two gigs of ram. It is not a problem for me on my Intel 9550 quad, with 8 gigs of ram. However, I seldom ever use the adjustment brush anyway, not because of the leak, but because it is a very primitive tool, comparatively speaking, for local corrections.
Ironically, this memory leak bug was introduced in their attempt to speed up the adjustment brush. Now it is faster and smoother--and works fine, that is if you use it very sparingly, or constantly reboot to get your memory back. I suspect a fix will be released soon--let's hope it doesn't come with another new bug to deal with.
I have just installed CS4 ( I am also running cs3) on windows Xp.
I have 4 ram and a nvidia geo force 9800gtx card. I have been having little quirky problems with cs4 ( cs3 continued to work perfectly )
Today a problem has appeared. I opened a raw image and edited it using the adjustment brush , the gradient and converted to black and white. It was after this that the problems occured. A shrt while after opening the file in photoshop cs4 I noticed that the efficiency rating had dropped to 35% ! I closed the file and reopened it in CS3 and the efficiency returned to 100%. I then noticed in Bridge that when I used the loupe on that image the loupe could not focus and a message appeared below the preview picture that"100% not available"
Interstingly the loupe had no problem with NEF images in the same folder. I then went to tools / cache and purged the cache for that folder ... The loupe worked but only for a short while before the same message appeared and the loupe would not focus ...Any thought as to how I can fix this? I would be very grateful fotr any help.
further to my post of yesterday where I referred to the problem with the loupe in bridge further problems have arisen. If whilst in filmstrip I use the space bar to enlarge the image and then tap the space bar to return the preview to the original size I am unable to view another image in the film strip by clicking on it .. the preview screen remains blank until I slightly adjust the bar which divides the film strip from the preview panel.
Since yesterdays post I have gone to bridges cache and found files called 256, 1024,data and full. I have manually deleted those files but the problem has not gone away.I have also gone to tools and purged the cache from the relevant folder.
The loupe problem does not occur with NEF (raw) images but only with
I am also getting the message that Bridge is running low on memory and needs to be re started.
I am not batch processing . I have about 150 images in the open folder and I am working on one image at a time.
I would appreciate any help
There may be more than one problem working at the same time.
Regarding the filmstrip mode problem, that usually is a video card thing. Make sure you have the latest drivers. Clicking on "use software rendering" in advanced preferences can also help.
Thank you Curt,
Using "software rendering" seems to have fixed the problem with the film strip and preview window problem. The problem with the non focusing loupe on TIFF images remains as does the bridge memory problem.
I am tempted to revert to CS3.. never had a problem with that.
Thank you for your help
The Raw image problem is an ACR 5 and 5.2) memory leak problem. Your other problem is, as suggested, a video card problem. Going back to CS3, which does not use Open GL, will take care of the video card problem, but you should be sure to upgrade to the latest nvidia drivers, if you have not already done so, Realize, as well, that your 4 gigs of ram will not be fully utilized on an XP 32bit system.
Also, going back to Bridge 2.1 will get you around the memory leak until it is fixed by Adobe--the word is that will happen soon for ACR 5.2.
Than you Curt and Don for your help.
I am now opening Bridge CS4 and collating the images for editing.I then open the NEF images with PS cs3 running in the background. This opens camera raw 4.6 (which thankfully does not contain the adjustment brush nor the gradient) as it would appear that those 2 beasties caused my problem in the first place. I then proceed with any further editing in CS3....I will follow this forum to see whether Adobe gets around to fixing the problems in ACR5.2 Thanks once again.
Ron: Surely just not using the adjustment tool or the gradient tool in ACR 5.2 will avoid the memory leak problem? also, have you noticed that ACR 5.3RC has been published? you might want to try that.
Hmm after installing ACR 5.3 seems to be something good happened. Not testing it much exhaustively but the adjustment brush is less "jerky". I applied 6 graduated filters on a PEF file, 4 adjustment brushes to differnet areas - memory allocation for Bridge increased to 1 GB but after pressing "Done" button the memory was immediatelly released to 240MB - so far so good.
Still something not OK. It seems to me as if there are two different beasts in one skin. There are still some RAW files which - when previewed via Slide Show are still unavailable at 100% view (they were adjusted with ACR 5.2). Bridge displays them with low resolution - it just shows "loading" for ever and finally displays "100% unavailable". Switching directly to ACR with "R" key displays the file with no problems. No matter if you purge the cache, or switch to software rendering. Only thing that helped was to rebuild the associated XMP file (either delete or open the file in ACR change a bit of something and resave). It seems to me that ACR 5.2 - with its unpredictable behaviour under heavy load - corrupted some XMPs which finally resulted into situation that Bridge cannot display them correctly (however ACR has no problem with them).
Is it possible that Bridge and ACR use separate rendering engines for displaying files? Or they interpretate the XMPs with different algorithms?
You most definitely have a problem. I have absolutely no problem with a show containingt 123 images, ranging from Nikon D300 12 meg raw to 40 meg tif, with some Canon images thrown in.
Where do you have the cache? Central or in directories?
What size previews have you set for cache in preferences?
What duration for each slide and how fast or slow on transitions?
Specs CoreDuo 3GHz, 4GB RAM, NVIDIA 8600, 3x 500 GB HDD (70% free), cache distributed when possible, previews size - keep 100% in cache, cahce size somewhere in the middle between 10000 and 500000, tried already :preferred embedded, high quality on demand, always high quality (with purging the cache in between) - slideshow was not actually slideshow but full screen preview via "spacebar".
But Don do not miss the keypoint - those were some XMPs which caused the problem. And these XMP files were used by ACR flawlessly whilst Bridge cannot use them - this is strange.
I'm running Bridge on Windows 7RC and I was experencing same "Bridge low on memory" problems.
Since some folks mentioned Permissions for Users to write to disk I recaled, that my problems started since I moved Cache to another disk.
I've checked out Permissions (disk>Properties>Security) and what I found was that on "Everyone" permission to Write was checked out, But on "Users" wasn't.
So I turned it on and my problems was solved . Since I belive Windows 7 is based on Vista, the solution should be OK for both.
For over 6 months now I have been using CS4 Design Premium quite happily on a 64 Bit Machine with XP64, 8Gb RAM and 3 x 500GB hard drives one of which is reserved for cache purposes only.
In particular I have been using Photoshop and Bridge (the latter is a tremendous package btw) to work on large panoramas compiled using Autopano Giga 2.
However, in the last few days, out of nowhere, I have suddenly been getting the "Memory Low restart Bridge" message. It's as though I've run into the buffers somehow.
I have read the Adobe forums on the matter, tried the various suggestions without success.
For Bridge, the cache size is set to the max. 500,000 items. while in practice it currently contains 11,376 files and 736 folders. I've also set up an additional bridge_overflow folder on the same cache drive the latter being 3% full with 453 Gb free. Finally I did a full CS4 upgrade but still the problem persists.
One interesting thing which may be a clue is that looking at the Properties of the Bridge cache folder it gives two parameters viz Size 2.56 GB and Size on Disk 2.54 Gb which is indicative of a memory limit being approached but I don't see how the former can be increased. Purging the cache folder hasn't made any difference to these values. And finally, I don't know if it is a related problem, but the Loupe quite often states that 100% is unavailable.
Any help / advice would be appreciated.
We also use Shop and Bridge CS4 on two 64x bit machines, like previous mails on this thread we never experienced the problem of the cache on bridge when we were osing CS3 on the same machines. Overall we do prefer CS4, but this bug is very frustrating, neccessitating as it does a complete shut down and restart - with sometimes a complete freeze needing a hard reset. Can you explain a little more re your point about users in XP so that we can try that. Obviously if anyone else is resding this and has any helpful advice, that would be very helpful.
As I see it, the problem is somewhere in understanding of users rights
on disk where cache is located.
In my case the problem was because I didn't have enough rights on drive
where Cache was (wich is stupid since I'm the only user of my comp), so
Bridge couldn't write it's date on target disk).
I don't know for yours , but john-o-eid's problem could be conected with
the same issue. It could happen also in situations when there are
more users and not everyone's rights were assured in phase of CS4
installation, since cache is located by default in folder of user that
installs it. In my case it was
C:\users\daregre\AppData\Roaming\Adobe\Bridge CS4\Cache (in XP instead
of C:\users..., C:\Documents and Settings...).
So either every user must set Cache for himself in his
C:\users\....\Cache directory, or ensure that everyone that uses
computer has WRITING rights on drive where Cache is. So:
1. check out if you've changed settings for cache location, (or someone
2. check everyone's rights on that drive (Control Panel>User Accounts,
perhaps also in disk sharing advanced options).
3. remove every possible restriction of rights for that drive on your
and other common user accounts (guest, everyone ...).
Hi Daregre and Malcolm 127
Many thanks for taking the time to reply to my problem.
I have removed all security restrictions on the Bridge cache folder and although it's early days yet, in the short space of time I've used Bridge since, I have not received the error message (fingers crossed).
I must confess I do not understand the logic of this because, as I said in my original posting, I had been using Bridge quite happily for six months, never changed anything and this problem suddenly came out of the blue.
I must also add that with the volume of correspondence there has been on this issue, I am disappointed that Adobe seem to have been silent on the matter.
The reason could be also some authomatic Microsoft's security update
that we're not aware of. Hope it worked for Malcolm 127 too.
... so comunity wins again!
In my testing today, the problem is still there.
I checked my permissions and disk space for my caches, and that is not the problem.
Here are some clues to the folks at Adobe to where this problem might be:
Open Bridge CS4, go to a folder of 35 Canon 5D2 CR2 files, and purge the cache for the folder. Select the first thumbnail, hit the spacebar, then the plus key, and right-arrow thru the files (at 100%). After a few images, it starts to take longer for the 100% view to fully resolve. On the 9th image, it never resolves and eventually gives the 100% unavailable message. Escape out of the 100% preview and then go back to the first image to show 100% unavailable. It still shows "100% unavailable". Close Bridge, reopen, open the previously 100% unavailable image and it displays fine. So the 100% unavailable error was stored in RAM cache. If you leave Bridge open but purge the folder cache, it also resolves the 100% unavailable problem.
If you open a folder and very rapidly right-arrow thru the files at 100% preview, after about 7-10 files Bridge goes berserk, starts flickering, gives the low memory error, and dies.
Since Adobe pays people (and I'm not one of them) to fix these things, I'll sign off here.
Hopefully this will help.