# Creating a Virtual Copy from a TIFF after using an external editor..



## MMarz (Jan 24, 2011)

I have challenges in LR with editing TIFF files produced as a result of using an external editor...sliders and overall performance is sluggish and sometimes causes "An Unknown Error" or out right crashes so I have started to create Virtual Copies immediately upon the return trip into LR from an external editor and continue the balance of my edits from there.

Assuming there are no earlier edits I need to have access to (the starting point for my TIFF is last edit to my DNG before leaving LR) am I missing functionality or quality if I work only on the low-overhead VC's?


----------



## Victoria Bampton (Jan 25, 2011)

Nope, no quality loss, although I'm fascinated to know why you're seeing a performance difference. Can you tell us a bit more about that?


----------



## MMarz (Jan 25, 2011)

Wish I could tell you more on this Victoria..  It didn't make sense to me either but sure enough, it seems to be true..   When editing TIFF's, sliders and refreshes all drag and slow.  If I apply too many edits without giving LR a chance to breathe, it will surely crash and require a reboot.  But when I create the VC fromthe TIFF, the sliders are more responsive..  I'll run a few more tests to reconfirm, but I am confident of what i will find.  What I would really like to know is why my machine, which isn't a dog, has issues with TIFF's in the first place...


----------



## RikkFlohr (Jan 26, 2011)

In your Edit>Catalog Settings on the Metadata tab, do you have Automatically write changes into XMP checked?


----------



## MMarz (Jan 26, 2011)

RikkFlohr said:


> In your Edit>Catalog Settings on the Metadata tab, do you have Automatically write changes into XMP checked?



I do, and always have.  Like many I am challenged with the exact reasoning behind why, but as I understand it, it ensures that the changes are saved to the file immediately and is a safeguard worth using.  The idea of having to manually write the changes is not warming to me.  On DNG's there is no perceivable slow down on my machine and since TIFF's are the vast minority in my workflow, I had planned to continue with DNG & Auto write to XMP..  But I am open to reasons to modify this...


----------



## RikkFlohr (Jan 26, 2011)

It is a simple test to turn this setting off temporarily and then see if your Tiffs respond as quickly as their Virtual Copies to Develop changes.


----------



## wernerg (Jan 26, 2011)

Do you use "Edit In" to send the tif to the external editor? If so, then when you return from the external editor and re-edit that same tif in the Develop Module, Lr is still updating and reloading the "Edit" tif every time you make a change. Basically Lr still thinks the edits are being done externally even though it is Lr that is doing them. This has been commented on before and as far as I know there is still no way to tell Lr that the external edit process is over and to stop reloading the tif. I do the same thing that you do, make a VC, then edit that, then make make the copy the master when you are done.

PS, the reload process goes on forever BTW.  I can go back to a months old externally edited tif and it will still reload the tif over and over again in the develop module.


----------



## MMarz (Jan 26, 2011)

RikkFlohr said:


> It is a simple test to turn this setting off temporarily and then see if your Tiffs respond as quickly as their Virtual Copies to Develop changes.


 
I know the answer to that Rikk..   TIFF absolutely do respond faster with AutoWrite to XMP off, but it's a compromise.  While I do regular back-ups of my catalog and all associated folders (presets, templates, plugins etc) I like the idea of the metadata being stored with the image as well as in the catalog.  I've tried incorporating an "Alt + S" action into my workflow on some regular basis, but I am vulnerable to forgetting.  That said, I rarely need to send an image out to a third party or to another app like bridge, so not seeing the edit info isn't a big deal for me.  It's the fear of losing the edits if my catalog goes corrupt.  

Since TIFF's represent a fairly small part of my workflow and the VC's for some reason respond faster than the TIFF from which they are born (I know, I don't get it either) I may opt to keep doing what seems to be working...


----------



## MMarz (Jan 26, 2011)

wernerg said:


> Do you use "Edit In" to send the tif to the external editor? If so, then when you return from the external editor and re-edit that same tif in the Develop Module, Lr is still updating and reloading the "Edit" tif every time you make a change. Basically Lr still thinks the edits are being done externally even though it is Lr that is doing them. This has been commented on before and as far as I know there is still no way to tell Lr that the external edit process is over and to stop reloading the tif. I do the same thing that you do, make a VC, then edit that, then make make the copy the master when you are done.
> 
> PS, the reload process goes on forever BTW.  I can go back to a months old externally edited tif and it will still reload the tif over and over again in the develop module.



Now that's interesting..

Yes, virtually all of the TIFF's are born from the Edit In command..   I hadn't noticed this, but are you saying that if I return to LR from an external editor, and continue to edit the TIFF in LR, that file is updated in the external app on the fly?  Say I take a DNG and send it to Vivesa...  The TIFF is created and opens in Viveza and when saved the edits are displays in LR's TIFF.  If I then perform another edit in LR.. say a crop.. it will update in Viveza?  How can that be?  Maybe if the external editor is PS or PSE where the TIFF that was sent remains open in the PS window, then the TIFF might update on the fly.  But most of the plugins I use, most of which are accessed via the Edit In command, close the app once the external edits are completed and saved.  There's nothing displayed to update...  

Are you confident in what you are describing?  I am not in the studio to give it a try..


----------



## wernerg (Jan 26, 2011)

MMarz said:


> Now that's interesting..
> 
> If I then perform another edit in LR.. say a crop.. it will update in Viveza? How can that be?



Viveza probably doesn't automatically update its saved tifs back into Viveza, it not expecting another program to make changes, but Lr does.  When Lr sends an "xxxx_Edit.tf" to the external editor, the edits magically appear in Lr as soon as you "Save" in the external editor.  I'm not a programmer so I don't know the exact process but Lr is clearly tracking the history of the "xxxx_Edit.tif" and reloads into Lr whenever a change is saved.  You should see a "reloading" sign flash whenever you make a change in the develop module.  My computer isn't very fast so I see the "reloading" sign for a second or so.  If yours is very fast you may miss the sign but detect only sluggishness.


----------



## RikkFlohr (Jan 26, 2011)

If you convert your Tiff to a DNG does your response time improve?


----------



## wernerg (Jan 26, 2011)

If you are asking me, I don't do DNG's.  Making a VC and editing that in Lr is a fast and simple way to deal with it until the problem is fixed.


----------



## RikkFlohr (Jan 26, 2011)

No, I was asking Michael.  He is looking for a solution to his workflow. If the TIFFs slow down but the DNGs do not, this is a workable solution.


----------



## MMarz (Jan 26, 2011)

wernerg said:


> Viveza probably doesn't automatically update its saved tifs back into Viveza, it not expecting another program to make changes, but Lr does.  When Lr sends an "xxxx_Edit.tf" to the external editor, the edits magically appear in Lr as soon as you "Save" in the external editor.  I'm not a programmer so I don't know the exact process but Lr is clearly tracking the history of the "xxxx_Edit.tif" and reloads into Lr whenever a change is saved.  You should see a "reloading" sign flash whenever you make a change in the develop module.  My computer isn't very fast so I see the "reloading" sign for a second or so.  If yours is very fast you may miss the sign but detect only sluggishness.



I do see a flash that could be interpreted as Reloading, but I don't see the text at the bottom.. but I think I have that turned off in preferences.  As I ponder your post, I can see LR communicating back and forth to an external editor that has the image open..  But once closed..   In my situation, a TIFF is a TIFF as far as LR performance regardless of whether the image is open or not.  I make it a point to close external editors once done and back in LR.



RikkFlohr said:


> If you convert your Tiff to a DNG does your response time improve?



Good question Rikk..  DNG -> TIFF -> DNG.. gotta try that.  I'll let you know.


----------



## wernerg (Jan 26, 2011)

Try working with a tif not created by the Edit-in process. I drag and drop tifs into Lr from pano programs and they respond to changes in the Develop Module as fast as raw files. Tifs created directly from real plugins, like Enfuse, not via the Edit-In process, don't experience the same behavior either. On my machine closing the external editor doesn't stop the reloading when further changes are made in the develop module. I think Lr is doing it to itself... unless there is a button somewhere that turns it off?


----------



## MMarz (Jan 26, 2011)

wernerg said:


> Try working with a tif not created by the Edit-in process.



That might be valuable as a test, but it won't help my workflow at all.  TIFFs are ONLY introduced into my workflow as a result of the Edit In dialog.  Communication between LR and the external editors is important as LR does 95% of my editing and cataloging needs..  I have no reason to introduce TIFFs for any other reason.


----------



## wernerg (Jan 26, 2011)

OK, but it might identify whether or not it is a "tif" problem or an "Edit-In" problem.  Either way, editing a VC after the external edit is the fastest way I've found to deal with it.


----------



## Mark Sirota (Jan 26, 2011)

I wonder if this is related to the registry key issue discussed in this painfully long thread on the Adobe forums (search for "registry" starting around page 3 or 4).


----------



## wernerg (Jan 26, 2011)

The registry is a scary place for me to play in but that discusson appears to be about develop module slider performance in general.  My problem is specifically with tifs created by the "Edit-In" command for external editing.  If I try to do additional editing on that xxx_Edit.tif file in Lr's Develop Module after the external edit is finished, the process is continuously interrupted by a "Loading" dialog box and a redraw of the reloaded file whenever I touch a slider.  I'm assuming that this is caused by Lr's saving edits instantly.  The OP is using the same Edit-In process and is seeing "sluggish" reponse to sliders in the Develop Module.  I think we are seeing the same problem with different computer capabilities but I'm not sure about that.  But we both have found the same solution; work on a Virtual Copy of the Edit-In tif and the make the copy the master later.  Tifs created in other ways respond "normally", ie like raw files, to the Develop Module sliders.


----------



## Mark Sirota (Jan 26, 2011)

It was found somewhere in there (I think I have the right thread) that it was the auto-write to XMP that was triggering lookups in the registry, and some cleaning of the registry would clear it up.  It's possible I've found the wrong thread, if you don't see that there...


----------



## wernerg (Jan 26, 2011)

I think you have the right thread, they were talking about auto-writes and xmp, but it seemed to be an all-the-time thing, not related to just one specific file type created by one specific process.  I have seen no similar issues with editing raw or other tif files in the develop module.  If it is an xmp auto-write issue shouldn't it affect every file type?   It is only happening to the Edit In tifs that are constantly be reloaded and causing pauses during the reload.  The Virtual Copies of Edit In tifs behave normally also.


----------

