# Use Smart Previews instead of Originals for editing – implications for workflow



## camner (Oct 7, 2016)

Before 2015.6.7, I always created 1:1 previews upon import, because disk space was no issue for me, and it made the process of editing faster, particularly moving from one image to the next and doing noise reduction.  I also retained 1:1 previews forever, again because space was no problem.

(I'm assuming that in order for this option to be effective, one needs to have LR generate the Smart Previews, either upon import or manually.  Yes?)

With this new option to use Smart Previews for editing, I'm wondering if my workflow should be revised. I see a couple of choices:

On import, render Smart Previews instead of 1:1, letting LR generate the 1:1 images as needed (which they will be on all images, since I always do at least some sharpening)
 On import, render Smart Previews instead of 1:1, manually generating 1:1 images after import is complete
Obviously #2 will cut down time at least a bit when I sharpen each image, since if I go with #1, LR will have to render the 1:1 preview "on the fly," thus resulting in some delay.  Have people noticed that this is an annoying delay?

I'm also reconsidering my prior practice of retaining 1:1 previews forever, not because I can't spare the space, but because I'm wondering if having such a large preview cache affects performance at all.


----------



## clee01l (Oct 8, 2016)

I haven't figured out what I'm going to do yet.   Currently on import, I generate minimal previews and no Smart previews.  My imports are 36mp RAW image and quite large for an image that may get rejected on the first pass.  This way my imports go faster and I can be culling before the import finishes. 
Regular 1:1 previews are going to get generated as needed and perhaps several times during the develop process.  So, it doesn't really help to generate a 1:1 of a soon to be obsolete view of an image.

Smart Previews (before the latest release) were never needed for every image imported. Smart Previews  were only use for Collections sync'd to the LR Mobile cloud.  Or for going portable and leaving the disk containing the primary image file behind.  The latter did no apply to me and the former takes care of it self as soon as a photo is added to a Sync'ing collection. 

I can see some advantage to working with Smart images during the develop process.  So my dilemma,  should I create these for all newly imported images even though a large number of these will be deleted in the first pass?  I think I will  Spoace has never been a problem and a faster develop cycle could be an advantage.


----------



## Johan Elzenga (Oct 8, 2016)

First of all, the 1:1 previews you can generate on import are not used in the develop module (but in all other modules), so I don't see how they could speed up noise reduction or other edits. They do speed up going from one zoomed-in image to the next in the library module however, for example to check focus. The develop module generates its own, different previews. If you zoom in to 1:1 (for sharpening or noise reduction) a 1:1 preview will be rendered, but that is irrespective of the previews you generated on import.

The new 'edit with smart previews' option does speed up editing, but it takes quite long to generate the smart previews on import. Obviously, generating 1:1 previews on import as well, will slow down the import process even more. So in that respect you may reconsider your workflow, but do not think that smart previews somehow replace 1:1 previews. They don't.


----------



## Jim Wilde (Oct 8, 2016)

Adding to what Johan has said:

1. The 1:1 preview which is generated in Develop is temporary (system cache only), and is not stored on disk anywhere.
2. Any 1:1 library preview (or standard preview for that matter) that was stored in the Library preview cache is automatically deleted when you start to edit the image in Develop (because it's now wrong, right?). A new preview is started, but this contains only thumbnails (for filmstrip, navigator views). When the image is subsequently brought onto the screen in the Library module (Loupe, Grid, Filmstrip), a new Standard preview is generated. A new 1:1 preview will only be re-generated either by zooming into 1:1 in Library, or by instructing Lightroom to re-create it. So the idea of "retaining 1:1 previews forever" needs to factor in this process.
3. Smart Previews are only generated on request. If you sync an image with LRmobile which already has a Smart Preview, that preview is used for the sync upload. If a Smart Preview does not already exist, it is generated for the sync upload, then discarded again.


----------



## clee01l (Oct 8, 2016)

Jim Wilde said:


> 3.* Smart Previews are only generated on request*. If you sync an image with LRmobile which already has a Smart Preview, that preview is used for the sync upload. If a Smart Preview does not already exist, it is generated for the sync upload, then discarded again.


What happens now when you have "Use Smart Previews  (instead of Originals for image editing" checked.  Does this mean that you have to generate Smart Previews on import or manually using the Previews menu item?  That is to say if I don't already have a Smart Preview generated through membership in a sync'd collection or intentionally on import or manually through the menu, then will image editing always use the original no matter what the state of the checkbox is?  If this is true, then you have to generate Smart Previews on import or manually to take advantage of the speedier Smart previews during image editing.


----------



## Jim Wilde (Oct 8, 2016)

Yes, that preference setting only applies if a Smart Preview already exists in the cache. If it doesn't exist, LR will use the original.


----------



## clee01l (Oct 8, 2016)

Jim Wilde said:


> Yes, that preference setting only applies if a Smart Preview already exists in the cache. If it doesn't exist, LR will use the original.


So, turning it on in the Performance tab and not creating on import does not buy you anything. Even if you have images in Sync'd collections.  If you want to take advantage of Smart previews for some images, you need to create Smart Previews for all/any images that "might" get to the develop module.


----------



## Jim Wilde (Oct 8, 2016)

Yes, and if you think about it, it's probably quite logical. But I agree that the preference setting could be clearer, maybe adding "if they already exist".


----------



## Johan Elzenga (Oct 8, 2016)

I think it's completely logical if you understand the concept. Smart previews are substitutes for originals. That is still the case, nothing has changed in this respect. What changed is that up till now, they were only used if and when the originals are offline. Now, you can also use them while the originals are not offline; to speed up your edits. It's obvious that this means they do have to exist in the first place...

BTW, I think Adobe should expand on this, and also offer an option to use smart previews for panoramas, even if the originals are not offline.


----------



## Jim Wilde (Oct 8, 2016)

JohanElzenga said:


> It's obvious that this means they do have to exist in the first place...



Well, it was obvious to you and I, Johan.....


----------



## tspear (Oct 8, 2016)

Until I read a detailed blog from Adobe about it, I made the assumption that Lr would create the smart-previews for me.
So, I think the checkbox label could be a little more clear.


----------



## clee01l (Oct 8, 2016)

Jim Wilde said:


> Yes, and if you think about it, it's probably quite logical. But I agree that the preference setting could be clearer, maybe adding "if they already exist".


What was not clear until an earlier statement from you is that the sync'd collection Smart Previews are not permanent and are created as a temporary file for LR Mobile and nowhere else.


----------



## Johan Elzenga (Oct 8, 2016)

tspear said:


> Until I read a detailed blog from Adobe about it, I made the assumption that Lr would create the smart-previews for me.
> So, I think the checkbox label could be a little more clear.



I agree that if you check the preference to use smart previews, it would only make sense that the import dialog would have 'Create Smart Previews' checked by default (with perhaps a short explanation why).


----------



## liv23d!t (Feb 18, 2017)

It's Feb 18th - over 4 months since the last post - and this remains a point of confusion for some. No qualifier necessary, the option should simply include more explanation. That it doesn't/hasn't is just bad business.


----------



## clee01l (Feb 19, 2017)

liv23d!t said:


> It's Feb 18th - over 4 months since the last post - and this remains a point of confusion for some. No qualifier necessary, the option should simply include more explanation. That it doesn't/hasn't is just bad business.


Welcome to the forum.  It is not like flipping the "clarity" switch and Adobe will magically include the "more information" that you allude to.   The Adobe people doing documentation are removed somewhat from the Adobe people fixing bugs.   Between LRCC6.0 and LRCC7.0 little happens in the way of added functionality.  Less in added Documentation. Documentation of that added functionality is minimal and may not even exist.   This is not an Adobe problem. It is an age old software development issue.  I don't expect it to resolve itself in my lifetime.  It did not get any better during my 25+ years in Software development.  The people that develop the software don't need documentation.  The people that need the documentation can't understand the documentation  The people that write the documentation are not developers but are likely liberal arts people whose skill is word-craft.


----------



## PhilBurton (Feb 19, 2017)

clee01l said:


> Welcome to the forum.  It is not like flipping the "clarity" switch and Adobe will magically include the "more information" that you allude to.   The Adobe people doing documentation are removed somewhat from the Adobe people fixing bugs.   Between LRCC6.0 and LRCC7.0 little happens in the way of added functionality.  Less in added Documentation. Documentation of that added functionality is minimal and may not even exist.   This is not an Adobe problem. It is an age old software development issue.  I don't expect it to resolve itself in my lifetime.  It did not get any better during my 25+ years in Software development.  The people that develop the software don't need documentation.  The people that need the documentation can't understand the documentation  The people that write the documentation are not developers but are likely liberal arts people whose skill is word-craft.


+1. No, +2 to what Cletus said.

Also, when the software development is behind schedule, guess what post-development activity is shortened or skipped altogether to make the schedule.  

Phil


----------



## Paul B (Feb 20, 2017)

PhilBurton said:


> when the software development is behind schedule, guess what post-development activity is shortened or skipped altogether to make the schedule


Could be worse ... I'm sure in some establishments requirement writing is a post-dev activity


----------



## clee01l (Feb 20, 2017)

Paul B said:


> Could be worse ... I'm sure in some establishments requirement writing is a post-dev activity


This is also known as scope creep.


----------



## Paul B (Feb 20, 2017)

clee01l said:


> This is also known as scope creep.


I tend to call it awkward ***** customers. As someone who's both written their fair share of requirements and also developed the ensuing systems (not usually at the same time!) I'm very familiar with the concept. However I was being tongue-in-cheek in suggesting something rather more extreme. At the end of the day, as mentioned, it's usually the testing that suffers.


----------



## tspear (Feb 20, 2017)

Paul B said:


> I tend to call it awkward ***** customers. As someone who's both written their fair share of requirements and also developed the ensuing systems (not usually at the same time!) I'm very familiar with the concept. However I was being tongue-in-cheek in suggesting something rather more extreme. At the end of the day, as mentioned, it's usually the testing that suffers.


Testing? What is that? I only have been in the IT field for 28 years and have never heard of this concept. 

Tim


----------



## Hal P Anderson (Feb 20, 2017)

If it compiles and links, it's ready to ship.


----------



## PhilBurton (Feb 20, 2017)

Paul B said:


> Could be worse ... I'm sure in some establishments requirement writing is a post-dev activity


Paul,

I wish I could say that you are only joking.  Exactly this sort of thing has happened on my watch,  but not with my agreement. 

Phil


----------



## PhilBurton (Feb 20, 2017)

clee01l said:


> This is also known as scope creep.



So true.  Or else, "We know better what they need than they do."  This is as close to a verbatim quote as I remember.  Of course, I had to kill that project.  I would like to think that the Lightroom team does not suffer from this common malady.


----------



## PhilBurton (Feb 20, 2017)

Hal P Anderson said:


> If it compiles and links, it's ready to ship.


With the kind of_ easily preventable errors_ that crop up (ooh, bad pun) in every dot-release of LR CC 2015/LR 6, I suspect that the Lightroom team thinks like this a bit.  And let's not forget that new import dialog that appeared around 2015.2/6.2 (if I remember correctly).  Obviously that was not subjected to user feedback before release.

One of the downsides of Agile/Scrum is this pressure for very frequent releases, whether justified or not.

Phil


----------



## liv23d!t (Feb 20, 2017)

clee01l said:


> Welcome to the forum.  It is not like flipping the "clarity" switch and Adobe will magically include the "more information" that you allude to.   The Adobe people doing documentation are removed somewhat from the Adobe people fixing bugs.   Between LRCC6.0 and LRCC7.0 little happens in the way of added functionality.  Less in added Documentation. Documentation of that added functionality is minimal and may not even exist.   This is not an Adobe problem. It is an age old software development issue.  I don't expect it to resolve itself in my lifetime.  It did not get any better during my 25+ years in Software development.  The people that develop the software don't need documentation.  The people that need the documentation can't understand the documentation  The people that write the documentation are not developers but are likely liberal arts people whose skill is word-craft.


Thanks, glad the forum is an active one. It sounds like you're advocating that b/c communication isn't great or b/c of where Agile/scrum tends to focus resources, I (customer) should be OK with whatever documentation is released. While I empathize with those difficulties (2 intense yrs at software/mobile SaaS) I don't exactly feel guilty for not caring about the internal-facing approach. There are any number of large companies who release perfectly great and responsive documentation, not to mention even more small ones. While I don't have some overarching vendetta against Adobe here, I think it's Ok that I expect they make confusing things easier for simple minds like mine. A quick look here and other forums suggests others tend to agree. So when can expect the clarity switch to work, if not after 4 months of complaints?


----------



## camner (Oct 7, 2016)

Before 2015.6.7, I always created 1:1 previews upon import, because disk space was no issue for me, and it made the process of editing faster, particularly moving from one image to the next and doing noise reduction.  I also retained 1:1 previews forever, again because space was no problem.

(I'm assuming that in order for this option to be effective, one needs to have LR generate the Smart Previews, either upon import or manually.  Yes?)

With this new option to use Smart Previews for editing, I'm wondering if my workflow should be revised. I see a couple of choices:

On import, render Smart Previews instead of 1:1, letting LR generate the 1:1 images as needed (which they will be on all images, since I always do at least some sharpening)
 On import, render Smart Previews instead of 1:1, manually generating 1:1 images after import is complete
Obviously #2 will cut down time at least a bit when I sharpen each image, since if I go with #1, LR will have to render the 1:1 preview "on the fly," thus resulting in some delay.  Have people noticed that this is an annoying delay?

I'm also reconsidering my prior practice of retaining 1:1 previews forever, not because I can't spare the space, but because I'm wondering if having such a large preview cache affects performance at all.


----------



## Paul B (Feb 21, 2017)

liv23d!t said:


> So when can expect the clarity switch to work, if not after 4 months of complaints?


Whilst it's absolutely no excuse for vendors producing inadequate documentation, I have to say that for a lot of complex software the best documentation is often written by third parties because it is written from an end-user's point of view _by end users_. The obvious example with Lightroom being Victoria's excellent material. I'd highly recommend taking a look through something like that rather than hanging around for Adobe to make small documentation changes which may or may not happen.


----------



## tspear (Feb 21, 2017)

liv23d!t said:


> Thanks, glad the forum is an active one. It sounds like you're advocating that b/c communication isn't great or b/c of where Agile/scrum tends to focus resources, I (customer) should be OK with whatever documentation is released. While I empathize with those difficulties (2 intense yrs at software/mobile SaaS) I don't exactly feel guilty for not caring about the internal-facing approach. There are any number of large companies who release perfectly great and responsive documentation, not to mention even more small ones. While I don't have some overarching vendetta against Adobe here, I think it's Ok that I expect they make confusing things easier for simple minds like mine. A quick look here and other forums suggests others tend to agree. So when can expect the clarity switch to work, if not after 4 months of complaints?



A few points. One, although there are a few Adobe people on this forum, it really is a users forum and is not officially associated with Adobe. Therefore, our ability to influence Adobe is rather limited.
Second, as long as I have used any Adobe product, customers have complained about documentation. And this has been going for multiple decades. As such I would speculate this lack of emphasis on documentation has become "baked" into the culture of Adobe. 
Third, you I would suggest adding a feedback item to Adobe via the official means, link on menu above, and provide a link to the issue here. A few of us would then likely vote for the issue, this may get some of Adobe's attention and get these few specific items cleaned up.

Tim


----------



## PhilBurton (Feb 21, 2017)

tspear said:


> A few points. One, although there are a few Adobe people on this forum, it really is a users forum and is not officially associated with Adobe. Therefore, our ability to influence Adobe is rather limited.
> 
> Tim



Tim,

Assuming that you are correct, and I believe you are, then that attitude is a problem for Adobe.  Social media is a great way for a company to get unvarnished feedback about its products (and its competitors).  Reading social media doesn't cost much, and the feedback it provides can't be duplicated by any other means at reasonable cost.

If any Adobe employees are reading this post, then please forward this thread, or the URL of this forum, to the right people in product management and marketing and *challenge *them to spend some time just reading.  

Phil


----------



## Victoria Bampton (Feb 21, 2017)

PhilBurton said:


> If any Adobe employees are reading this post, then please forward this thread, or the URL of this forum, to the right people in product management and marketing and *challenge *them to spend some time just reading.



We do have some Adobe Staff members and other associates who read many of the posts here, and they do feed back the information to the product team. Product management are slightly stuck between a rock and a hard place, because they're under pressure from above too. That is the downside of huge companies.


----------



## PhilBurton (Feb 21, 2017)

Victoria Bampton said:


> Product management are slightly stuck between a rock and a hard place, because they're under pressure from above too. That is the downside of huge companies.


THAT is a major fail, speaking as a management consultant (my "day job") specializing in product management.  But not all companies suffer from this problem.


----------



## clee01l (Feb 21, 2017)

PhilBurton said:


> THAT is a major fail, speaking as a management consultant (my "day job") specializing in product management.  But not all companies suffer from this problem.


I never worked for a Software development company or IT in a major industry that all had this problem.   I worked for one of the best start up "dot.com" software development companies ever to be created by the auto retail industry.   Ultimately pressure from above (Venture Capital) killed the project. The company itself had the right intentions and practices, BUT pressure from above prevented them from filling these lofty noble goals.


----------

