New Content Since Last Visit
No New Content Since Last Visit
In the Process-Edit-Process thread, which has really meandered quite a lot, I think some progress has been made toward identifying what some real issues are here. I've been giving the matter a considerable amount of thought to one in particular: the problem some JPEG shooters have with their originals being moved when using Develop or Edit mode.
As I've mentioned elsewhere, I don't exactly love this aspect of the implementation either. But nor do I love the idea of having to do explicit exports to make my JPEG edits visible to the outside world, as one has to with Lightroom. In my mind, they're both awkward and unfortunate side effects of the need to keep separate original and edited copies of an image in order for non-destructive editing to function. I don't see a way to implement non-destructive editing with none of those unfortunate side effects, and apparently neither Adobe nor ACD does either, or they'd have done it. Nor do I see any way to predict which of these awkward and unfortunate side effects would be more painful to more users. I think Bill has outlined a proposal for treating JPEG's more like RAW files, and this in effect "solves" the problem by moving toward the LR model. If it is determined that moving JPEG originals must be avoided at all costs, then I think his ideas make sense.
But again as I described elsewhere, I also wonder whether it would be possible to address most of the concerns over the moving of JPEG originals without such a drastic implementation change (and the corresponding need for an explicit "export" command or an equivalent way to make edits available to the outside world). So this is where I would like to outline my ideas for solutions, and see to what extent they would actually problems.
First, my assumption is that if you truly want your originals all in one place and not touched in any way by ACDSee or any other program, the simplest way to do that is to close your working folder before you begin editing, archiving the originals and then working on the cloned folder. That's actually what I've advocated in the past (in my DAM article series). It seems to me if always having all originals from a shoot in one folder together is important to you, then think this makes a lot of good basic sense, and fits in well with many sound backup strategies. If you take this approach, then concern about what ACDSee does with the cloned copied almost goes away right there (but not entirely, and that's why I'm just getting started here :-).
I also recognize that this isn't always acceptable - for some people, the need to have all originals together isn't important enough often enough to be worth altering one's workflow to be worth this cloning up front (or else, it isn't practical for whatever reason - time or disk space constraints, syncing metadata between original and cloned copied, etc). But nevertheless, the need might come up to be able to access all originals for a shoot at once. For this reason, I am advocating that ACD add an "Originals" item to the "Filter" list, to allow one to view the original versions of any group of files. Or some similar mechanism, but this seems simplest to me to fit into the exist architecture. The goal would be to provide a way to access the originals for the whole folder at once, which you could then burn to disk, backup to another drive, etc, as you see fit. I also advocate providing an option to not hide the Originals and Develop folders. Yes, one can turn on display of hidden folders, but maybe I don't want them hidden to the outside world either, and maybe I don't want ACDSee to be showing me *all* hidden folders - just these.
The question is, between the suggestion of cloning the folder before beginning and having the option to view all originals together, what remaining objections would there be? If you do the clone, the originals *are* all the same folder and are never moved. If you don't clone but instead rely on the Filter, then yes, your originals may still be moved. But really, they were moved when you downloaded them from the camera; they'll be moved again if you ever migrate them to a different drive, moved again if you back them up and restore them. And besides, in the old world, the originals would have been *overwritten* if you followed the same steps - surely that's worse than having them moved? And they are not scattered all over the place either - they are still underneath the current folder, at most one level removed, and can easily be all backed up together by backing up the main folder, etc. So again, the question is, aside from a general uneasiness with files being moved, is there is any specific *problem* not addressed by this?
Before you answer, let me raise the objections I see, and propose solutions for those too.
So again, we're now assuming that those JPEG who care about having their originals all int he same folder can either clone the folder before beginning, or else can use Filter->Originals feature to view their originals together after the fact, and I'm looking for things that would still be problematic.
I'm going to start with the case where we go ahead an do the clone. If you use Edit mode on these cloned copies, you really don't need ACDSee saving yet another copy every time you edit one of those clones. Actually, I'd personally find it useful, since my *real* originals would at that point likely be on a external drive and perhaps not easily accessible while I'm editing the clones. So being able to quickly undo my edits and start over without having to reconnect that drive (which might well not be in the same city as me at that point!) would be very nice. So from my perspective, I'd like to see a simple command from within ACDSee to delete all saved originals for a given set of files (ie, removing the "E" from the image on Manage mode). I'd use this to reclaim the space taken by those extra copies when I feel I am done with my editing of the cloned folder. Others who don't foresee a problem with having access to the original folder while working on the clone would probably prefer an option to simply turn off the saving of originals, so the space is saved right off the bat rather than needing to be cleaned up later. I think *both* of these would make *fabulous* enhancements to the current implementation. Potentially worth holding up the release for - but, luckily, also completely "compatible" enhancements that could be added for a 3.1 release with no great complications.
Again, assuming you're doing the cloning, but now looking at the case where you use Develop mode - there is simply no way to avoid the fact that there will be two copies aside from the true pre-clone, archived (possibly on an external drive) original. Develop mode needs the cloned original that you are working from in order to work. So there's no possibility of an option to disable the saving of originals entirely for Develop mode. And the version that actually contains your edits is, if not strictly necessary since it can be generated on the fly, valuable in that it speeds viewing. And again assuming the core implementation is left alone - so your original is moved but the edited version left in place - keeping the edited version around prevents the need for the explicit "export" step required in Lightroom. But the "cleanup" option - deleting the saved originals, removing the "D" from the developed image - would remain a wonderful enhancement to reclaim the space when I feel I'm done with a batch of images.
It occurs to me that what I've just written is actually completely compatible with Bill's suggestion of treating JPEG more like RAW. That is, whether the developed version is saved in place and the original moved, or the original left in place and the develop version saved elsewhere, is immaterial - I'd still find the "cleanup" option useful to reclaim space when done. I really can't see that it would affect my life one way or another which file goes where, except that I'm ready for the product to be released sooner rather than later :-), so I'm trying to find ways of seeing if we can come to a consensus on a solutions that addresses most concerns with relatively little effort on anyone's part (mine, yours, or ACD's). Also, I've argued elsewhere why I think it makes more sense for the edited copy to be in place - because that's what a "normal" editor would do, and I think people are going to expect their edits to be visible to the outside world without having to explicitly export them or find the edited file in another folder. But I'm still trying to understood just what the objections are to Develop mode moving the original, and how this is considered worse than an "normal" editor simply *overwriting* the original.
Speaking of which, without actually *understanding* the objections to originals being moved, one other idea occurs to me that would simplify life for those who prefer to use Develop mode more like how one would have used a "normal" editor. Those who shoot JPEG, are concerned with non overwriting originals, but are unwilling to clone the whole folder before beginning, were presumably in the habit of doing a "Save As" operation from the editor rather than save. Convenient, then, tht Develop mode has only a Save As and no Save. A change to ACDSee that might work well is to alter the behavior of Save As to then abandon the changes to the original - treat it as if it hadn't been processed at all, so that hitting Done or Next does *not* apply your changes. I believe Tracy alluded to this. Actually, I'm a little surprised it doesn't work that way already. But on the assumption there is a reason it works the way it does, I'd also be OK with leaving Save As alone, but add a new option to "Save As, And Abandon Changes To Original". This would remove the non-destructive functionality (eg, the saved version couldn't then be revisited and picked up in the same way it could had you simply hit Done or Next - your processing would have become "permanent"). But it seems a lot of the objections to the current behavior comes from people who have not really embraced non-destructive editing in the first place (and hence are not willing to put up with having a few files moved around in order to reap the rewards of non-destructive editing).
Almost done, but let's return to the case of people *not* cloning their original folder before commencing editing. In Edit mode, I assume most of these these people would be using Save As in the past in order to avoid overwriting their originals. So as far as i can tell, no change is needed to that functionality, except maybe remove the nag dialog when you try to exit edit mode after doing a save as - same rationale as "Save As And Abandon Changes To Original". Again, either Tracy or tdi or both have alluded to this. Some people would not have used Save As but would have made their own copy of the file before editing, and for those folks, having an option to simply disable the saved originals feature would allow them to edit in place as they always have.
For Develop mode, again, no getting around the need for multiple copies if we want it to work and avoid the extra step of an explicit export to make edits visible outside ACDSee. I've outlined why I think it smarter to have the edited version in place, as that the version I think the outside world is most likely to expect to see in place, since that's how "normal" editors work. The options I described above for Save As And Abandon Changes To Original would, presumably, also be appreciated here. But in the default case where you simply hit Done or Next, I guess I do keep coming back to how "normal" editors work, and in "normal" editors, that overwrites your originals - I can't see how moving them out of the way can be considered worse. So I don't perceive the *need* for change there.
Anyhow, that's *my* perception of the path of least resistance here. I think users who find it important to their workflow to have all their originals in one folder are best off cloning the folder before beginning, as that accomplished this most directly and simply. But even so, that leaves room for some enhancements to ACDSee in order to better support that type of workflow, and to better handle the cases where people have not first cloned their originals folders. So the list of enhancements needed for ACDSee to address the issues as I've framed them are:
- Add global option to not hide Originals and Developed folders. Or just *don't* hide them; I doubt that many would mind seeing them. Although I guess that opens the door for more questions on what they are there for from people who otherwise might have remained blissfully ignorant, so an option is probably better)
- Manage Mode: add Filter->Originals (should appear to work same for JPEG and RAW) or equivalent way to view the original versions of currently displayed files. BTW, one alternative is a separate "Show Originals" command that works on currently *selected* (as opposed to currently *displayed*) files.
- Manage Mode: add "Remove Originals" command for selected JPEG files (affects both Developed and Edited files, making the processing "permanent").
- Edit Mode: add option to not save originals. Perhaps implemented as separated command from within Edit mode ("save" versus "save without saving original") or else a global option. But if it's a global option, there should still be a way to override it case by case, and it shouldn't create more work in the cases where you don't want to override it. That is, Save should *silently* save with originals saved or not saved according to the global option setting, but there should be a way to explicitly override this from within Edit mode for a given file.
- Edit Mode: add command to Save As And Abandon Changes To Original (better named, of course; or just make that the default behavior of Save As and eliminate the current nag dialogs).
- Develop Mode: add command to Save As And Abandon Changes To Original (same observations as above).
I think that actually finally covers what I've been thinking. My feel is that these changes are actually rather small but would address practically all concerns raised. Figuring out which of these are worth holding up a release for and which aren't - well, that's not my job. But I'm actually quite excited to realize that *all* of these could potentially be released in a 3.1 version in a completely compatible way - eg, adding these options and commands in 3.1 wouldn't break any work done with 3.0 that I can see. As opposed to changing the relative locations of the saved original and edited version of file (which is done in place, which is moved elsewhere), which I think everyone would agree would be a *nightmare* to change after 3.0 goes out.
