I would think this message can relate to scratch disk as well as actual RAM.
What are your scratch disk settings (in Edit > Preferences)? What’s the scratch size when you get the message? (See those numbers bottom left on your image window – click on the arrow and set them to show "scratch size")
The point of this being that CS3 has a much more aggressive scratch disk policy than CS2.
My scratch disk size is 1.19 GB.
So how do I adjust it.
The disks that I have checked as my preferences for my scratch disks each have 200GB of free space.
The disks that I am using as scratch disks have 214 and 405 GB of available space.
The reading in the lower left of the image window that I just opened is 123.7M/1/19G.
that should read 123.7M/1.19G
I take it that means you have a scratch disk separate from your system disk, and the numbers indicate you should be well in the clear. You also seem to have PS RAM allocation in the neighborhood of the recommended 55%.
Hmmm. Couple of more things: ACR addresses memory in contiguous chunks above and beyond what PS itself uses, so fragmentation might be an issue. Is there anything else on your primary scratch drive? Which one is it, by the way? If C, you should move it.
My primary scratch drive is currently C.
I will move it to one of the other 7 drives that I have connected to this system.
Do that. Ideally, you shouldn’t have anything else on it.
I think that I may have solved the problem. I went into the system preferences in Windows XP control panel and increased the "paging" allocations.
But you should on no account have your primary scratch on the same physical drive as the Windows paging file.
(Unless you only had one drive like a laptop.)
Whatever works…
But I have more faith in optimising your scratch disk configuration. Just out of curiosity, what was your pagefile size and what did you change it to?
Note that JJ says "the same physical drive". That’s important – some people think it will help to put them on different partitions. It won’t.
Paging was – Minimum = 2gig Maximum = 4gig
I changed it to – Minimum = 4 gig+ Maximum 9 gig.
I also set my scratch drive to a drive other than C.
i’d set paging to 2x installed RAM min and max and leave it at that.
ditto same physical drive info. if you can help it, windows swap and ps scratch should be on seperate drives.
as for the EMPTY drive, i don’t think so. all you need is a large contiguous block of free space. i have a drive with over 100gig free, that i keep defragged so the free space is in one big block, i use that as my ps scratch drive. the problems happen when you start fragmenting your scratch file, so that the disk heads have to jump around the drive to read and write – and i think that’s what FA’s advice is trying to tell you to avoid at all costs.
I have now set paging to 2X installed RAM – min and max.
My paging is on drive C.
My scratch drive is on an external drive which has a contiguous block of free space.
May the scratch drive be on the same physical drive as the RAW files that I am converting?
I think the scratch drive should NOT be on an external (usb?). everyone agree on that? that’s probably way too slow.
May the scratch drive be on the same physical drive as the RAW files that I am converting?
I would think so, as long as there’s enough contiguous free space so that fragmentation doesn’t occur.
I can connect an external drive via eSATA. That should be equivalent to an internal drive.
I can connect an external drive via eSATA. That should be equivalent to an internal drive.
My only internal drive is the C drive.
I seem now to be able to convert more than 100 images in one "save images" action.
What I find is that I must close out Photoshop and restart it if I intend to convert another batch. If I do not close it, I will get the "Not Enough Memory" message, starting with the first image in the batch.
Is that typical?
OK, you’ve moved the problem upstairs a bit – from 25 to 100 images. We might be on to something, but I still think you shouldn’t get that message at all if the scratch disk is operating efficiently.
BTW closing PS to clear it is normal. PS holds on to its memory as long as it’s open.
Let’s just sum it up:
* Ps scratch and Windows pagefile on different drives. Partitions don’t count.
* The scratch file needs to be contiguous. Free, unfragmented space on that drive.
* USB is too slow. eSata is fine (same as internal), Firewire should also work.
* You can have scratch and your raw files on the same drive, but then it should be two partitions: scratch on first (outer and faster); data on second. But it would affect open/save speeds. Could that be it?
What have I forgotten?
Oh yes: you could try to increase PS RAM allocation to 70%, but I would not go beyond that. That would lead to increased windows paging.
Just occured to me:
Even though Adobe employees no longer post in this forum – no doubt scared off by hostile attacks from grumpy and ignorant users – some of them like Thomas Knoll, Jeff Schewe and Eric Chan turn up in the ACR forum on a regular basis. I’m sure any of these gentlemen would be able to point you in the right direction, and this is, after all, at least ACR related.
So it might be worth a shot to try over there. (Carefully, though, we don’t want to lose them from the ACR forum as well…)
Actually, I was able to convert 180 images in one session. I opened 200 RAW images, clicked on "select all" and then clicked on "save images". It converted 180 before giving me the "memory full" error.
Thank you so much for your help.
I will also visit the ACR forum.
Good. Seems like you’re on the right track. 🙂
no doubt scared off by hostile attacks from grumpy and ignorant users
….no doubt scared off by hostile attacks from grumpy and ignorant users suits at adobe…
there. fixed that for ya. 😉
Thanks dave. Knew I could rely on you to clean up my little typo…
it’s a great example of what i call "suit-think". i believe the damage done by NOT allowing adobe personnel from taking part in these forums is many times greater than the damage that could done by any misspoken, informal statement – which could easily retracted – could ever be.
Adobe personnel or no Adobe personnel, the help that I have gotten on this forum has significantly reduced if not eliminated my problem.
Here I am, a total stranger, and each of you has been kind enough to provide me with very valuable input.
I cannot thank you enough.
You’re welcome, Michael. We’re all learning new things here every day, and answering questions can be every bit as educational as asking them.
Have to say I agree with you dave, but it seems to work well over at ACR, and then there’s John Nack. Just can’t bring myself to believe they would be that stupid. But I’m not wearing a suit awfully often, so I wouldn’t know.
You’re welcome, Michael. We’re all learning new things here every day, and answering questions can be every bit as educational as asking them.
exactly! what FA said!
Just can’t bring myself to believe they would be that stupid.
you should have seen what it was like a few years ago when we had about 4 adobe engineers regularly popping in and offering help and advice.
and then there’s John Nack.
he’s the new mouthpiece. seems that when he started, everyone else stopped. that’s sad, and a great loss.
If you are selecting multiple RAW files in Photoshop’s file open dialog, the problem is that Photoshop needs scratch space for all of those files simultaneously, which could well be exhausting your available space. It would be better to select the files in Bridge and either (a) run an action that opens a file, does any needed processing, saves as whatever type you need, and closes; or (b) use the Image Processor to save as whatever type you need, without size constraints. This will only open one image file at a time and thus can reuse the same scratch file space for each image.
Good point Michael. How about letting Bridge host ACR, without involving Photoshop at all? Would that do any good?
Yes. It’s worth a try.
Select the files in Bridge and open with ACR.
Still…there is this nagging little piece of information from the OP:
When I used CS2, I would be able to convert 100 or so RAW images with no problems
….as opposed to 25 with CS3, and that’s I suppose with the same scratch configuration.
It reminds me a bit of a another thread about 6 months ago, concerning placing smart objects into a blank file. The gist of it was that CS2 would perform flawlessly, while CS3 would stall or freeze, apparently from scratch overload. Can’t recall if that was ever resolved.
Candidly, I do not remember what my scratch settings were in CS2.
That’s OK.
I was just thinking out loud, that maybe the new and aggressive scratch disk management of CS3 – highly effective for the most part – might have a downside that would pop up in certain situations.
Back then I think the general consensus eventually became "bug". Whatever it was, I’m sure they’ll fix it in CS4.
