Log in to post in the forums, comment on the blog and submit or rate photos in the photo contests.
New Content Since Last Visit
No New Content Since Last Visit
backup batch Beta canvas categories category color management conversion Convert crop database date develop dng Edit editor email Embed EXIF fixed format import IPTC Keywords mac metadata NEF Nikon print pro Pro 2.5 Pro 3 Process process mode RAW resize Rotate save search slideshow thumbnails TIFF upgrade vista windows 7
Sign up to get special e-mail only offers, photography and software tips from ACDSee.
Michael Presley
Member
I haven't found this in the help or in a search of the forum so I'll ask you guys: has ACDSee implimented a virtual copy feature (I really hope so), and is stacking still not a feature either?
In case the definition of a virtual copy isn't clear - what I mean is a copy of a photo that doesn't exist physically exept in the database - one that i would be able to apply any of the process commands to.
Michael Presley
Member
Hi Michael,
Short answer, No and No.
Stacking has been asked for many times, but not implemented, and you are the first person here, I think ,that has asked about virtual copy.
Thanks for the answer - that's to bad, I use both of those features a great deal in LR. I'm finding a lot to like in the process module of ACDSee, I've even configured ACDSee as an external editor in LR - after ACDSee opens the duplicated file (created in LR) I do whatever edits I like and then issue a save-as command and overwright the original file (so it will show up in LR), stacked with the original - the process work pretty well.
John Radcliffe
Member
I'm not sure that I'm answering your question, or just talking at cross-purposes, but . . .
When you "Develop" a Jpeg image, Pro3 generates a "physical" output file (i.e. it actually exists on your computer, and can be seen by other applications), but it also produces a data file that records what you did. Then if you choose to "Develop" the same image again, Pro3 will reload the original image and reapply your previous settings, so that you can change them.
Michael Presley
Member
I'm not sure that I'm answering your question, or just talking at cross-purposes, but . . .
When you "Develop" a Jpeg image, Pro3 generates a "physical" output file (i.e. it actually exists on your computer, and can be seen by other applications), but it also produces a data file that records what you did. Then if you choose to "Develop" the same image again, Pro3 will reload the original image and reapply your previous settings, so that you can change them.
Yes I think I understand what ACDSee is calling "non-destructive" editing. The virtual copies I'm referring to is a feature of Lightroom and the new (yet to be released) Bibble 5. In both of those apps there is no physical copy made when you create a 'virtual copy', it only exists in the database but it is displayed on you screen - you can have any number of virtual copies of a file (any format supported by the software) and can then apply any and all developement tools available to these virtual copies - in other words - I can have a black & white, sepia, cross processed, softened, vivid, or whatever version of the same file - all visible in the catalog - but only one file actually exists on your harddrive. All of these 'virtual copies' can be reapeatedly and independantly edited, changed in anyway the software would be able to change the 'real' version. You can then export any/all of these to a 'real' jpeg/tiff file. This is a very powerful and useful feature that I wished ACDSee would add.
tibu
Focus Group
If virtual copies became part of ACDSee, I would want to have it as an option to turn of and off at the image leve. One thing I really like about the way things are working now is I can drag and drop from ACDSee to my onlinle gallery upload facility.
This drag and drop is convenient and qucik without having to export everything first and applying the changes. I upload alot of images to share and would be dissapointed if I had to go through an export process for all of them.
I also personally really like that the image that you see and can drag and drop is the version that already has changes applied to the file, but the non-destructive version is still available for further editing, as is the original for archiving.
Anyway, for my workflow I would like the option of 'virtual copies" as long as it was something I could turn on or off at the image level.
Michael Presley
Member
If virtual copies became part of ACDSee, I would want to have it as an option to turn of and off at the image leve. One thing I really like about the way things are working now is I can drag and drop from ACDSee to my onlinle gallery upload facility.
The operation of other packages is that a virtual copy is something you have to create - it is not something that is automatically done - the original is always available and to remove a virtual copy is nothing more than to select it/them and choose delete - the database definition is then simply deleted. I don't really see this being an option in ACDSee, especially with jpegs, with the way the 'non-destructive editing' has been implimented - that being with the original file moved from it's original location (a 'feature' that I really don't like) and a copy being displayed in it's place.
Chippy
Moderator
Michael,
I just re-installed LR, and having never used the VC feature,I can see where it is a nice thing to have.Hopefully, the devs will read this thread, and, probably not in V3, but we can hope for V4. :-))
Michael Presley
Member
Michael,
I just re-installed LR, and having never used the VC feature,I can see where it is a nice thing to have.Hopefully, the devs will read this thread, and, probably not in V3, but we can hope for V4. :-))
Most of the time I've spent in front of my PC has been using the current software available and eagerly awaiting the next version - it gives us something to look forward to, doesn't it?
The thing you have to always remember in LR is that virtual copies only exist in the database - until you export - so protecting the database is extremely important. I've rebuilt my work enviornment several times since adopting LR and restoring the database from the backup location (one file) puts all the collections and virtual copies right back into place - LR uses xml files to store the develop settings for RAW file formats (or writes them into the jpeg).
John Radcliffe
Member
The thing you have to always remember in LR is that virtual copies only exist in the database - until you export - so protecting the database is extremely important.
That's the concern I would have if ACDSee did implement virtual copies. Over the 4+ years I've been using ACDSee I've had database problems more than once. That's why I like having my captioning and categorisation data saved in my image files, and why I'd hate to lose all my edits down to some database corruption (or user error).
But, as always, opinions will differ.
But one thing I would like that Pro3's method doesn't currently allow is to be able to have multiple "developed" versions without having to duplicate the original. So perhaps instead of having the same name as the original, perhaps the developed version could have a "version suffix", with all such versions based on the same underlying original. Having it based on filename would allow the user to rename or move files without losing the link. (E.g. the two "developed" versions Test1234a and Test1234b would both relate to the same original Test1234.)
Michael Presley
Member
That's the concern I would have if ACDSee did implement virtual copies. Over the 4+ years I've been using ACDSee I've had database problems more than once. That's why I like having my captioning and categorisation data saved in my image files, and why I'd hate to lose all my edits down to some database corruption (or user error).
But, as always, opinions will differ.
Yes, a stable db would be very important - is very important - I know my experiance isn't universal and maybe I've just been lucky - but I've never had either product (LR or ACDSee) loose it's database - I currently manage around 18,000 images in LR.
Marc Sabatella
Moderator
Good point about versioning/stacking facilities locking into the db a bit more than some of us are now, where all metadata I use can be stored within the file in a way that would accessible to the outside world. So I would want any implementation of these facilities to be configurable so I could make sure any different versions / virtual copies of a file were named in a way I could deal with. My preference would probably be for appending a letter/number code of my choice after the filename, so that related copies of a file all had the same base filename, but with letter appended to indicate the purpsoe of the versions. Which is to say, exactly what I do now, but with ACDSee *knowing* these files files were related so I could perform operations on all at once, etc. I'm sure others would want the specifics to be different, hence the thought that this behavior needs to be customizable.
strudelm
Member
"Stacking has been asked for many times, but not implemented..."
I'm extremely sad to hear that - that's the features I'm waiting so for long time and many versions... I can't understand why it isn't implemented - that the tool that helps to sort pictures so much, as well for first rough sorting after import as for sorting versions: all versions of an original are stacked together.
What about the feature to mark pictures with a colour band (like Lightroom and Brigde offers)?
Michael Presley
Member
My preference would probably be for appending a letter/number code of my choice after the filename, so that related copies of a file all had the same base filename, but with letter appended to indicate the purpsoe of the versions. Which is to say, exactly what I do now, but with ACDSee *knowing* these files files were related so I could perform operations on all at once, etc. I'm sure others would want the specifics to be different, hence the thought that this behavior needs to be customizable.
LR's approach is to assign the same file name - but there is a "copy name" field that you can use. LR is aware of the relationship and indicates so with 1 of x, 2 of x.... overlay on the thumbnails. They do not have to be stacked but can be if so desired. Operations are independant or universal if you select more than one. There are no functional differences between the 'real' version and the 'virtual' versions.
samn
Focus Group
I used stacking in Elements several years ago before moving on to ACD Pro. In Elements I had mixed feelings about their usefullness. It seemed a good way to loose both wanted and unwanted images, never seeing them to dispose of or to do something with. On the other hand it made looking at overviews of a persons work easier.
Now with more and more images being taken of events I could truly see some type of hybird being developed simular to stacks. Maybe someting like stacks of images only in the image well. Under any other view, search, catagory, keywords, etc. they would show expanded.
Michael Presley
Member
I used stacking in Elements several years ago before moving on to ACD Pro. In Elements I had mixed feelings about their usefullness. It seemed a good way to loose both wanted and unwanted images, never seeing them to dispose of or to do something with. On the other hand it made looking at overviews of a persons work easier.
My primary use for stacks is the occassional HDR/enblended or pano image - I'll stack the final product on top of the building block images - I always felt Elements had a lot of problems with the database and never adopted it.
samn
Focus Group
I always felt Elements had a lot of problems with the database and never adopted it.
Elements certainly did, probably still does. But, I can see stacks use as you describe, but even much further for the professional who shoots many frames of a wedding or of product or on location. Family photographs are now not just one or two of John Doe's Graduation but 50 or 100. The category lists just keep getting longer. The folder pane keeps expanding. Keywords keep getting more involved and the list longer.
There should be some way to choose, such as "show stacks" or "show unstacked" when you open a catagory, the image well, keywords, however you work your database. Scrolling through 500 photo's of Jane's Wedding when you open the category of Jane and Joe's family photo's category is a PITA. Of course we can always add a sub, sub, category, under the sub catagory under "Family" of "Jane and Joe's Family Photos. That of course does not preserve the contunity of the history of Jane and Joe's relationship in the family for the viewer, does it.
Michael Presley
Member
There should be some way to choose, such as "show stacks" or "show unstacked" when you open a catagory, the image well, keywords, however you work your database. Scrolling through 500 photo's of Jane's Wedding when you open the category of Jane and Joe's family photo's category is a PITA. Of course we can always add a sub, sub, category, under the sub catagory under "Family" of "Jane and Joe's Family Photos. That of course does not preserve the contunity of the history of Jane and Joe's relationship in the family for the viewer, does it.
The model of stacking that I'm basing my request on is from Lightroom - that implimentation allows for the expansion of a stack (that leaves the stack visually expanded but the stack relationship is still maintained), the ability to right click on an image in the expanded stack and move it to the top, to collapse the stack, or to unstack the images. I'm guessing that the biggest obstacle is the fundamental difference between ACDSee and LR - that is the database. LR connects the database to the file structure but it is a managed connection - there is no file browser - only files that are imported into the db (which BTW is much more robust than the Elements version - and the stupid way that Elements would just completely ignore any files it deemed as duplicates is now fixed and configurable).
Marc Sabatella
Moderator
FWIW, I can totally see the utility of user-controllable stacks (automatically generated ones based on thigns like combining pictures taken within a specified time period do *not* apeal to me). However, for those new to ACDSee wondering how you manage all these images without that feature, I'd just mntion that Ratings is my primary method. I basically give a 3 or 4 to the image of each "stack" of related images I like the best, and view my images sorted on rating most of the time, so the 3'4 and 4's are all together. That way the images that would otherwise have hidden in the stacks are out of my view too, because they are at the top of the file list whereas I'm looking mostly at the bottom due to the sorting.
So while I too wold love to see stacks (although I'd be much *more* excited by true version control), I did at least want to point out how ACDSee as is can be used to reasonably good effect as is.
samn
Focus Group
I basically give a 3 or 4 to the image of each "stack" of related images I like the best, and view my images sorted on rating most of the time, so the 3'4 and 4's are all together.
I'm sorry Marc, I don't see the logic here. So you do 3 weddings @ 500 photos each. Out of that the 3's and 4's = 15 to 25% of total shots. So you end up by choosing 3&4 ratings, still having to scroll through approx. 500 photo's, plus whatever other 3&4's are in your database. I realize that you can sort again by different criteria. But that is just an added step. Stacks and Versions could significantly reduce sort times for the user.
As I said before one can continue to add more and more sort criteria, but why? Lightroom is using this tech. because thier users want it.
Marc Sabatella
Moderator
I basically give a 3 or 4 to the image of each "stack" of related images I like the best, and view my images sorted on rating most of the time, so the 3'4 and 4's are all together.
I'm sorry Marc, I don't see the logic here. So you do 3 weddings @ 500 photos each. Out of that the 3's and 4's = 15 to 25% of total shots. So you end up by choosing 3&4 ratings, still having to scroll through approx. 500 photo's, plus whatever other 3&4's are in your database.
First of all, no, other 3's and 4's from the db don't enter into this. I'm talking about *while looking at just the images from one given wedding*, sorting that display by rating (I have the keybaord shortcut "`", right next to the "1" key on my keyboard, customized to do this). That way, only the 500 images *for that wedding* are displayed at all, and the 20% I've identified as 3's and 4's are at one end of that list. So I completely ignore the rest of the list and just look at those 100 images for the most part. Sometimes, I even temporarily "tag" them with the little checkmark and then filter on tagged, so I'm literally seeing only the 3's and 4's.
And I'm assuming that I'm giving 3's and 4's to the same images you would have put on the tops of the stacks - that is, if I'm giving out 100 3's and 4's, you're creating 100 stacks from that same wedding. So you'd be looking at a list of 100 stacks. If you're telling me you'd actually be creating fewer stacks, then I'd respond that I'd give out fewer 3's and 4's. No matter how you count it, it hould work that we both see exactly the same thin on our screens: "X" number of images from the shoot that we wish to see, with the rest basically invisible to us until we want to see them again.
It's still not *exactly* the same, of course. With stacks, it is easy (I assume) to perform operations on all images from a given stack at once - to assign them a keyword, to alter their white balance, etc. So I actually do all my keywording and so forth with the images sorted normally (by date/time taken), to ake advantage of the fact that there are likely to be similar images that are adjacent. Then I resort on rating and concentrate further efforts (RAW processing and so forth) on just the 3's and 4's). Sometimes, I then resort normally and copy the RAW processing from some of my 3's and 4's to the adjacent 1's and 2's. But more typically, I don't bother doing that unless someone specifically asks to see more of my images than the ones I have assigned 3s and 4s to - which, if I were shooting professionally, would be the ones I'd be delivering by default.
I realize that you can sort again by different criteria. But that is just an added step. Stacks and Versions could significantly reduce sort times for the user.
Absolutely, and I wholehertedly support the request to see these featuees added some day (although I personally have far mor interest in version control than in stacks). I was just hoping to explain how one can use ACDSee as it is, for the benefit people of folks who are accustomed to a "stack" model and don't know where to begin with ACDSee.
Subscribe to this topic via RSS
You must log in to post.
