Luminous Landscape Forum
Raw & Post Processing, Printing => Adobe Lightroom Q&A => Topic started by: dreed on September 05, 2014, 02:41:36 am
-
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?
-
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.
-
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
-
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
-
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.
-
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.
-
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."
-
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 8)
PS: I did not notice "that file size" part... then for 180mp it sounds right.
-
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 8)
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
-
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:
(http://www.kasson.com/ll/blexif.PNG)
Just browsing in the gallery doesn't use much memory:
(http://www.kasson.com/ll/lrmemzoomedout.PNG)
But zooming in to 1:1 makes the memory go up a lot:
(http://www.kasson.com/ll/lrafteronetoone.PNG)
As does going into the develop module, even zoomed out:
(http://www.kasson.com/ll/LRindevmodule.PNG)
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:
(http://www.kasson.com/ll/lrexport.PNG)
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
-
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
-
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.
-
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
-
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.
-
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
-
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
-
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.
-
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
-
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?
-
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)...
-
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.
Jeff,
Here's a way to do sharpening in luminance on an RGB image: http://www.google.com/patents/US5793885
I'm not saying that Lr does it that way, but you certainly don't have to go to Lab to do luminance sharpening.
..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?
Starting with a pixel in linear PPRGB, multiply the red value by 0.288040, the green value by 0.711874, and the green value by 0.000086, and add the results together to form a quantity that we'll call Y. Convert from Y to L* by applying the appropriate non-linearity, which is mostly a cube root function with a straight line portion near zero.
If an approximation is sufficient, take 3/4 of the green value and 1/4 of the red value and add them together. Right-truncate to 8 bits, and use that to index into a 1D LUT to get L*.
[Added later: even more approximate, but even faster. Take the 7 MSBs of the green plane and the 5 MSBs of the red plane and use them to index into a 2Dx1D LUT that gives you L*. Or even cruder, take the 8 MSBs of the green value and use that to index into a 1D LUT that gives you L*.]
There are several options in between the above two [three] in both accuracy and computational complexity.
Jim
-
I'm not saying that Lr does it that way, but you certainly don't have to go to Lab to do luminance sharpening.
I'm not saying LR does it that way...I was just trying to expand on what Eric said...that LR/ACR does certain things that require processing to move out of RGB (or CIE XYZ). For specifics, you'll need to ask Eric.
-
Could you explain what you mean by this as in my view this explanation or rationale is pretty meaningless.
If you read through the thread from the beginning, you will understand.
-
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)...
Yes, I see. My comments have been in the context of conversion of the entire image, which is what I think is the long pole in the tent for the Lr memory footprint issue.
As an aside, and possible something worthy of some research, Eric Chan informed me some time ago that there are two image-processing pipelines in Lightroom: output-referred, and scene-referred. Raw files and 32-bit floating point TIFFs get the scene-referred pipeline. Integer TIFFs and JPEGs get the output-referred pipeline. Many of the Lr tools work differently on the two pipelines. Therefore, it's possible that the considerations involved in Lr memory footprint may be different for these two classes of files.
Jim
-
As an aside, and possible something worthy of some research, Eric Chan informed me some time ago that there are two image-processing pipelines in Lightroom: output-referred, and scene-referred. Raw files and 32-bit floating point TIFFs get the scene-referred pipeline. Integer TIFFs and JPEGs get the output-referred pipeline. Many of the Lr tools work differently on the two pipelines.
I 'd assume those are not parallel, but somewhat sequential within one workflow/pipeline... scene referred exists till you do a first color transform from raw RGB to anything else (note that EC 'd say "...I would argue it's still scene-referred colorimetry because each RGB coordinate still has a linear relationship to the non-white-balanced camera coordinates. In other words, the interpolated camera -> XYZ matrix is providing a scene-referred colorimetric interpretation of what those captured camera RGB values mean..." - I'd assume his position is that only a non linear operations like 1-2-3D LUTs applied somewhere make something non scene referred)
-
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.
Sorry but that answer did not make much sense to me either.
Can you give us any hints that you know what you are talking about?
-h