Continued Restore Workspace Problems

Moderator: jsachs

Robert Schleif
Posts: 340
Joined: May 1st, 2009, 8:28 pm

Continued Restore Workspace Problems

Post by Robert Schleif »

Even with version 8.0.338 I cannot make Open Workspace or Recover Workspace work as I think they are supposed to. In summary, while these two functions work fine if the top image on the image workspace branch has been placed there by opening an existing image file, they do not work for me if the top image on the workspace has been placed there with a script. I can provide a click-by-click scenario if that would be helpful.
jsachs
Posts: 4203
Joined: January 22nd, 2009, 11:03 pm

Re: Continued Restore Workspace Problems

Post by jsachs »

Yes, please -- I don't know what you mean by "place there by a script".
Jonathan Sachs
Digital Light & Color
Robert Schleif
Posts: 340
Joined: May 1st, 2009, 8:28 pm

Re: Continued Restore Workspace Problems

Post by Robert Schleif »

I hope that the following synopsis explains what I mean by "placed there by a script" and also illustrates the behavior thatmay be incorrect.

Image in "Test" directory
C:\Pictures\2022\Test\2022-10-29 19-15-13 (C,Smoothing2).tif
Open PWP, process image, Save As into "Final" directory in "Test" Including Script with Image copies
End PWP by clicking on the X in the upper right
Delete the image in "Test"
In a Windows directory window, double click on the .script file in
"Test\Final\ This opens PWP and reproduces the workspace.
Instead, opening PWP and choosing Recover Workspace apparently looks for an image file and reports
File does not exist .\2022-10-29 19-15-13 (C,Smoothing2) v1.images\
2022-10-29 19-15-13 (C,Smoothing2).tif
If I then select as a replacement file, the copy of the image that has been placed in "Final\Test", the workspace is correctly recovered.

If Recover workspace worked as I expect, it would find the needed image file on its own.
jsachs
Posts: 4203
Joined: January 22nd, 2009, 11:03 pm

Re: Continued Restore Workspace Problems

Post by jsachs »

I'm not sure I entirely sure I get what you are doing, but I would point out that it appears you are saving the image with image copies and not image names. When a workspace is autosaved, it is with image names -- to save with image copies would be enormously slower and not appropriate for frequent saving after every operation.

RIght after you save with image copies, there are two copies of the original image -- the one you opened with File Open and another you saved along with the script. When you save with image copies, the File Open command in the saved script file is modified to open the saved copy of the original instead of the original, so if you run the saved script it does not matter whether the original still exists or not, but if you delete the copy in the images subfolder, you will get an error. Substituting the original file will let you restore the rest of the workspace. Autosaved workspaces do not make copies so if you delete the original file you will get an error.
Jonathan Sachs
Digital Light & Color
Robert Schleif
Posts: 340
Joined: May 1st, 2009, 8:28 pm

Re: Continued Restore Workspace Problems

Post by Robert Schleif »

It looks like the problem may be that since autosave saves image names and not image copies, then when it autosaves a branch that was created not by a File/Open/Image file, but was created by a File/Open/Script, it wrongly considers the script name to be an image name.

It would be helpful if the Help text mentioned that autosave and crash recover work via image names and not via image copies and therefore if a branch was initiated with a File/Open/Image, and this source image is deleted and then the program or computer crash, you are out of luck.

A short white paper on Best Practices might be helpful. My own practice is to open an image, work on it, save with a script and image copies, and delete the original image. Thereafter, I open the script and continue to modify and add to the transformations used to edit the image. As you are seeing in this thread and its predecessor, my practice doesn't lead to smooth operation of autosave or workspace recovery.
jsachs
Posts: 4203
Joined: January 22nd, 2009, 11:03 pm

Re: Continued Restore Workspace Problems

Post by jsachs »

In my own workflow, I never delete the original files and I almost always save scripts with image names and not copies, in accord with the general idea of non-destructive editing, i.e. that you can retrace your steps from the original file to the final result. In this scenario, autosave works OK since the original files remain intact.

PWP does not distinguish between an image created with a script that was created with image copies and one created with image names -- both are just File Opens, the only difference being which file is being opened. Since it is impractical to autosave with image copies, if you want autosave to recover your images using your workflow, just don't delete the original files.

Also, saving image copies instead of image names generates a copy of all the original image files each time you save a new version, so this can lead to a lot of unnecessary duplication of image files if you save multiple versions of the image. If you save with image names, there is just one copy of the original files that all the variations share.

An example of a use case where I might save image copies instead of image names might be if I was creating a finished image I intended to print and sell. In this case, I would want to preserve all the original files along with all the operations I performed on them and store this in a safe place in case I needed to make another print or modify the file later. This way I would not have to worry about losing the original or modifying it accidentally.
Jonathan Sachs
Digital Light & Color
Robert Schleif
Posts: 340
Joined: May 1st, 2009, 8:28 pm

Re: Continued Restore Workspace Problems

Post by Robert Schleif »

Thank you for a description of your workflow.
Up to now I have chosen to save with image copies as insurance against the possibility that a Windows update or new version breaks PWP and you are not there to fix it.
When saving with image copies, the final image is saved, and a copy of the original is placed in a directory created in the save operation. Thus, when saving with image copies, two copies of the original result, the true original and the new copy. It seems like PWP should always be able to use the new copy, but as I've explained, that does not seem to be the case.
In the workflow that I have been using, I do not create new versions, I have them overwritten, and thus everything stays at v1.
Robert Schleif
Posts: 340
Joined: May 1st, 2009, 8:28 pm

Re: Continued Restore Workspace Problems

Post by Robert Schleif »

Perhaps it would be more apparent that there is a problem here if other users confirmed that this is a problem.
By the way, when recovering the workspace and PWP can't find the image, it would be helpful if more information were provided as to where PWP is looking. It would then be possible to manually direct PWP to the copy of the original image that it stored in the directory that it created in Final. Right now the path information that appears as the title of the error window is too short.
jsachs
Posts: 4203
Joined: January 22nd, 2009, 11:03 pm

Re: Continued Restore Workspace Problems

Post by jsachs »

I think I have fixed this for the next release -- the main problem was that the workspace was not being autosaved often enough so you were restoring an older version of the workspace that had not yet been saved with image copies.

Also, the dialog box that indicates a file is missing is resizeable so you can widen it if it cuts off the pathname.
Jonathan Sachs
Digital Light & Color
jsachs
Posts: 4203
Joined: January 22nd, 2009, 11:03 pm

Re: Continued Restore Workspace Problems

Post by jsachs »

On further testing, there are still problems with saving with image copies. The basic problem is that when you save with image copies, the names of the images are stored as relative pathnames with respect to the folder the script is in. While this works OK for creating scripts as a side effect of saving an image, it has a couple of problems:

1) If you merge two or more scripts (load one script and then load another without first clearing the workspace) saved with image copies from different folders, the relative pathnames are no longer sufficient to identify the image files.

2) If you save a script or workspace script to some other folder (which is what happens when PWP autosaves), the folder containing the workspace script is no longer the one containing the image files, so PWP cannot find the images.

The advantage of using relative pathnames is that you can copy, move or rename the folder containing the script and images and it will still work as long as the script and the images are in the same folder.

I am still thinking about the best way to fix this, but currently I am leaning toward converting the pathnames from relative to absolute. This will fix problems 1 and 2, but will lose the advantages of relative pathnames. When saving with image names (as opposed to image copies), PWP uses absolute pathnames so when you move the image files to a new folder or rename the folder they are in, it needs to ask you where to find them.
Jonathan Sachs
Digital Light & Color
Post Reply