Well, I think you meant 2GB RAM and not 20 in the last sentence? 20GB would be fine.

In any case, I completely agree with what you said. If you don't have a 64-bit OS with an i5 or i7 processor and at least 16GB RAM, you are going to have some trouble for editing 16-bit color.

No, no with 2GB would be totally hopeless and even 8 are not sufficient ( i know because i have 8 and i even if i may do some 16 bit editing, do it is a pain for me and a sort of stress test for my PC)

Obviously 20GB are fine for now, a bit more than fine since as you said even only 16GB would be sufficient... but i was talking of a close future :
20GB are good for..let say edit photos from last Canon Rebel, but may become too few for the next Canon Rebel (or how would be called its future replacement) that obviously will offer much higher resolution

So are you saying gimp 16bit editing will be more memory hungry than say something like Rawtherapee ?
I went from a core due 2.13ghz , 2gig of memory (XP ) to a i5-3570, 8gig on win7 65bit and have no problems now with raw from Canon XSI raw's . I was able to do most all even with the XP system but was slow and had to make sure nothing else running .

I guess it will depend on what your doing , working with 24 MP raw and then have multiple layers and you probably need 16 gig .

yes more memory hungry mainly for the layers

Yes, I can see that but also most times you don't need full res raw size . You could convert to the size you need and then layers won't add up as much. That is of course if you don't need full size res .

Is this new 2.9 gimp still processing the image using tiling methods (breaking up the image into many tiles and processing and combining) . This is suppose to save on memory, at least for each image processing .

The amount of RAM and # of CPU processors are relevant only to a certain point.
First problem - it depends on what you do with the raw file. Most of the 3rd party plugins are still not ported to access GEGL buffers and work with GIMP tiles, which have been around since GIMP 1.2. Tiling is very slow by its nature.
2.10 will be all about GEGL but, here we run into the second problem:
16-bit or 24-bit per channel color depth processing will be slowed down not by your computer's hardware but by processing with GEGL>OpenCL based rendering. Hardware acceleration with OpenCL is not exactly the fastest compared to some of its alternatives, computation time on NVIDIA graphic cards are too high, not much better on AMDs.
And finally, GIMP multi-threading capabilities are limited. For a number of key procedures GIMP uses just 1 thread. I've noticed that, although GIMP detects all 8 processors of my i7, it hardly utilizes more than 2 and that's where 8GB RAM is usually enough. I have 16GB but it does not perceptibly speed up image processing in GIMP, although it allows PC multitasking. Running GIMP, Blender, Skype and VCL player at the same time - no problem.

My PC currently has a quad-core CPU and 16GB RAM. It would probably be alright for the type of work I do.

Well, the amount of RAM is always relevant.

GEGL is under heavy development and I am only optimizing code to a certain extent. For example I build with "-O2 -ffast-math -ftree-vectorize". This results in pretty optimized code and but does not go all the way.

So, things will speed up.

Finally this is an experimental release so that all Windows users can play with it. Why should Linux users have all the fun?

Please let me know what difficulties you face with this build. If you find a bug, please don't hesitate to report it.

Thanks.

Yes, it should be fine.

I assume you can set the color depth per image and layer (if I remember meet the gimp vids on 16bit ).

So could you say working with layers save the one 16bit layer that you want to work on S curves on and then the other layers like masks , blurs , blend have them 8bit ?
to save memory an speed things up or you can't mix bit depth ?

IIRC the issue of not having enough RAM or addressing limitations of RAM, the bulk of the problem is the amount of disc swapping that is required, which is very slow. Wouldn't adding a SSD drive drastically reduce the problem? If I am wrong, please explain why.

while the app should be able to use virtual ram (HDD ) many are unstable and crash once swapfiles starts to get used heavy .

Do you have an idea of which SSD's would work in this situation? Would it be brand related? Has any testing been done that would show which drives are stable enough, and where can I find these results?

I was talking with HDD's , I don't know if SSD change this, I "think" it is a windows and how the program is programed , but i could be wrong .

AFAIK it always was bad running into swapfile .

[quote="Edkiefer"][/quote]

SSD stands for Solid State Device. It is high speed flash mem that looks like a disc drive. No seek or latency, just like RAM. Sort of RAM on a Disc, so it is very fast.

bilbo9955,
SSD's have limited read/write cycles.
AFAIK they have a much shorter lifetime than magnetic media.
Swapping will cause lots of write cycles thus reducing lifetime.
Gerard.

gerard82,
Thank you for the info.

You're welcome.
I've come by this knowledge by wanting to install Gentoo Linux on an EEEPC.
This netbook computer only had SSD,no regular harddisk.
I was told not to make a swap partition and why.
Gerard.

One user on Flickr is using an SSD + 4G RAM. He did say it was slow and was looking to speed things up. Perhaps if you are testing the use of SSD as a drive for Gimp, you can let us/me know if it works well?

Thanks!
Partha

I am the flickr poster with the SSD and 4GB ram on Win7x64.. I actually have my swap/temp on an HDD partition though, as this is supposed to extend SSD lifespan.. I don't notice slowness anywhere else, and even processing 3meg jpegs is slow for me in this 2.9 so far.. I tried moving gimp temp/swap to SSD and HDD and no difference.. Everything is still fine with partha 2.8.2..