put variants into separate albums
As I see, this had been requested since at least 7 years.
Please, captureOne, implement a simple "drag-n-drop" feature to add a specific variant to an album (instead of the entire fleet of variants, which can't be labeled and thus are not easily distinguishable)
Use cases:
- Albums with black and white versions of some photos (remember this means also fake B/W with just minimal saturation, so no smart filtering possible)
- Albums to group photo variants with special grading styles, i.e. "warm tone", "cross developed", "out-of-camera", "flat"
- Albums to collect "cropping variants" for a special project
(for the record, it's 2022)
-
Smart filtering and albums simply rely on data - as do Folders and everything else in computers.
You could achieve all of the above list with consistent use of metadata fields and/or keywords at the Variant level. You could even do B/W combined with "warm tone" and a "crop variant".
It is available today and has been for some years.
-1 -
Yes I really appreciate your help but I already know that I can more or less "achieve" this functionality with a metadata/smart-album workaround but my feature request was to implement a more "native" way by using a new, hot UI buzzword feature called "drag'n'drop"
I mean, maybe I'm spoiled by all the other ways you can drag photos into folders or bins. ;)
Off topic:
I hope Capture One does not push me even further to reconsider their yearly perpetual license vs adobes hateful Lightroom sub as I already have trouble getting all my Lr Catalogs over to C1 in the first place; (that's € 11.99 x 12 = €144 adobe vs. € 219 captureone)...I still love layers, though...
0 -
Capture One really is lacking when it comes to file management, organizing and searching. This particular improvement has been requested many times before, a few examples:
Organize Images and Variants independently
Add one variant to an album without automatically adding all other variants
Rethink Variant / Single Varian in Albums (Ablum specific preferred variants)
1 -
@SFA
What you are describing is a workaround.Workarounds are not intuitive, require extra work, and are therefore not an adequate substitute for proper support in the first place.
1 -
Class A,
In data processing terms it is not a work around.
Maybe the real need is to consider the process requirements.
The original file is the source of data. Ideally one only uses one copy of it for simplicity of organisation and space saving reasons. As a secondary consideration if we are likely to produce variants for OUPUT based on the source file and some common edits followed by some OUTPUT requirement specific edits we may need to consider at what point the need for separation (by name or "folder" does not really matter at this point) is particularly important.
At that stage we need to identify whether it is likely, in our workflow, that we will frequently return to the original image and its edits to make changes. Or is it the final Output file that needs to be clearly named and saved as a new and independent entity?
How many variations and combinations of variations are we likely to need? How often will we want to find them? How will we be using them?
Will we need to give the variants their own names and yet still link back to the original file or not?
If we think of an "Album" as an old school book of prints, each book serving its own purpose, then we are dealing with Output files and most likely need multiple "books" to group the combinations we need.
The same would be true of traditional filing cabinets for documents and the need for multiple draws and multiple folders using multiple copies of documents if instant grouping by type and purpose is required for discovery.
Relational databases are supposed to eliminate such duplication.
However, the consumption of photographic output will always be more akin to the "Book of Images" method than a database search for the time being, whether physical prints (or the files that can be used to make physical prints) or digital files for slide shows are the consumer's favoured medium.
In both cases, assuming one does not want to reprocess the files to output each time they are required, the file will have been created and stored somewhere. This means the variant will have been processed to output. It has an existence of its own. You can call it what you like and, hopefully, populate its metadata with enough information to allow it to be searchable so it can be regrouped with others with the same sort of content. Even the other variations that were produced from the same source file.
Of course, if that metadata has been added during the development process the same searches will identify the same variants. So the task, performed well once, becomes useful for multiple purposes, requires less data storage space and simplifies administration and housekeeping of the systems involved.
Individually we can choose which approach to take based on our personal preferences and comfort zone about using database concepts versus traditional "physical" filing cabinets, drawers and human-ready contents.
-1 -
@SFA
I have no problem to getting all technical about relational databases, etc. but at the end of the day the request (which indeed has turned up multiple times in the past) is about a simple usability issue.
Consider a C1 folder containing all the images of a shoot. It makes sense to have multiple perspectives on the same set of images, e.g., there might albums capturing
- personal favourites
- the client's favourites
- the editor's selects
- etc.
Each of these albums captures a specific subset of the images which can be arranged in an album-specific order, have album-specific ratings, etc.
This is supported by C1 in general, but matters become complicated when variants are involved. One can individually add images to albums but if the image happens to be a variant, all its variant siblings are dragged along, whether one wants it or not. For instance, if you want to add "image-1" to your "personal favourites" but not "image-2" you can in general, but only if those are not variants of each other.
It does not matter that "image-1" (e.g., a full body shot in colour) may look very different to "image-2" (e.g., a heavily processed crop of "image-1" showing a headshot in B&W) to the point that they might have been different photographs to begin with. The fact that they are (under the hood) sharing the same RAW data, prevents them from being added to albums on their own; they are always joined at the hip, like conjoined twins.
Now, of course there are workarounds. For instance, one can copy the file "image-1" is based on and base the processing of "image-2" on the copy of the file. Voilà, now one can add the images to separate albums on an individual basis. There are other workarounds, involving using star ratings, colour ratings, keywords, etc.
Note however, that
- one did not have to involve any of these workarounds (e.g., adding keywords) when the images are based on different files.
- all these workarounds have at least one disadvantage.
Any software that does not allow one to treat "image-1" and "image-2" the same way, regardless whether some data sharing optimisation occurs under the hood, creates a technical barrier to an intuitive, friction-free usage.
2 -
I appreciate every helpful workaround, although everyone should judge for themselves if it is practical/usable in their specific workflow.
at the end of the day the request ... is about a simple usability issue.
And my request was: "well I really wish this was more usable!"
0 -
It´s a pitty that this request dosn´t get realized. It would be so helpful. Some mentioned workarounds by using keywords, color filters etc. are not realy helpful nor practical. It´s always a lot of additional work. And even if you think physical on an album you will have one variant in there and not the whole flow.
Georg Bieber
2 -
I agree this keyword-smart folder workaround is complicated and could be done easier. Specially nowadays I need square variants for instagram, bw for prints and colour variants for press.
If Phase One would include "stacks” and only show the selected varians on top of the stack, like in Aperture and Lightroom, management and culling could be done much easier.
0 -
If enough users want to work with albums containing only specific variants, instead of all, I have nothing against such a feature, if it is configurable.
Each to his own, and if users want to work with static albums they should continue to do so.
In my opinion this is oldschool and has more disadvantages then advantages (working with static albums as such, regardless of the possibility to hold only selected vs. all variants). As SFA has pointed out already, when you classify your variants e.g. with keywords, i.e. tagging your variants, this tag survives when you export a variant to a file (jpg etc.).
Using tags doesn't lock you in (into C1), but static assignments to albums do.
And it can be used in your todays smart albums and also in your future smart albums (saved filters) which you don't even know about today. You can combine keyword and other metadata in these filters which you can't do if this information is only stored in the assignment of a variant to an album.Keywords and smart albums are much more flexible and reusable, and the effort to assign a keyword is roughly equal (in my book even less) compared to the effort to drag & drop a variant to an album.
Also, when I search in All images to find a subset of my images and see an variant (e.g. B&W) which I want to create another variant for (e.g. a square crop) then all I need to do is to select the image, press F8 (clone variant), do my changes and only add the keyword "square", and I'm done.
I would have to drag&drop it to album Square and B&W if I would work with static albums instead
...EDIT: and assuming albums were variant-specific and album assignments would not be part of the cloning (which I hope would not).If I have a static album "Wife" and another called B&W, how do I find black and white images of my wife if I don't use keywords? But if I use keywords anyway, then smart albums are close to free from additional effort.
This having said there are situations where static albums might be better suited, e.g. for closed projects which should not grow when you create new e.g. B&W variant, but you can either use a keyword for this project and use is in the smart album, or use the concept of "project" in C1 which limits the scope of the smart albums it contains, though the latter I find a bit intimidating.
I am using smart albums 95% of the time, I find it the superior concept overall, if I had to choose between only static albums (even if variant based) and smart albums I would definitely opt for the latter. Calling this a workaround is not adequate in my view.
This post is not arguing against this feature request, it is a speech for using keywords and smart albums.
-1 -
Enabling individual variants in separate albums doesn't prevent anyone from using the keyword workaround/method they're currently using. As is already clear, there are numerous reasons why users may prefer being able to add individual variants to an album, and it seems a little unnecessary to try to convince them that they should really prefer using keywords, even if that's what you prefer.
2 -
Your post actually is more unnecessary then mine, as it adds no additional ideas nor any background of how you work and why. To discredit my contribution is neither nice nor of any value.
And in case you did not read I repeat myself: My post was NOT arguing against this feature request!
0 -
This is the place to discuss feature requests.
... and not to discuss how valuable or invaluable fellow's posts are!
0 -
I'm aware that you wrote that. Your comment nevertheless comes across as trying to convince other users that smart albums are preferable. No one is arguing against the advantages of smart albums, only for the ability to be able to manage variants individually.
[Addition:]
Similar requests have been made by other users several times before, and every time someone shows up to tell them that keywords/smart albums are much better etc. Yours seemed to place itself in this category of comments, which is what I reacted to. I'm sorry if that came across as an overreaction.
1 -
As BeO said, using keywords doesn't lock you in – after a few years and many bad experiences with discontinued DAW / RAW software, I try to keep everything as open as possible – I even started using XMP files. My never listened wish for the discontinued Media Pro were smart folders… Anyway, I'm lazy and wish we got a faster, simpler way to organise several variants too. This more fixed approach with "normal” folders for variants would be better for me. To have an option would be nice.
0 -
Regardless whether users prefer "smart" or static albums, there should not be a difference between standard images and image variants. Even if someone only uses static albums 5% of the time, they should not be hindered by the current approach to variants.
For the product designer, there is an important question to answer:
If variants are stuck together by design -- perhaps the idea is that one should never lose sight of the fact that the members of certain image subsets are variants of each other -- then should it be possible to separate them at all (by using approaches involving metadata and "smart" albums)?
It seems to me that if separating variants from each other is supported at all, the straightforward way of separating them through the use of static albums should be supported as well.In my view, static albums have their place. Of course one could emulate them by using metadata and "smart" albums, but AFAIC, static albums not only provide a more intuitive and convenient way of establishing certain collections, they also do it in a more robust way (accidental additions are not as easily possible) and in a more efficient manner (their contents do not need to be computed).
1 -
Your comment nevertheless comes across as trying to convince other users that smart albums are preferable
You nailed it Thomas, but I can't see what's wrong with such comments.
I don't know everyone in person here, not to speak those readers which did not comment, so I don't know if everyone is aware of the different aspects, hence discussing advantages but also disadvantages of a not yet existing feature is a valuable thing, everyone can then can make an informed decision in which cases to use the one and in which cases to use the other approach, in case this feature would be implemented. And this is not to say that I know more and than anybody else here, nor do I know all aspects.
I use static albums too, and I'm not against this feature, I might be using it too, even if it is only for temporary selection of those images I wish to categorize when browsing through my collections, in order to add a keyword to them all at once when I'm done with selecting, in case that turned out to be more convenient.
I would like to add the idea of an easy way (e.g. button like "Edit selected") to toggle the content of static albums (and maybe even smart albums) with regards which variants to show, i.e. only the variants actually in that album vs. all variants of the image this variant is representing. And the whole stack of image derivates, would such a stack ever be implemented. Then one would have an easy overview which variants exist (or don't exist) and an easy access to them when you are in an album.
Phrank, I'm with you regarding xmp, but I wish the keywords and other metadata of all variants could be made available either in the same xmp file (as it is the case in the .cos files) or as separate xmp files. Currently only the first variants metadata is saved to xmp.
ClassA, the contents of a static album has to be "computed" as well, i.e. retrieved from the sqlite database, and the relationship to albums has to be stored there, if that is actually more efficient I don't know.
0 -
"I can't see what's wrong with such comments"
Static albums and smart albums are two different things with each their advantages. Claiming that one is better than the other makes about as much sense as saying that colour tags are better than ratings.
I basically don't see why you should have to create unnecessary keywords as well as define smart albums to be able to do something as simple as add individual variants to an album. The handling of variants is bad enough as it is given that you're unable to name individual variants in a way that will allow you to tell them apart in the browser.
And, as mentioned above, every time a user has requested that a limitation of Capture One is addressed, other users typically show up to defend this limitation tooth and nail (luckily, it's not as bad now as it was a couple of years ago when I started using Capture One), telling them that everything is much preferable as it is.
1 -
... define smart albums to be able to do something as simple as add individual variants to an album.
Yes, as been said many times, it's about usability:
one simple mouse-drag
-vs-
assigning additional keywords + opening a dialog-box and defining criteria.Whether the "architecture of the CO database" (dis-)allows a simple implementation of this feature is not my business. I'm here to pay for software and using it for my job and hobby – expecting a base-level of functionality or some parity with the competitor's offerings (e.g. Lr) to retain a productive workflow.
Achieving this goal should also be in the interest of the CO product manager who wants to "positively affect my purchase decisions".
2 -
@BeO
You wrote "...the contents of a static album has to be "computed" as well,...".
There is a difference between simple retrieval (accessing some static information) and dynamically computing results.
There are various ways in which "smart" albums can be implemented, some being very inefficient. Even in the most efficient implementations any time the metadata of an image is changed, it may enter or leave multiple smart albums. A good implementation will keep the respective overhead to a minimum, but still there are definitely computations to made (filters to be executed) and the more "smart" albums there are and the more complex the filters, the more it will they will cost.
FWIW, I feel it is OK to contribute to a feature request by spelling out what the potential advantages of alternative approaches are. In this instance, though, in my view, "smart" albums are a tedious workaround for what should be a very simple operation.
I hope it is clear to everyone that you are definitely not one of those evangelists who defend the product they use against almost any suggestion to change it.1 -
ClassA,
I hope it is clear to everyone that you are definitely not one of those evangelists who defend the product they use against almost any suggestion to change it.
Those opinions should respected too. But indeed it should be clear for everyone who is following threads in this forum (and I admit I have feature requests open too :-).
Back to the topic.
Performance
Yes, an indexed relation table (static album<>variant) is probably faster to implement and faster during runtime than keyword searches, if keywords are stored in a big string field.Unless the database would have an indexed keyword<>variant relation table at least for those keywords used by smart albums. The direct equivalent of a static album is a smart album with a very simple filter, i.e. the keyword equals one word (e.g. the album name) and nothing else.
Functionality
I can even imagine a "clever static album" which you can drag&drop variants to, this would result in a static relationship (this is the request here, variants in albums) and optionally (if you have configured so) the drop action adds specific user-configured keywords to the variants, or even complete metadata presets. Thus, by a simple drag&drop action of variants to such a clever (but static) album, you could do a bigger part of your image organization (namely adding metadata).0 -
" A good implementation will keep the respective overhead to a minimum, but still there are definitely computations to made (filters to be executed) and the more "smart" albums there are and the more complex the filters, the more it will they will cost."
Smart albums do appear to be heavy on resources. When creating smart albums, it often takes a while for the text I've typed in a search criteria text field to appear, and it only does so slowly, one letter at a time. (This is on a MacBook Pro M1 Max 64 GB.)
Another thing that makes keyword based smart albums more bothersome to use is that 2nd (and 3rd etc.) level keywords need to be preceded by parent keywords ("1st level keyword|2nd level keyword|etc.").
And for this part: "I hope it is clear to everyone that [BeO is] definitely not one of those evangelists who defend the product they use against almost any suggestion to change it" – I agree.
0 -
Maybe have a look from this point of view.
The fexibility shown using keywords, tags etc is understandable.
One point from my view is:
I created already a collection (album) at a certain time.
Some of these pictures I like to use for other project(s), some time later.
I add some variants. From this point on my collections gets changed
dynamically. Means for me, my previous collections are not the same anymore and
I cannot count on a stable "workflow".
This might be a pitty, with additional unwanted effort to check it out in case.
Even if you are using some keywords, lets say e.g. diashow which could be used
in more than one collections. Looks to me I need to establish a ceratin structure
on keywords? This doesn't make it simple and easy.1 -
"One point from my view is:
I created already a collection (album) at a certain time. Some of these pictures I like to use for other project(s), some time later. I add some variants. From this point on my collections gets changed dynamically. Means for me, my previous collections are not the same anymore and I cannot count on a stable "workflow"."Good point.
0 -
@Thomas Kyhn. You are totally right. I got the same issue. Not to mention, If you also shoot JPG+RAW, you will end up with a mishmash collection, which only can be controlled a bit by smart folders.
So I guess we need maybe stacks like in Aperture and Lightroom, where you can decide what's on top to view in each collection, if you can't place a single variant in a collection.
0
Post is closed for comments.
Comments
25 comments