Skip navigation
Currently Being Moderated

In which order is the raw file rendered?

Mar 3, 2013 1:30 PM

Tags: #rendering

As far as I understand (and can measure), in the develop module Lightroom renders the picture in stages and can cache the image state of a stage so future changes can be rendered faster.

 

This sounds confusing, lets start simpler:

 

When I have an image with a lot of local corrections and I change some basic setting light brightness, dynamics, saturation, Lightroom will render the change quite fast, usually in about half a second.

 

If, on the very same picture, I change the noise reduction setting it will take Lightroom several seconds to render and update the image on the screen!

 

So it seems Lightroom caches the result of the noise reduction and when I change a basic setting it does not need to render the noise reduction anew, it just can take a cached image and work from there.

 

And I would like to know which cached stages exist in the current version of Lightroom and in what order they are rendered.

 

Is this information available somewhere? Or at least some hint about the order in which an image is rendered internally, this would help me a lot!

 

Thanks!

Sam

 
Replies
  • Currently Being Moderated
    Mar 3, 2013 3:42 PM   in reply to radeldudel

    radeldudel wrote:

     

    Is this information available somewhere? Or at least some hint about the order in which an image is rendered internally, this would help me a lot!

     

    No, and it's actually a lot more complicated than you think and exactly how the ACR/LR pipeline works is proprietary info and unlikely to be disclosed.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 3, 2013 4:53 PM   in reply to radeldudel

    The official position is as Jeff describes, this question has been asked many times and details have not been made public.

     

    All the producers of software for the processing of RAW data from digital cameras adopt the same approach, the camera manafacturer, other third party providers like Adobe, DxO, Capture One, Silkypix, DCRAW, ACDC Pro, AfterShot Pro etc.etc.etc. all have proprietory processes that they will not disclose, period.

     

    That said, I have used Lightroom since the Beta of version one and afaik

    1. Lightroom has a specific order for applying the rendering of development adjustments, irrespective to the order they are applied by you.

    2. On import of images Lightroom applies the import defaults and presets (if selected) and creates Preview data files which are used by Lightroom to display the images in modules other than the Develop Module. Lightroom also creates info in the ACR Cache folder which is used to assist the develop module in rendering and displaying the image.

    3. When you are working on an image in the develop module the original image is rerendered each and every time you make a change, re-applying all the process in the prescribed order. This is why moving between files in this module takes more time than the Library Module.

    4. There are a number of edits that take longer to process by the very complex nature and how they affect other processes. e.g. Lens correction, Noise reduction, and are better done in the latter part of your editing.

    I have tried to make this simple an short, just to get to the point. Get the simple processes out of the way first, then work on the complex finesse issues last.

    Just an opinion.

     

    One other point, do not think Photoshop, Lightroom is not Photoshop and requires a completely different thought process. Photoshop makes the change in the order you choose, Lightroom makes their own choice.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 3, 2013 5:49 PM   in reply to DdeGannes

    DdeGannes wrote:

     

    3. When you are working on an image in the develop module the original image is rerendered each and every time you make a change, re-applying all the process in the prescribed order.

    This statement may need some editing in order to be correct as worded.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 3, 2013 8:21 PM   in reply to Rob Cole

    OK, how do you think it should be worded. "in the designed order"?

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 3, 2013 8:34 PM   in reply to DdeGannes

    It takes multiple seconds to do what you describe (rerender entirely, from scratch, re-applying all the process in the prescribed order), so I don't see how it could (or why it would) do that for every little tweak you make.

     

    I'm drawing my conclusion based on observation and limited understanding - I could be wrong.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 3, 2013 8:46 PM   in reply to Rob Cole

    Its just my understanding of how it works. Somehow the ACR cache assists in the process. The other option would be to update and use the preview.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 4, 2013 8:57 PM   in reply to radeldudel

    radeldudel wrote:

     

    Some adjustments are faster than a complete recomputation of the image, so there must be some kind of caching at work.

    Most definitely.

     

     

    However, I suspect Jeff Schewe is right on both counts:

    * More complicated than we might imagine.

    * Adobe shan't try to elaborate.

     

    Sometimes said algorithm is tweaked on a per dot-release basis, in the quest for improved performance and reliability/stability, which is probably one of the reasons new dot releases perform better for some folk (or in some ways), and worse for others (or in some ways).

     

    Anyway, there have been user recommendations when things were noted about how one adjustment affects speed in general, or speed of other adjustments in particular, but I've never followed nor scrutinized, so I don't know...

     

    Good luck,

    Rob

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 4, 2013 10:39 PM   in reply to radeldudel

    radeldudel wrote:

     

    A pity. For speed it matters if I work with or against some kind of order and information about this would be helpful.

     

    As it relates to the order a user does something, there are general rules...if you are going to do lens corrections, it's better to do them before doing tones of spot healing or local adjustments because if done first, the local brush masks and spot healing must them be warped the same as the lens corrections-which can slow down ACR/LR considerably...

     

    Noise reduction–depending on the preview size can also have an impact of screen refresh of adjustments made after the noise reduction has been set because ACR/LR is previewing the noise reduction (to the size of the preview) and then trying to update the additional adjustments...you can, in LR, turn off the Detail panel adjustments by sliding the preview slider to off–this will speed up refresh of additional adjustments, but you'll need to remember to turn the Detail panel back on after making the other adjustments...

     

    There are factors that impact performance...obviously, multiple real cores helps, so does ram (up to a point) and really fast drives. The size of the LR display window impact performance too. Using LR full screen on a 30" display is going to slow down refresh because more screen pixels must be calculated than with say a 24" display.

     

    Everything seems to impact everything...but I wouldn't worry too much about the exact order of the raw processing pipeline because, well, you can't change it and Adobe is unlikely to disclose what it's doing when and why.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 4, 2013 11:19 PM   in reply to radeldudel

    Have you tried the 4.4 release candidate? I'm curious.

     

    4.4 RC seems much snappier than 4.3 on one of my two machines, to the point where it now really feels hardware-limited, as it should, instead of "something else" getting in the way. (Also D800, but smaller monitor).

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 5, 2013 12:23 AM   in reply to radeldudel

    radeldudel wrote:

     

    Uh, this is interesting! So there is a difference between first doing local adjustments, then lens correction or the other way around? Or, in other words: Does the order of corrections matter in this case because it will lend to different results (and speed)?

     

    Different speeds, yes...but the rendered results should be the same. If the adjustment brush masks and spot healing is done before distortion correction, LR must render the masks and spot healing as placed in the uncorrected image and then transform them to correct for the lens corrections. This has an impact on the speed because of the difference in pre and post lens corrections.

     

    The pipeline is the pipeline and the results should always be the same no mater what order you do them in, but the order the user makes adjustments can have an impact on performance...but...

     

    The ONLY thing I can think of that is literally order dependent is the order you put spot healing points down...if you place one down and then do another point with a slight overlap, the order that you place them will change the results...

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 5, 2013 12:43 AM   in reply to Jeff Schewe

    Red eye detection is also dependent on the current state.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 5, 2013 8:09 AM   in reply to radeldudel

    I can't tell you why, but I did run a few tests here:

     

    http://forums.adobe.com/message/5094278#5094278

     

    Using LR defaults with no NR etc. browsing images takes about .5 sec. on my system to reach maximum sharpness. Add Luminance NR and that goes up to 1.0 sec. Add Luminance NR and Defringe and it goes up to 1.5 sec. My guess is that you are seeing different image building stages onscreen.

     

    Another interesting rendering order I would like to point out is that LR applies the Local Tone controls prior to the Global Tone controls:

     

    http://forums.adobe.com/message/4612100#4612100

     

    This has ramifications to the image dynamic range. Any Local control setting that increases image highlights runs the risk of creating unrecoverable clipped highlight areas. Try the test outlined at the above link and read the other comments further down.

     

    The takeaway here is to use the Local controls in the direction of reducing highlights and increasing shadow areas. This has no impact that I am aware of concerning LR's speed, but it is something you should be aware of when making Local adjustments.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 5, 2013 1:59 PM   in reply to radeldudel

    Try 1:4 size.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 5, 2013 2:59 PM   in reply to radeldudel

    radeldudel wrote:

     

    I wonder how Lightroom fares on Retina-displays.

     

    The higher the display resolution the longer it will take to render the screen preview. It's should be proportional to the screen Megapixels:

     

    1280x1024 =  1.3 Mp

    1920x1080 = 2.1 Mp

    1920x1200 = 2.3 Mp

    2560x1440 = 3.7 Mp

    2560x1600 = 4.1 Mp (Retina 13" Display)

    2880x1800 = 5.2 Mp (Retina 15" Display)

     

    Based on these numbers I would expect the Retina 13"  to be 2x slower than a 1920x1080 display resolution and the Retina 15" about 2.5x slower.

     

    You can easily control this by pulling in the right, left and bottom film strip panels to make the center preview image smaller. Unfortunately on a 13" or 15" Retina screen the preview image is going to be fairly small, which is not too helpful.

     

    Until Adobe adds GPU acceleration to LR to speed up preview rendering there isn't much else we can do. A faster processor helps, but as we well know some systems with fast processors are still slow.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 6, 2013 7:13 AM   in reply to radeldudel

    The MacBook Pro with Retina display uses two graphics processors:

     

    1) Integrated Intel HD 4000 using system memory

    2) High-Performance NVIDA GeForce GT 650M with 1GB of GRAM

     

    It automatically switches between them depending on the application being run, I assume to save power. Since LR currently does NOT support any type of GPU acceleration its performance is the same regardless of which graphics processor is being used.

     

    See test here:

     

    http://forums.adobe.com/message/5094278#5094278

     

    You can "scale" Retina displays to reduce the resolution by 1/2 (1/4 Mp). This would increase LR's performance considerably at the expense of losing the Retina fine resolution capability.

     

    IMHO using Retina's 2x display resolution with LR isn't going to help you make better image adjustments, so scaling makes good since. For image "viewing" you can use the multitude of applications already provided and/or supported on Retina based Mac products.

     

    Anyone here care to comment on their MacBook Pro with Retina display performance using LR 4.3/4.4?

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 9, 2013 7:10 PM   in reply to radeldudel

    radeldudel wrote:

     

    trshaner schrieb:

     

    It's should be proportional to the screen Megapixels:

     

    Yep, it should

    No, it shouldn't.  There are discrete rendering sizes - 1:1, 1:2, 1:4, 1:8 etc.  If you're in between two of those, it renders at the next higher one.  Each one should be 4 times as fast as the previous.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 10, 2013 5:04 AM   in reply to radeldudel

    Lee Jay is correct. The speed difference should be in 4x steps proportional to the standard pyramid view sizes (1:1, 1:2, etc.).

     

    For 5D MKII files these are the display image sizes:

     

    1:1  5616x3744

    1:2  2808x1872

    1:4  1404x936

    1:8  702x468

    1:16 351x234

     

    On my 1920x1080 display based system 1:16 views (351x234) take just as long as the 1:2 view size (2808x1872) when browsing in full-screen mode in the Develop module. It isn't until 1:1 view size (5616x3744) that I see a difference and it is 4x. Why it's not proportional to the actual pyramid view size steps I have no idea.

     

    So you can improve the browsing speed by reducing the image size. Once you hit the "speed bump" display size you should see a 4x speed up in screen rendering.

     

    Cheers,

     

    Todd

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 10, 2013 7:17 AM   in reply to trshaner

    I was talking about frame rate when moving sliders, not image to image time.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 10, 2013 10:27 AM   in reply to Lee Jay

    I just tried the effect of image size on moving sliders using the worst case with Luminace NR and Defringe tool applied and I'm only seeing a 2x difference between 1:16 and 1:1 views (i.e. four pyramid steps).

     

    I'm sure this has to do with how the Camera Raw Cache file speeds up image building in the Develop module during real-time image adjustments. In the case of "browsing" in the Develop module it doesn't appear to help as much since I'm seeing a 4x difference.

     

    Try it for yourself and let me know what you see. These things tend to be system specific so all bets are off that your Develop module behavior will match mine (i.e 2x sliders and 4x browsing at 1:16 vs 1:1 views).

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 10, 2013 2:53 PM   in reply to trshaner

    I'm talking about global sliders like exposure.  Things like CA may have to work on the full size, I'm not sure.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 10, 2013 3:53 PM   in reply to Lee Jay

    Sorry. I was referring to the White Balance slidersTemp and Tint slider response, which is worst case with Luminnce NR and Defringe settings. I guess you can find many variations as to what slows things down and which controls are affected. The point I was trying to make is that none of the controls exhibit a 4x response increase for each pyramid step. Agreed?

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points