Move image to user collection/album, without variants!
I want to move pictures to an album, but only the selected variant and not all variants of the picture. Actually all variants of the image are always moved into the album.
Perhaps I have shifted something unconsciously, etc..
Do you have an idea what I am doing wrong?
Best
Mick
-
All of the variant edits are associated with the source image. They travel as one.
I think you may need to use the Smart Album concept to split different edits of the same image into separate albums.
Alternatively, if Smart Albums do not appeal to you, duplicating the original and applying the required variant edits to the new source file is an option.
And of course if you have finalised the edit you could simply produce the output file and use that for the album.
0 -
As other users have pointed out, this behaviour makes no sense and should be changed.
0 -
I can see the attraction of this idea, but I wouldn't like it to be implemented at the expense of stability of catalogs. A lot of users complain that Capture One catalogs are not very robust. (I find occasionally that it seems to lose folders.) I'd rather that they sorted out that sort of thing before adding another complexity to it. Would the database be able to keep track of variants in different albums without getting in a twist?
Ian
0 -
It does seem like such a basic thing though, and the current behaviour is both counterintuitive and inconvenient.
I see your point about the catalogue stability, and obviously a change to this behaviour shouldn't come at the expense of already limited stability. Rather, catalogue stability (and performance) issues ought themselves to be fixed as well.
0 -
Many thanks to all!
Now I know that it is so.
For me it is not acceptable like this! Also not in comparison to other providers. It is a dilettante implemented function and if C1 has problems with the IT/DB reliability, they should hire IT specialists for it.If I collect 100 pictures to put them in an album and then have 400 pictures in the album... A pity!
Mick
0 -
@Mick Inger
Why would you have 400 pictures in the album?
In many ways, since the concept of Relational Databases was introduced to computing, the older "Filing Cabinet" approach to gathering "documents" together has been obsolete. But we all cling on to it.
Back in the day of prints in albums this was not an issue. You wanted the same image, or a version of it in 4 separate albums you obtained 4 prints and 4 Albums and made things so. Doing so had the advantage of creating "backup" copies as well. The negative (or positive) used to crate the print would be stored, often not very well, and lost over time.
Now we have other ways of doing things. Whether they are better in the long term remains to be discovered. Perhaps not.
One could still create multiple albums, using multiple catalogues, if required.
Or a single catalogue (or session) and use Smart Albums.
All of that said it is probably more logical to think of making Albums from completed edits output to distribution of "print ready" (or screen ready, depending in purpose) saved locations.
0 -
Workarounds for this limitation – smart albums, multiple catalogues, etc. – are still just workarounds, and while they may be temporary solutions they don't eliminate the inconvenience of this behaviour. And it must be clear by now that to quite a few users this behaviour really is counterintuitive and inconvenient.
0 -
@SFA
there are new methods and they offer new, previously unknown possibilities. I am a computer scientist myself and I like it!
But if I mark 1 (one) picture to move it, then I want to get only one picture to move. It is that simple! ;)
Otherwise, when marking a picture, all would have to be highlighted, etc.
But let's leave that, it is as it is.
Mick
0 -
@Thomas Kyhn
This is exactly how it is...
Mick
0 -
@Mick Inger
Mick, if you are moving you are moving.
If you only want one version of that image but you have, say, 4 variants, then delete the other 3 that are not required.
It, on the other hand, you want to be able to keep the variants together for editing purposes but have specific variants in spefiic "hard coded" albums then you still need something like a Smart Album, albeit perhaps with most of the "Smart" functionality removed. So the edited variant you wish to include in a fixed album needs a field that can be used to uniquely identify it.
And an album process that need to only count that once for counting contents.
And a review of the file handling system to ensure that variants or indeed entire source images and their edits cannot be accidentally deleted or have the unique reference name changed by some other processing without the association with the Album being flagged up. Or at least one would guess that a regular album user would want to see that sort of control.
Actually the variant might appear in more than one album. Also, possibly, in more the one catalogue or session.
So that may mean that any maintenance activity needs to be entirely "global" for the installation.
For performance needs that could mean that each variant really needs to be able to support a list of albums and their host machines, catalogs/sessions and albums with which it is associated. The may be more of a requirement for sessions given the greater flexibility of use involved.
As a developer I would likely consider such possibilities as being so rare that they could be ignored.
As an implementer I have often found it enlightening that the "never likely situation" appears quite early after a development is rolled out or a new system is implemented. Not something to be ignored from a Customer Relationship point of view. Especially when the customer (if paying the bill for the development) indicates it will never happen and they won't pay for it.
But of course one never knows how the C1 team will approach the requests that have been made.
0 -
@SFA
With all respect, what you're doing appears to be merely deflecting from the actual issue. As Mick Inger pointed out above, when you select one variant and add it to an album, you expect the selected variant, not variants that you haven't selected, to be added to the album. That's all.
0 -
Thomas,
I understand that.
However the existing edit information of all variants is held in a single "file". Literally a file in the case of sessions. Something very similar if not identical in the case of catalogues.
More than one file if you include masks. There may be some other stuff as well if one digs deeper but these two will do for now.
In an Album, unlike a folder, one is not moving anything. One is creating a list of source files and the list is the album.
Smart folders create lists on the fly but the same "not moving anything" observation applies.
So the management of the contents of the Album is all based on being able to uniquely identify a specific variant if only one variant of several possible variants is ever to be accessible from a particular Album.
The reference to the location of the source file will stay the same. Likewise the Preview and Thumbnail files. They will, normally, be used just as they are with the edit information for the primary variant (i.e. the current Primary edit instruction set) applied to the preview and thumbnail UNLESS for some reason the display size is not well suited to using the default preview file, in which case things will be recalculated for the purpose of the Viewer window.
Unlike traditional "Photo Albums" full of prints (old school) or digital images (new school) the image in any component of a C1 catalog or session are still available for active editing. I would suggest that trying to treat a single section of a single file as something isolated entirely from other parts of the same file, whilst possible, given suitable section identification and edit locking controls, might not be ideal. Indeed there would be questions about design concepts. For example if editing a particular variant should be allowed ONLY as part of the some Album activity. Also, could the same variant be allowed in 2 separate albums? It would be currently but should that be the case?
If none of those matters is important to the use case then I can't see a conceptual problem related to deploying a "Smart" album based solution. The principle of using a data field or fields as a specific identifier to associate an edit variant with a specific album would be the same and it should, hopefully, be clear that any changes that might take the variant out of the Smart Album are at the risk of the Smart Album administrator.
Currently there is no obvious way to being able to select a single variant of a multi-variant image to allow just that variant to appear - other than by adding something to the variant edit instructions that would make it identifiable and extractable for display. Basically like a Smart album but with the Primary Source file "fixed" in the Album "Filing drawer" but with a filter to instantly select the specific variant or variants of the source image that currently relates to that album.
0 -
I assume the way it currently works is a compromise that has been made because of limitations in the way variants are referenced in the catalogue; as a design choice in itself it makes no sense. If this is the case – the catalogue structure preventing variants from being treated as individual instances – changing this behaviour probably isn't the low-hanging fruit it would seem to be right away. Nevertheless, with the catalogue instability mentioned above as well as performance issues in addition to these limitations in the handling of variants, it's something that needs to be changed.
0 -
Thomas,
The Session concept predates the introduction of catalogs by several versions.
Edits are recorded in a sidecar file for sessions and edits for all variants are held in a single file. Likewise the is a single thumbnail and a single preview file. Also Layer masks, but in a Mask sidecar file.
For compatibility the same concept is used for Catalogs.
Using separate files could get messy. I have used a s system previously that created separate files and embedded a jpg preview in each file but of course the storage required was greater then a single preview and a single edit container file. Not too bad if low res. previews are used but a lot of files to keep under control if one created multiple edits from the same source image. That application had no specific DAM functionality to consider. It also did not auto save all changes - so it was very easy to lose all edits if one did not save regularly.
The simple catch-all approach for this would be to identify an existing IPTC field (or introduce a new non-IPTC field) in which to store an Album Name (or maybe multiple names) in order to link a set of images to an album and then use the same entry as a filter to prick only the variant of interest.
This works in the current software if one uses an existing field for the IPTC fields offered and populates it for all variants to be selected and then applies the filter to the Album. It would also work for a Smart Album. And of course one could use a Smart Album selection as the basis for creating a "Fixed" album.
It should also work in both Session and Album workflows - convenient for those who use both.
0 -
As I wrote above, insofar as the current behaviour is the result of a limitation in the catalogue structure, it's understandable that it may not be easy to remedy. But as a design choice in itself it makes no sense at all. For those who prefer some form of workaround, this is of course fine, and I don't assume that such workarounds would stop working if Capture One became capable of handling variants as individual instances. Consequently, changing the current behaviour should come at no expense to those who prefer the current way of organizing their albums, but would be an advantage to those who request the ability to handle variants as individual instances.
0 -
Thomas,
In general I do not disagree with your principal argument.
The problems might arise when users have to make choices and find, very likely, additional complexity, more choices and conflicting ways of doing the same thing.
Now one can contain that sort of problem to some extent by setting parameters for the software to function only one way or another. However I doubt that all users would accept such a solution and in any case there is tremendous scope for confusion when trying to support two segregated approaches.
The world seems to have headed into demanding ever greater complexity mainly because it can rather than because it needs it. Software, since its early days, has led in that direction.
It's actually quite easy to handle variants as individual images providing one is prepared to treat the source files as individual images. Or, more in line with traditional dark room based photography, treat the OUTPUTs as the Album content.
After all if we are discussing Albums anything that is only existing in C1 as am Album is not an immediately public product for consumption. An output file, processed to a size and for a specific type of viewing whether screen or printed, IS a file for public consumption. Just as would be the case for a print from a negative in fume room days.
Maybe we should re-think the use of the word "Album" as applied to the digital era. Perhaps also the purpose of the collection?
0 -
I don't quite see what albums not being immediately public products for consumption has to do with the ability to add individual variants to an album.
And whether or not it's called an album or something else isn't really important. The main thing here is the simple ability to add individual variants to a collection without having to use a workaround. The basic principle really is simple: one image file referenced in the catalogue + any number of variants of this image in the catalogue, all of which can be handled as independent instances. I fail to see anything confusing about this.
0
Post ist für Kommentare geschlossen.
Kommentare
17 Kommentare