Assign different names to cloned variants
Would be nice, to my opinion, to be able to rename cloned variants with different text e.g. for describing changes applied
For the moment, if I am not mistaken, changing the name of one is reflected in all the other cloned variants.
-
Long standing wish from many users.
> "...changing the name of one is reflected in all the other cloned variants"
I assume "changing the name" means "changing the image source filename". Variants are based on (sourced by) the same image file. As far as I know, images in C1 do not have a name other than the image source filename. Variants are assigned a variant number (1,2,3,...)
0 -
Yes indeed?
When I clone a variant, and edit its name in the Browser (under the image), it changes the name of all other variants the same way.
1 -
Claude,
You can do that for output - which has relevance since the changes HAVE been applied.
To do something like that within the application would, in effect, require a new date field for some form of substitute name whilst still retaining links throughout the database and that could easily start to be messy as well as adding a lot of conversion processing to an update at some point and thus backwards compatibility issues to consider. Not impossible of course but perhaps not something to do without serious consideration or possibly in conjunction with some other changes for additional benefits from the work.
On the other hand there are a number of IPTC text fields already available and probably underused by most C1 users. Maybe one of those could be utilised as a proxy name field for an alternate name if that would be easier to introduce.
The issue then would be making if readily available for editing and selection and searching purposes - presumably throughout the application. That, potentially, is quite a lot of work and added complication for the UI. It sounds simple but I would bet that there would end up being a lot more to it than one might think. It's just that kind of change.
So if the field is purely for information - there are text fields that could be used available now.
If it is for active management, sorting, selection, creating (smart) albums, etc., the whole concept should be considered in some detail. Free text may not be the best option. Can the naming rules be created by tokens? If so which tokens? Are there any requirements for categorisation codes a User controls for their purposes? If so are there already IPTC or Getty pre-defined fields that could be activated? Or introduced?
Of course, even the IPTC stuff is a moving target probably require a fully trained Media Librarian to have the experience to make best use of it. Or indeed any useful use of it.
Quite normal for "data".
0 -
I don't agree with you on this one.
You don't need to export/process the files to name it another way.
I can, for example, create 4 clones:- One with shadows +5
- One with contrats +2
- One with..
- One ...
Fiction examples of course.
But it would help me lot to find back the file where "this type" of edit was applied without having to check the tools or the IPTC.
Therefore, a simple naming like "pictureName version shadows + 5" would do the job without any extensive learning of DAM.
2 -
You can put that description into an IPTC Metadata field and use if for searching if that is what you wish to do.
That is possible today.
If you can be certain to keep the naming conventions consistent - i.e. "shadows +5" is always consistently typed (or copied) into the text - then it may well be possible to use that as a search term to create a Smart Album, for example, for all variants with "shadows +5" associated with them. Just not in the name in the browser or elsewhere on screen.
It could be made visible by using the Metadata tool alongside the browser.
However, my concern with concepts like that is that, having created the new name or a description or whatever, one then changes the value that it is describing but not the description/name and the whole idea becomes a mess.
Using a computer system should, in theory, allow consistency to be improved (perhaps "perfected" would be a better description but rarely achieved) by making use of the actual values applied (per your example) rather than rely on a separately maintained descriptive text.
Output naming potentially fixes the values being applied and so makes the name more meaningful and less prone to later introduction of errors - though over time the description might become meaningless in practical terms.
I'm not sure a potentially long list of adjustments applied makes sense for digitally processed images. Back in darkroom days recording the times of each step along the way was a wise decision (in fact necessary) to make film processing and print exposure a somewhat consistent process most of the time but I am less convinced that digital processing, given all the changes that can be made in seconds and endlessly revised, can make for a long and detailed list and even frequent situations where the base settings are altered by additional "layers" or just the effects of other tools, thus making the original "value" irrelevant out of context.
So the Automated computerised concept of "use the recorded values" sound sensible and obvious UNTIL one starts to consider what that really implies.
Maybe we are back to the human written text description that makes something what we went it to be rather than what it actually is according to the data!
-2 -
> "a simple naming like "pictureName version shadows + 5" would do the job..."
If you need the variant name for "search and find" only, then using a metadata field as suggested by SFA, should work.
Personally, I would welcome a variant name for the purpose of seeing it in the browser, below the thumbnail where C1 currently displays the name of the source image file. The variant number in the thumbnail's upper right corner, is ok for computer consumption, a name would be far better for a user like me.
I use Photo Mechanic a lot. The PM browser also displays the filename under the thumbnail image, but it also allows me add up to tree extra lines of information under each thumbnail. Information means anything from that image's metadata or static text. A variant name in C1 metadata would work for me if the C1 browser had said PM feature. But it doesn't.
2 -
« Personally, I would welcome a variant name for the purpose of seeing it in the browser, below the thumbnail where C1 currently displays the name of the source image file. The variant number in the thumbnail's upper right corner, is ok for computer consumption, a name would be far better for a user like me.«
Probably I expressed me in an unclear way, because this is exactly what I meant.
Thanks for helping sharing my ideas :-)
0 -
So if one could pick a metadata field - preferably an existing one to make development quicker - and have that available to display in the Browser (etc.?) as an alternative to the file name (given the possible constraints of the amount of text that can be displayed subject to zoom level), would that work?
0 -
Technically perhaps, but too elaborated I would say.
I personally would not use it.
I need a light and easily workable solution, not something that would increase the workflow0 -
In my view this request is highly related to this one --
-- about making variants first-class citizens.
As soon as variants are treated as images in their own right, it would be natural for them to have different names.
3 -
agreed
0 -
Plan B.
Copy the source file and rename it. Then you will have a variant with the name you require and that can live its own autonomous life.
Much easier than having to maintain another field, whether or not that field is an existing one or a new one created for the purpose
-1 -
>SFA: Copy the source file and rename it. Then you will have a variant
The copy will not be a C1 variant, which I believe is the subject matter here.
>SFA: Much easier than having to maintain another field, whether or not that field is an existing one or a new one created for the purpose
Hehe. Keep the shutter release button pressed for a burst of five seconds or so. One import and no need for that extra copy/rename cycle :-)
-1 -
This is a specific use case for why C1 needs to support snapshots. IT NEEDS TO SUPPORT SNAPSHOTS. Not having this is a HUGE failing. Right now I have a photo that I was asked to provide for publication and I want to ensure that version of the photo can be saved standalone. I still may need to change it for this specific publication if asked, but I don't want it to impact any other versions I might have. And trying to manage 'version1', 'version2', 'version3', of file xyz is just stupid. We're supposed to be able to give meaningful file names to files.
1 -
On output of the latest current "final" version you can give the image whatever name you like. Even if it makes it more difficult to trace it back to the original image should you need to in 5 or 10 years.
Each Capture One variant edit (Note that the term "variant" applies to all images, even those with only one edit instruction set) shares the same Out of Camera EXIF data but for every one of them the can be populated with entirely different edit instructions and supported IPTC data fields using the Metadata tool.
The IPTC section provided for "Content", for example, seems perfectly suited to the objective you have.
And it is an industry-wide standard - in so far as Standards are followed.
I have no familiarity with LR Snapshots having abandoned LR after V1.4 other than a quick assessment of V3.
But realistically, in computing terms, how one records data and resents it may look different and seem either familiar or unfamiliar depending on what one is used to but in effect it's all the same thing with data fields storing information in some way and application being able to use that information for their own purposes. File names are just identifier tags to a computer. Which section of a data record provide the "File Name" is not relevant so long as the program knows the rules. The benefit of the IPTC concept is that all compatible programs can make use of the data. (Always provided they deem to use it and follow the "standards".
Maybe allowing quick access to one of the existing IPTC fields would satisfy your needs?
Likewise with Output processing, the option to ensure that a traceback to the original file name and sources could be easily included might be beneficial for all of those times when we think that just maybe someone will discover some further interest in the file (with more changes required) at some future date. And that those changes require revisiting the original RAW (i.e. source) file.
0 -
If it requires the file be copied, this is dead easy to code so why won't Capture One do it. Add a 'New Named Variant' feature that copies the original file and gives it a new name, which the user can change. Even better, keep the history of the changes of the original variant. In other words copy the sidecar or whatever it uses to keep the history. Mind you I think history is lost whenever you close and reopen the app anyway, which is shite. This would actually be a very simple way to implement a snapshot.
0 -
> William Rosmus : Add a 'New Named Variant' feature that copies the original file and gives it a new name
I really hope for a smarter solution.
A variant is not an image file. It is one image file and any number of image variants based on that one file. The request, at least the way I understand it, that each variant could carry a user designated name. The variant name could be brought in at different places in a work flow. Processed to an output file like now, but perhaps more important: displayed on the monitor. One variant for "Uncle Tom", one variant for "Lisa's blog", one variant for "National Geographic " etc. All from a single (raw) image file. A variant is a data block in C1's database. Variants have computer desginated numbers, 1, 2, 3, 4... Some of us want user designated names as well.
1 -
A variant is not an image file, blah blah blah.... Yes, we've established that. It is why I said, "New Named Variant". NEW. In programming that means you are creating a new object. I used the term variant so that it could be used to imply that it is a copy of an existing file that can be edited independently of the original but it is obviously from an original. And you can rename it whatever you like. I'll guarantee it is very, very simple to copy a file programmatically. I'm a programmer, or was until I went into analysis and design. So I made this suggestion. Copy the original file. Give it all the ancillary files and database entries so that it can be edited without impacting the original. One of the attributes could very well be a reference to the original image; that also would be a relatively simple thing to do. And give the new file a new name. In terms of a solution this is a smart one. It achieves what people want in terms of enabling snapshots and allowing multiple versions of the same photo each with a unique name. I don't know why you would insist on just having the original file. It would be a much more complex use case to implement with very very little benefit. In fact no benefit as far as I could see. The only thing I would like to see is when copying the image, it brings over all the changes to date. And I'd also like them to fix the app so that the history is still there and available to go up and down after closing and reopening the app. AND when undoing and redoing it doesn't jump around images. Changing what image you are looking at as part of an undo operation is just retarded.
-1 -
+1 for naming variants. Without reading through the wall of text concering database management etc, I also would welcome the ability to identify certain variants quickly, without having to check the toolboxes in order to know which edits have been applied to them. It's interesting that we can give star ratings independently for each variant, but not any form of human readable ID. Meta fields aren't much less cumbersome than looking at toolboxes, in my opinion.
I have one base variant and another with adjustments for printing. If I now was to add another variant for web or whatever, it would quickly become confusing, and mistakes where I edit the wrong variant would become more likely.
1 -
Well, I see others are and have been asking this question. My turn. I am new to Capture One and I am trying to get my organizational structure worked out so I don't have to go back and redo it.
Here is my thought, and I am posting it to get feedback not to suggest it to others, I don't know Capture One well enough to make suggestions.
My approach would be (is going to be?) to add a keyword identifying the purpose of the variant, then I can add Smart Folders that filter all images for that keyword(s). Actually, a nested structure of keywords to select project, purpose, output, etc. Once the "master" is edited, I never touch it again and would work exclusively on variants, so I always start a variant at full resolution and no output sharpening. Each is reflected in its own smart folder with others of similar destination/purpose. So I have keywords identifying the project, output format, etc. for use in smart folders.
Suggestions on why this will not work, or ways it could get out of hand?
Kind of a PIA to restructure 10's of thousands of photos, so I would like to get it close to start with - LOL!0 -
Yeah, that's kind of what I do. I use tags (keywords) to indicate the purpose (output related), e.g. print_candidate, printed, printed_xyz (with xyz some details like paper or size), photobook_name, a tag for a "distribution channel" e.g. flickr, 500px, instagram etc. and I create filter collections (smart albums) for some of those keywords. Only if I want to classify the whole image with all its variants I create a static collection (album). If it is worth (or even possible) to retrospectively tag 10thousands of images is up to you or course...
0 -
I just upvoted this post (though it is not in the correct topic which should be "Feature request" because I think this is a helpful feature (at least in case you could show the requested field name in the browser). But the keyword approach is much more versatile, as you can assign multiple keywords to a variant, so this would not a either-or question for me.
0 -
I upvoted to. I'm eager to have this feature so that I can put the same photos in differents albums with differents settings.
For now, my workaround is to add a keyword to the variant to distinguish it from the original.
It seems that lot of C1's lacks can be overcome by using keywords.
0 -
Hi All :) Is this problem solved? Does anyone now how to change for different name from clone variant? Please PhaseOne help us :)
0 -
Still nothing! This is particularly useful when you have to export different ratios and crops of the same image, or different color options.
If in any case after retouching an image, you need to change something on it you just change those settings on one variant and they take effect in all of them and just export again without having to rename files individually every time.
1 -
Yeah still nothing. Which is why I haven't updated since v20 and won't. That and being unable to keep separate change history for the ability to undo and redo and not have the process go through changes including switching views when undoing, affecting changes in other images. And also losing change history when reopening the app. And then there's the not listening to customers. Why should I pay to support this? There hasn't been any changes that I care about, they just release new versions without anything functionally useful; it's just an excuse to generate more revenue. I'm not getting behind that.
1
Please sign in to leave a comment.
Comments
26 comments