A 180 Mpixel file would use somewhere between 1 and 1.3 GB of RAM to store a single copy of the image, depending on the presence of alpha data.
Sandy, it looks like you're assuming 16-bit unsigned integer representation. Since Lr works in linear PPRGB, that precision would be insufficient to avoid posterization. My guess is that Lr works in either single or double precision floating point. But the wild card is when does it actually work with the full-res image? For most of the editing operations, it could work with a smaller copy, a la Live Picture. It would only need to work at the native resolution when zoomed it to 100% or more, or when exporting, printing, etc. And, when it's doing those operations, it doesn't need to operate on the whole image at once.
Eric Chang, can you help out here?
In the absence of a contribution from Eric, how can we find out? I've done a few tests, and it looks like Lr uses various amounts of memory depending on what it's doing.
With a big image:
Just browsing in the gallery doesn't use much memory:
But zooming in to 1:1 makes the memory go up a lot:
As does going into the develop module, even zoomed out:
Another thing: I had to restart Lr in between these tests, because it seems that once it's grabbed some memory, it doesn't want to let it go, even if it's doing something that doesn't require a lot of memory.
But when you export the big file as a full-res 16-bit TIFF, memory usage actually goes way down, indicating that Lr is processing the image in slices:
From the counts, it looks like
Lr is using at least 32 bits per pixel, and is not subsampling or cropping the image in memory when you're in the develop module. [Edit 9/6 @ 9am PDT: I've improved my testing methodology, and I now believe that Lr stores 16-bit versions of 16-bit and 8-bit files, and 32-bit versions and something else of 32-bit files. Details here:
http://blog.kasson.com/?p=7055 ]
Jim