History per image
At the moment undo is global, it is what you did, in a serial sense, from image to image
A localised undo/redo option that applies only to changes to the image you are working on would be a huge benefit
-
I asked for exaclty the same feature update however the way C1 handles variants seems to be set in stone.
>I got into the habit of creating a Variant
Yes, this works under 2 conditions:
1. You don't forget to create a variant.
2. You don't mind all the cluttered variants in your image browser (a workaround to this is to limit the images in the browser using the search filter at the top right). Since named variants do not exist (another bummer), you can only guess which variant refers to which editing state.
I can only assume that all this is no hindrance to professional photographer's workflows. For me as an amateur, the not-so-flexible handling of variants is a weakness of C1.
@...
I have read a few of your comments over the months and many of them can be reduced to users needing to adapt their workflow to the limitations of C1, instead of C1 having to remove those limitations. It just doesn't seem productive to keep spreading this ideology, especially in times of rising prices for the software.
1 -
As mentioned before when this discussion has come up, variants are something entirely different from a list/history of edits/changes/actions, and they cannot in any way replace such a list/history. Creating a new variant with every edit would result in a complete mess, not to mention the waste of hard drive space. And this method wouldn't necessarily supply the information that a list of edits would.
The only thing that could, at least in some ways, replace a list of edits would be a snapshot option like Lightroom's, which would enable you to save the settings of a photo at various stages of editing (basically a list of such saved stages), without resulting in any clutter or any wasted space.
In the unlikely case that anyone should find it useful to create a new variant with every edit, nothing would prevent them from doing so even if an overview of edits or a snapshot option were to be introduced.
2 -
Snapshots are not similar to variants. Variants are more or less similar to what in Lightroom is called a virtual copy. Variants and virtual copies have their own entry, so to speak, in a catalogue, and an individual preview file is created for each variant/virtual copy. As I wrote, snapshots are saved states in the editing process of a photo, or to be more precise: variant/virtual copy. Snapshots appear in a list so that you can jump between them to compare different settings and easily go back to a previous edit; they do not have their own entry in catalogues, neither do they have individual preview files, so they don't clutter up your catalogue, nor they take up space. If you want to see how they work, have a look at this briefe introduction for instance.
1 -
Capture One variants do have preview files, otherwise they wouldn't show up when image files are offline. And they do – as has been pointed out countless times – clutter up the catalogue. Variants are useful as variants, not as countless stages in the editing process of single instances of a photo.
And the fact that there's no way of naming individual variants in Capture One – so that the name shows up in the browser – makes variants an even worse alternative to snapshots.
I don't quite see the point to your insistence on variants as a replacement for both image history and snapshots. The advantages of the latter two have been pointed out by different other users – who have used these options and miss them in Capture One – again and again. There's a reason that Lightroom has all three – virtual copies (variants), snapshots and image history: they serve different purposes.
1 -
I just checked, and you're right that different variants rely on the same preview file.
Nevertheless, as I wrote above, the three functions, virtual copies/image history/snapshots, serve different purposes, and they're useful in each their way. There's no point in insisting otherwise, or in insinuating that it's just a perception other users stubbornly hold onto.
0 -
Even if the differences between variants, snapshots and image history had to do mainly with how versions of a photo are presented, that's no argument against their individual usefulness.
As for the usefulness of an images history overview, this should be self-explanatory – you can see exactly what you've done so far, and, if you want to go back to a specific step, you can easily do so. The usefulness of snapshots is, as mentioned above, that you can save different states of editing without having to create any new instances (variants/virtual copies), and thus without cluttering up the catalogue in any way, they simply appear in a list (cf. the introductory video linked to above). Using variants for this purpose would, as pointed out above, clutter up the catalogue with unnecessary instances of photos that you're unable to distinguish between because you cannot name them individually.
1 -
Now that variants in C1 can be treated as if they were regular images, i.e., now that it is possible to move a variant into an album without the related variants following it, C1 variants have become functionally equivalent to Lightroom's virtual copies.
Here are the characteristics that justify the existence of variants, snapshots, and edit histories:
Variant (virtual copy):
A variant is used to create an independent variant of an image, e.g., a B&W version. Such a variant is not a stepping stone in the development of an image (e.g., part of the evolution of a particular image), it defines its own editing history. In other words, variants are used to branch off different images from an existing image. Apart from the detail that they are based on the same RAW data, variants, in general, share nothing with each other.
Snapshot:
A snapshot captures the state of an image at a certain time in its editing evolution. Therefore, all snapshots of an image are strictly ordered. They are not meant to represent variants of the image since they cannot be independently assigned to albums, viewed at the same time, etc. As a result, snapshots are versions rather than variants. Snapshots are used to mark significant points in time in the editing history so that one can go back to them, use them as "before" versions in "before/after" comparisons, or branch off variants from them. Snapshots are not visible at the top level, they have to be selected from an edited image.Editing history:
An editing history chronicles the steps a user undertook to edit an image. The per-image editing history asked for by this feature request (which has been requested many times before) allows a user to undo editing choices without having to undo changes to other images that occurred between producing the unsuccessful editing steps and recognising that they weren't successful. Editing histories only implicitly represent (many) different versions of an image, i.e., unlike variants or snapshots they do not represent an image as such.In summary we have:
- Variant (virtual copy) = Variant, creating a branching point
- Snapshot = Version, i.e., part of a linear history (i.e., non-branching)
- Editing history = chronology of editing steps, i.e., not representing a single image at all
Due to the above, C1 variants are unsuitable to represent snapshots (snapshots are ordered and hidden by a certain image whereas C1 variants are independent and visible at the top level). C1 variants are furthermore unsuitable to replace editing histories because
- it would require clairvoyance to be able to create a variant every time one might want to fall back on a previous editing state.
- variants clutter up the top level whereas editing histories are private to individual images.
In closing, I hope the utility of an "undo" function is not disputed. Anyone who is capable of making a set of edits to an image that they can later improve upon by removing the set all together, and is capable of noticing that only after having worked on other images in-between (often the work on other images generates the insights necessary to rework the last editing operations on an older image) should see the utility of an image-based undo capability.
The useful by-products of an "Image Edit History" are just cherries on top, although I'd argue that only by having the ability to nominate a "before" image state from an editing history, the "before/after" tool makes any sense. Currently, this tool is mainly a marketing device to showcase the big differences one can create by a succession of C1 editing steps. It is absolutely useless to evaluate a set of recent editing steps.
FWIW, I'd take an image-based undo-capability even if it were just available per C1 working session, i.e., if image-based editing histories did not persist between shutting down C1 and opening it again.
3 -
@...
You mean well, but I have to agree with Noob with a Nikon's post. Although your posts can be interpreted as helping users to make do with what is available in the absence of the functionality they request, your posts typically come across as denying the validity of the feature request by
- pointing to existing C1 functionality that is supposedly able to cover the requested functionality, and
- explaining how the feature request would make things worse in your view.
In my experience, your criticism is often not justified because it targets a misrepresentation of the request. For instance, in this case, an image editing history would not -
Complicate the requirement by suggesting a need for perpetual and endless multi-branch "edit history" records
- as you've put it. On the contrary, variants are the tool to "multi-branch" whereas edit histories (e.g., those in Lightroom) are completely linear, i.e., non-branching.
You seem to take concerns such as "variants cluttering up the top level and/or having to be removed after one's work is finished" not seriously.
Perhaps your perception in this forum could be improved if you framed your criticism in the form of questions, e.g., "Have you tried to use XYZ instead?" or "Why is XYZ important to you?"?
It is hard enough to try to make any progress against the inertia and diverging interests of Capture One. It really can be frustrating if one has to fight fellow users on top of that. I do realise that criticism can help sharpen the formulation of a feature request, so criticism is in principle welcome, but it in my view it is more welcome if it is created with that spirit in mind and avoids coming across as refuting a request based on an incomplete understanding of the request.4 -
I work in software development where we have a tool called "Git", it is for version control. Which is exactly the kind of thing we are trying to do here, with images instead of code. Git allows a programmer to
1. Create a new branch (=variant)
2. Create a named tag (=snapshot)
3. Revert to any previous commit in the commit history (=the requested editing history)
And much more. Right now, C1 only offers us option 1, and I am surprised (really) that this seems to be enough for a professional level image editing software. You have to let this sink in: if I wanted to undo a change in the codebase of my pet sanctuary website, I would first have to undo all following changes in my T-Shirt ecommerce webshop. Seems ludicrous, but this is how C1's undo feature works currently.
If Git was to be reduced to only one of the 3 options above, there would be an outcry in the coding world.
3 -
Well put, Class A and Noob.
1 -
So how should the Git philosophy be applied to a photo editing tool where one might sit for some time experimenting with a slider in a tool, making what are in effect multiple changes that may eventually leave one value of the change as the new value to be "saved"?
I just thought about this today, because it *is* surely a challenge for any edit history (not sure how LR does it). One solution would be to only record 2 states:
1. The state the tool was in when the user started using it
2. The state the tool was in when the user switched to using another tool
That way, all the experimenting "in between" entering and leaving the tool would be insignificant.
If you are working with layers and decide that for one of the layers you wish to revert to a previous state for that layer but have undertaken a number of other changes in other layers since then, would it be acceptable to go back to the state of the image as it was back then or should the layer have its own individual history so that only that layer is changed (or t least the user has the option to choose whether to reset everything or only the layer).
It is a non-question - in my opinion - what a scoped undo button should do. I should undo the last edit made in the scope of the current image.
If you then ask me whether we need an edit history also, where we can undo specific changes in a chronological list, then I would say there is no difference. The undo functionality is merely a convenience wrapper around the edit history. It seems so obvious as to why this would be incredibly useful, and I am not sure why anyone would expend their energy on proving otherwise.
1 -
@SFA
Considering 1) that image history has been requested countless times before – which you are probably aware of as you've voiced your opposition on a number of such occasions already – and 2) that the three functions discussed above work fine in Lightroom and are found to be useful, also by users who have switched from Lightroom to Capture One, is there any good reason to think that this feature wouldn't be considered useful by a wide sample of Capture One users?
1 -
@SFA
There's also the possibility that missing features in Capture One sometimes really are missing features and not part of some grand underlying design concept.
2 -
@...
Before I changed to C1, I've been using Lightroom for three years.
I have never seen a version where one had to explicitly "commit" a change. Also, the per-image history in Lightroom was not "limited" in any way.With what granularity a per-image history will be recorded is a design question that has many useful answers (and must be addressed for the current global "undo" history as well).
We get that you don't need the feature. However, your only valid criticism has been to say that you don't need it. I don't need many features of C1 either, but I acknowledge that they are useful for others.
Anyone who never needs more than one attempt: Does not need undo at all.
Anyone who always recognises mistakes as they happen: Global undo will be fine.
Anyone who- makes suboptimal choices and only recognises them as such after having worked on other images, or
- likes to have a glance at edits that were made to an image (in full or condensed form), or
- finds a use for recording "snapshots" (versions) of the image evolution, or
- wants to select a past edit stage to choose it as the "before" state in a "before/after" comparison (to turn the "before/after" tool from a gimmick into something useful)
would very much welcome a per-image history.
If you can point out why what we want is wrong, or which solutions are better, or what existing functionality already addresses our needs (without workaround disadvantages) then please let us know. Repeating that you personally don't need it, is not necessary. Just downvote the request when it pops up again, but please consider not making multiple people respond to your posts time and again.2
Post is closed for comments.
Comments
14 comments