Lightroom memory use vs file size

On a forum that I frequent, a poster made the assertion that Lightroom memory usage was not so much a matter of the number of pixels in the image, but of the number of bytes in the file. That didn’t make any sense to me. I figured that Lr, like Photoshop, would decompress any file it was working on, so that the memory load would be a strong function of the number of pixels in the file. I also figured that Lr, unlike Ps, would convert all 8 bit-per-color-plane images into 16-bit or 32-bit ones, since it uses a linear version of ProPhoto RGB as its working space, and that would posterize with 8 bits per color plane.

I set up a test. I created a big image:

I filled the image with a highly-compressible simultaneous contrast optical illusion:

I wrote it out as uncompressed TIFF, LZW-compressed TIFF, and JPEG, both in 16-bit and 8-bit versions:

You can see that Ps writes 8-bit JPEGs even when it’s writing them from 16-bit images. We have a range of file sizes of about 300:1. Will Lr’s memory usage reflect anywhere near that range?

I imported all the images into Lr, picked the 16-bit uncompresssed TIFF file in the gallery, but left it in light table mode. I shut down Lr, waited for the OS to take back all the memory Lr was using, and started it again. Here’s how much memory it used after it settled down (when it first comes up, it grabs a lot of memory (6 or 8 GB on my machine), then rapidly gives it back to the OS:

Well under half a GB.

Then I picked the same 16-bit uncompressed TIFF file, and opened up the Develop module. Then I shut down Lr, waited for its memory footprint to go to zero (you have to do this to get consistent results), and started the program again. Here’s what I saw:

It looks like Lr stores a 16-bit file as a 16-bit image, at least before it does something to it.

I went back to the gallery, picked the LZW compressed 16-bit TIFF, shut down Lr, waited, and opened it again:

The same memory footprint as the uncompressed file, even though the uncompressed file is 64 times as large. That’s what I expected.

I turned my attention to the 8-bit uncompressed TIFF. It uses this much memory:

Wait a minute! The 8-bit file takes up more memory than the 16-bit one? Oh wait, Lr probably is keeping a copy of the 8 bit file around in addition to the 16-bit version that it created to work with.

What about an 8-bit compressed TIFF? Here you go:

It looks like Lr is uncompressing the 8-bit file and keeping a copy of it around after it converts it to 16-bit.

Here’s the situation with the JPEG file:

Hmm. Lr makes a 16-bit version, but doesn’t keep the 8-bit uncompressed file like it does with TIFF.

OK, what about a 32-bit floating-point TIFF? I went back to Ps and converted the base file to 32-bits per color plane, then wrote the image out as a 32-bit compressed file. It compressed quite nicely:

I imported the file into Lr, went to the Develop module, shut down Lr, waited, and opened it again. Here’s what I saw:

That’s too much memory for a 32-bit version of the image. So Lr probably stores a 32-bit floating point version of the image and another version. There’s almost, but not quite enough room for both a 32-bit and a 16-bit version. This needs more research.

So a 2GB file (uncompressed 16-bit TIFF) can take up less Lr memory than a 6 MB file (compressed 8-bit TIFF), and a 100 MB file (compressed 32-bit TIFF) can take up more than twice as much memory as a 2GB file  (uncompressed 16-bit TIFF again).