Lightroom vs RAM: How many MB per MP?

[dreed]

Earlier I created a stiched panorama, around 180MP in size and wrote it out in TIFF format using PTGui.

When I tried to work on it with LR (small laptop, 4GB RAM), it sat around for over 15 minutes doing what I don't know.

For regular raw files, it doesn't seem to have a problem...

This has me wondering, is there a relationship between how many MB of RAM Lightroom needs to work with an image of MP (or MB?) in size? And does it differ between raw, TIFF, JPEG?

I suppose where I'm going with this is what are the limits of LR on a 4GB laptop?

[PhotoEcosse]

The Mp size of the image is fairly irrelevant but the Mb size of the file is not.

Basically, LR should process any *reasonable* size of image file but, obviously, the larger it is in relation to the resources and specification of the computer, the slower the process might be.

[sandymc]

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. However, (a) to actually do anything, LR will need more space to actually work in, and (b) LR likes to cache copies of intermediate results. I don't know how exactly LR handles caching, intermediate results, etc, but I can tell that for  a product I do know, AccuRaw, for that file size 8GB would be a minimum for any reasonable performance, and 16G preferable.

Sandy

[hjulenissen]

The Mp size of the image is fairly irrelevant but the Mb size of the file is not.

Basically, LR should process any *reasonable* size of image file but, obviously, the larger it is in relation to the resources and specification of the computer, the slower the process might be.

How do you know this to be true?

If Lightroom represents images "as early as possible" in a common format, then most heavy operations would be loops over a number of pixels, i.e. primarily dependent on pixel count. Operations that scale lineary with file size (such as entropy coding in JPEG or similar stuff in raw files) may have a cost, but I doubt that this dominates the Lightroom load?

Assuming that Lightroom does not scale down that intermediate format (which it might well do for previews and such, but probably not for rendering full-quality output).

-h

[PeterAit]

Open Task Manager (or the Mac equivalent) and keep and eye on memory usage. If it maxes out, or even close, there's the problem. Then the OS will buffer to disk what "should" be kept in RAM and that is a much slower process.

[ChuckT]

Don't forget you are working with a bit mapped file. One where each and every pixel is a binary string (a number) and computers, being dumb,  count on their fingers.  Make the file large enough and panos being longer than high will take a while to render. Its your OS and app operating on each pixel in turn to make the raster image resemble the "look" you commanded.

[Jim Kasson]

Don't forget you are working with a bit mapped file. One where each and every pixel is a binary string (a number) and computers, being dumb,  count on their fingers.  Make the file large enough and panos being longer than high will take a while to render. Its your OS and app operating on each pixel in turn to make the raster image resemble the "look" you commanded.

I am reminded of a joke that IBMers used to tell on themselves.

A small, 14-seat plane is circling for a landing in Atlanta. It's
totally fogged in, zero visibility, and suddenly there's a small
electrical fire in the cockpit which disables all of the instruments
and the radio. The pilot continues circling, totally lost, when
suddenly he finds himself flying next to a tall office building.

He rolls down the window (this particular airplane happens to have
roll-down windows) and yells to a person inside the building, "Where
are we?"

The person responds "In an airplane!"

The pilot then banks sharply to the right, circles twice, and makes a
perfect landing at Atlanta International.

As the passengers emerge, shaken but unhurt, one of them says to the
pilot, "I'm certainly glad you were able to land safely, but I don't
understand how the response you got was any use."

"Simple," responded the pilot. "I got an answer that was completely
accurate and totally irrelevant to my problem, so I knew it had to be
the IBM building."

[deejjjaaaa]

AccuRaw, for that file size 8GB would be a minimum for any reasonable performance, and 16G preferable.

ouch... I run RPP in OSX/VmWare on a PC/Win7x64 noteboook, with 2Gb "RAM" set for a virtual machine ...  and it does work OK with 36mp D8** raw files  

PS: I did not notice "that file size" part... then for 180mp it sounds right.

[sandymc]

ouch... I run RPP in OSX/VmWare on a PC/Win7x64 noteboook, with 2Gb "RAM" set for a virtual machine ...  and it does work OK with 36mp D8** raw files  

PS: I did not notice "that file size" part... then for 180mp it sounds right.

Yes, AccuRaw would "like" +- 1.2G for a D810 file, but that's all intermediate products cached, etc, so full out maximum performance. It will work in maybe 1/3 of that with some reduction in performance, so even on old(ish) laptops. Most modern apps will cooperate with the OS to cache more/less depending on available RAM to optimize performance.

Sandy

[Jim Kasson]

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

[sandymc]

Sandy, it looks like you're assuming 16-bit unsigned integer representation.

Photoshop and LR (mostly) use signed 16-bit, aka 15 bits plus sign bit. But it's common practice to keep copies of results at intermediate points of the processing pipeline; that saves on having to redo computationally expensive operations every time a change occurs. But when the user stops editing, you can release the intermediate results to make room for the render to final image - probably you won't need the intermediate results anymore

Sandy

[PhotoEcosse]

How do you know this to be true?

Because, in terms of data processing, a "pixel" is not a unit of data. It can be referenced by data in different ways in different software on different machines for different purposes.

[Jim Kasson]

The Mp size of the image is fairly irrelevant but the Mb size of the file is not.

My testing shows that 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), with all files containing the same number of pixels,

Details here:

http://blog.kasson.com/?p=7055

Jim

[deejjjaaaa]

Since Lr works in linear PPRGB

ACR/LR use a lot of different color spaces in their internal raw workflow and you might assume that there is a moment when the same image data is presented in RAM in 2+ spaces at once... from RAW RGB (non-color-space) to cieXYZ to PPRGB/g1 to HSV and back (to PPRGB/g1 - to apply LUTs in dcp profiles) or to LAB (masks calculating), etc.

[Jim Kasson]

ACR/LR use a lot of different color spaces in their internal raw workflow and you might assume that there is a moment when the same image data is presented in RAM in 2+ spaces at once... from RAW RGB (non-color-space) to cieXYZ to PPRGB/g1 to HSV and back (to PPRGB/g1 - to apply LUTs in dcp profiles) or to LAB (masks calculating), etc.

That's not what Eric Chan told me. Do you have a reference?

Jim

[deejjjaaaa]

That's not what Eric Chan told me. Do you have a reference?

http://www.adobe.com/content/dam/Adobe/en/products/photoshop/pdfs/dng_spec_1.4.0.0.pdf = that covers raw RGB to cieXYZ to ppRGB/g1 and round trip to/from HSV

http://lists.apple.com/archives/colorsync-users/2011/May/msg00187.html = that covers trip from ppRGB/g1 to LAB

naturally there might be some other exotic voyages from ppRGB/g1 elsewhere for whatever reasons

[Hans Kruse]

Because, in terms of data processing, a "pixel" is not a unit of data. It can be referenced by data in different ways in different software on different machines for different purposes.

Could you explain what you mean by this as in my view this explanation or rationale is pretty meaningless.

[Jim Kasson]

http://www.adobe.com/content/dam/Adobe/en/products/photoshop/pdfs/dng_spec_1.4.0.0.pdf = that covers raw RGB to cieXYZ to ppRGB/g1 and round trip to/from HSV

http://lists.apple.com/archives/colorsync-users/2011/May/msg00187.html = that covers trip from ppRGB/g1 to LAB

naturally there might be some other exotic voyages from ppRGB/g1 elsewhere for whatever reasons

Thank you for the references. I had not seen Eric's comment about color difference calcs, and I hadn't looked at the DNG spec since a much earlier version.

However, as evidence of conversion of the full-res image to other color spaces than PPRGB/gamma=1 these references are not dispositive. In the context of Lr's memory footprint, keeping copies of the full-res image around in more than one representation is what's going to eat up the space.

Let's take the footnote in Eric's comment first: "ACR does use L*a*b* for some internal color difference estimates, e.g., for auto-calculated masks." It's not clear to me that you need to convert the entire image to Lab to generate masks. I will admit that I con't figure out what masks Eric is talking about, and it is entirely possible that you do need a full-res Lab version of the image to do these color difference (probably DeltaE) calculations.

With respect to the DNG spec, the existence of color spaces that are used to build 3D color Look-up tables is not evidence that the image needs to be converted to each of those spaces. Let's say that I need to go from Space A to Space B, and what I know is how to get from Space A to Lab, and from Lab to Space B. I could convert the image from Space A to Lab and thence to Space B, or I could populate a 3D LUT with values calculated from my knowledge of Space A > Lab and Lab>Space b, and pass the image through the LUT, going directly to Space B.  If the curvature between Space A and Space B is less than the curvature to and from Lab, this actually yields more accurate results for a given size LUT.  But there again, Lr could take a full-res image on a journey through many color spaces if it discarded the imtermidaite ones quickly, and I'd never see it, so you could be right.

In my testing, I've noticed that Lr's memory footprint drops dramatically when exporting a single large image, which indicates that it's not processing the whole image at once.

When you put the above together with Lr's habit of holding onto memory after it's done with it, which makes running tests difficult, I think the only sure way to find out if and when Lr converts the entire working image to spaces other then PPRGB/gamma=1 is to have someone with inside knowledge tell us.

By the way, I have some work experience with color space conversion using 3DLUTs, though it's at the interpolation level: http://spie.org/Publications/Journal/10.1117/12.208656

Jim

[Schewe]

Let's take the footnote in Eric's comment first: "ACR does use L*a*b* for some internal color difference estimates, e.g., for auto-calculated masks." It's not clear to me that you need to convert the entire image to Lab to generate masks. I will admit that I con't figure out what masks Eric is talking about, and it is entirely possible that you do need a full-res Lab version of the image to do these color difference (probably DeltaE) calculations.

I think he's referring to using the L* to create auto generated edge masks in the Detail panel...also note that sharpening (and luminance noise reduction) are applied to the luminance data only. I'm not 100% sure it's L* but I think it is...so, I'm not sure how you would separate out the L* of L*a*b* if you don't actually convert to Lab, do you?

[deejjjaaaa]

With respect to the DNG spec, the existence of color spaces that are used to build 3D color Look-up tables is not evidence that the image needs to be converted to each of those spaces.

I was not stating that they produce copies of the whole image in all those spaces at once, but you can't apply LUT /dcp LUTs/ unless for each pixel you do the trip from ppRGB/g1 to HSV and back for example... I was saying "you might assume that there is a moment when the same image data is presented in RAM in 2+ spaces at once" - may be just in 2 (and not 3+)... certainly you can have a range of tricks to avoid that (for example replacing pixel related data in place, in exisiting memory structure, instead of in a newly allocated memory structure, etc)...